1. 项目概述

1.1 核心需求解析

“context-mode”这个名字，最初是我在做一个内部工具时突然冒出来的想法。当时团队成员正在为“切换环境后参数错乱”的问题焦头烂额——测试环境跑得好好的配置，一到生产环境就乱套，不是加载了旧的缓存，就是拿到了另一个服务的实例。查来查去，问题出在我们对“上下文”这个概念处理得太随意了：全局变量满天飞，状态散落在各个模块里，谁都能改，改完谁都不记得。

我意识到，与其继续打补丁，不如把“上下文”本身当成一个一等的设计对象来对待。这就是“context-mode”的雏形：一套以上下文为核心组织代码逻辑的开发模式。简单说，它的核心是给系统里所有“跟当前环境、当前用户、当前请求相关的东西”一个统一的身份和生命周期，而不是让它们在代码里四处游荡。

这篇文章里，我会把这个模式从设计思路到落地实现完整拆一遍。适合正在做中大型项目、被配置管理、状态同步、多租户隔离这些问题困扰的后端开发者，也适合想了解如何系统化处理“上下文”这个概念的前端同学。你不需要有很深的架构经验，只要写过几个接口、被环境切换坑过，就能看懂我在说什么。

1.2 它解决什么问题

常规开发里，上下文信息通常是散装的。用户ID放在session里，请求ID放在中间件里，数据库连接串放在配置文件里，日志追踪号放在协程里——每个模块各自为政，互相之间靠“约定”通信。这种“约定式”方案在项目规模小的时候没毛病，但当系统复杂到一定程度，问题就开始冒头了：

第一，切换场景时会出错。测试和生产的数据库地址不同、缓存前缀不同、调用外部服务的token不同，稍有不慎就串了。我在一个项目里见过最离谱的bug，是线上环境给用户发了测试环境的营销短信，就是因为一处状态没有跟着上下文切换。

第二，排查问题靠猜。没有统一的上下文记录，一个请求进来，经历了哪些服务、用了哪些配置、踩了哪些分支，全靠日志里有没有人记得打点。出了问题，只能一台台机器翻日志，效率极低。

第三，代码复用率低。每个函数都得从各种地方获取自己需要的“环境参数”，要么传参传一长串，要么从全局拿。两种方式都难受，最终导致代码和具体调用场景强绑定，没法轻易复用。

context-mode的解决思路很直接：把所有跟“当前是什么场景”相关的信息，收拢到一个统一的上下文对象里，由框架层面创建、传递、销毁，业务代码只跟这一个对象打交道。

2. 核心思路与设计原则

2.1 区分“数据”和“上下文”

很多项目把配置、状态、上下文混为一谈，这是设计混乱的根源。我自己的理解里，这三者是有清晰边界的：

• 配置是相对静态的，比如数据库地址、Redis密码、开关状态。它一般来自配置文件或配置中心，一个服务一套。
• 状态是相对动态的，比如某个订单当前处于哪个流程节点、某个任务执行到第几步。它存储在数据库或内存里，跟具体业务对象绑定。
• 上下文是“某次具体运行过程”的信息，比如这次请求是谁发起的、来自哪个端、traceId是什么、应该用哪套配置。它的生命周期只存在于一次调用链中。

拿做饭打个比方。配置是厨房里贴着的菜谱，谁来做都一样；状态是锅里那锅菜现在炖到什么程度了，只属于这道菜；上下文则是“此刻是谁在掌勺、给谁做、口味偏咸还是偏淡”。context-mode管的就是最后一个——它让你在做菜过程中的每一步，都能知道当前是给谁做的、该放多少盐。

这个区分解决了我在实际项目中遇到的一个很典型的问题：有同事把配置读到之后直接塞进了全局变量，结果服务一旦被多个租户共用，A租户的开关就影响了B租户的行为。把配置访问通道路由到上下文之后，这套问题就再也没有出现过。

2.2 为什么非要做成“模式”

有人可能会问，直接用现成的依赖注入容器或者ThreadLocal不就行了吗？为什么要自己造一个“模式”出来？

依赖注入容器管理的是“对象的实例化时机”，它不关心“当前这次调用处在什么场景”。ThreadLocal能存储线程内的变量，但它只是一个存储工具，没有生命周期概念，用完了不清理就会内存泄漏，而且业务代码很容易绕过它、直接new一个对象就完事。

context-mode更接近于一套行为规范：它明确了哪些信息必须放在上下文里、上下文什么时候创建、什么时候销毁、业务代码通过什么方式读取和写入——这些如果不靠约定而是靠自觉，迟早会有人打破约定。

我见过不止一次“所有人都知道应该走上下文，但有人图省事直接塞了个全局变量”的情况。所以，这套模式最终落地时，我的做法是：框架层强制创建上下文，业务层只能通过显式的Context对象访问，没有第二种入口。强制，是它区别于“工具类”的核心。

2.3 生命周期设计：一次调用，一份上下文

context-mode最重要的一条铁律是：一请求一上下文，请求结束上下文必须销毁。这条规则听起来简单，实现起来容易出问题，尤其是现在几乎所有服务都是高并发的多线程模型。

我最早用Java写这套逻辑时，用的就是ThreadLocal。每个请求进来时创建一个Context对象放进去，请求结束时在finally块里调用remove()清理。但这样有个隐患：线程池里的线程是复用的，如果请求A处理完之后代码抛了异常、清理逻辑没有执行，线程里残留的上下文就会被请求B读到，造成数据串线。

后来我做了个装饰器，把创建和清理包在了一个统一的包装类里，任何进入服务的入口都必须过这个包装类。这样即使业务代码中抛了异常，清理逻辑也在finally里兜底，线程池复用的情况下也不会残留脏数据。这一步是我认为整个设计里最值得借鉴的防御性措施。

2.4 数据隔离：上下文不等于全局变量

这里要强调一下：上下文对象只能承载“与当前运行场景相关的”信息，绝不能变成新的全局变量容器。我见过有团队把上下文当成万能袋，什么东西都往里塞，最后上下文对象膨胀成一个几百字段的上帝类，比之前的全局变量还难维护。

我定的规矩很简单：

• 放哪些字段？只放身份信息（用户ID、租户ID、请求ID）、链路信息（traceId、spanId）、环境选择信息（配置版本、环境标签）。
• 不想放的？任何跟业务计算相关的数据都不放。订单金额、用户等级、库存数量这些，该查库的查库，该算的算，别为了省事塞进上下文。

一旦上下文开始承载业务数据，它的生命周期就跟业务对象绑定在一起了，不再纯粹是“运行场景信息”，整个模式就变味了。这条规矩我在团队里反复强调，代码评审时发现违反的直接打回，坚持了几周才让大家形成习惯。

3. 技术选型与实现方案

3.1 语言无关的核心抽象

先说结论：context-mode不绑定任何语言，核心抽象有且仅有三个接口。

第一个是Context接口，描述“当前上下文有哪些信息”。它至少得提供读取身份信息、链路信息、环境信息的方法，以及写入自定义键值对的能力。第二个是ContextFactory接口，负责创建上下文。一个请求进来，框架需要根据请求头、token、环境标识别等原始信息，构建出一个完整的Context对象。第三个是ContextHolder，它是业务代码访问上下文的唯一入口。业务层不直接持有Context对象，而是通过Holder在任何地方拿到“当前这次调用”的上下文。

这样三层解耦的好处是：底层用ThreadLocal实现也好、用协程局部变量实现也好、用请求头传递也好，业务代码完全感知不到。我在这套抽象之上分别用Java和Node.js实现过一遍，业务代码的核心逻辑完全一样，只有基础设施层不同。

3.2 Java实现的关键细节

Java平台最自然的落点是ThreadLocal，但直接裸用会有很多隐患。我的实现是定义了一个ContextHolder类，内部维护一个ThreadLocal<Context>，但只暴露静态方法get()和set()，并且set方法加了权限控制——只有框架层的过滤器和拦截器能调用，业务代码拿到的是只读视图。

这个只读视图很重要。如果不做限制，业务代码里任何一个地方都能context.set("userId", "1")，那上下文就不“上下”了，成了人人可改的公共变量。我通过定义一个只暴露get方法的接口，而实际实现类实现了完整的读写接口，这样业务侧拿到接口引用时，编译器层面就禁止了写操作。

另一个关键点是跨线程传递。现在很多服务都有异步处理的场景，主线程创建了上下文，结果提交给线程池的子线程执行时，子线程里拿不到上下文。Java提供了ThreadLocal的子类InheritableThreadLocal可以自动传递，但它只能传递到第一层子线程，孙线程就传不过去了。我的方案是在提交任务到线程池之前，手动把当前上下文复制一份，在任务体的开头重新set进去，任务结束再清理掉。这是每个用了异步的高并发服务都躲不开的问题，踩过坑的自然懂。

3.3 Node.js的场景适配

Node.js的异步模型没有线程的概念，但也因此更容易出问题。Node里最常见的坑是：请求A还在处理中，中间await了一个异步操作，等异步操作回来之后，执行上下文已经在同一个进程里被别的请求复用了。

Node.js社区常规的做法是用AsyncLocalStorage，它能在异步调用链中自动传播上下文。我的实现是写了一个中间件，在每个请求进入时run()一个新的Context存储，之后的整个异步链路——包括Promise、async/await、定时器——都能访问到同一个上下文。

用Node实现的好处是语法比Java简洁很多，但坑也不少。最典型的是：如果业务代码里有人用了setTimeout但没await，或者自己实现了奇怪的异步调度，上下文就会丢失。我的排查经验是，给异步调用链加上自动打点，每次通过Holder获取上下文时检查是否存在，不存在就输出一条带了请求ID的告警日志，这样很快就能定位到是哪里断了链。

3.4 多语言统一的接口设计

如果团队是异构的，比如服务端Java、BFF层Node.js，我建议把上下文信息的传递格式做统一。具体做法是设计一个标准上下文传输结构，定义好字段名和类型，跨服务调用时通过请求头传递。Java服务端从请求头解析，Node端从请求头解析，解析出来的都是同一个结构，之后各自放进自己的上下文机制里。

这个传输结构我一般只放五个字段：traceId、spanId、userId、tenantId、envTag。其中envTag就是环境标签，它决定了当前应该加载哪一套配置、连接哪一套基础设施。这套结构越小越好，因为每个字段都要在每一次请求中传递，字段太多了传输成本和管理成本都会上升。

3.5 配置服务与上下文联动

context-mode效果最明显的地方，是跟配置中心联动的时候。传统方式下，服务启动时一次性把配置拉下来放内存里，切换环境要重启服务。而跟上下文联动之后，配置可以做到请求级别的切换。

具体做法是：配置中心里维护多套配置，每一套用一个envTag标记。请求进来时，Context里已经带着这个请求应该用的envTag（通常从网关透传，或者根据请求头解析），配置管理器拿着这个envTag去取对应的配置。同一个服务实例，A请求用测试配置，B请求用生产配置，两个请求同时跑，互不影响。

这个能力在做灰度发布、多租户隔离的时候特别有用。我在一个SaaS项目里用这套方案实现了“同一个服务实例同时服务不同版本客户”的效果——无需为每个客户部署一套环境，而是让每个请求带着自己的环境标签，动态选择自己的配置组合。

4. 实操过程与核心环节实现

4.1 第一个版本：手动传递的Context对象

我先说最初级的实现，虽然不够“自动”，但能让把概念讲清楚，后面再逐步升级。

第一步，定义Context对象：

public class Context { private String traceId; private String userId; private String tenantId; private String envTag; private Map<String, String> extra = new HashMap<>(); // getters and setters 省略 }

第二步，在入口处创建上下文：

public void handleRequest(Request request) { Context ctx = new Context(); ctx.setTraceId(request.getHeader("X-Trace-Id")); ctx.setUserId(parseToken(request.getHeader("Authorization"))); ctx.setEnvTag(request.getHeader("X-Env-Tag")); // 调用业务 process(ctx, request); }

第三步，业务方法接收并透传：

public void process(Context ctx, Request request) { OrderService orderService = new OrderService(); orderService.createOrder(ctx, request.getBody()); }

这个版本的问题很明显：每个业务方法都要多一个Context参数，到处透传，代码很啰嗦。小项目勉强能用，项目一大就痛苦了。但它有个好处——上下文是显式的，不会“凭空出现”，新人看代码也能明白数据从哪来。如果团队刚开始引入context-mode，我建议先从这么原始的版本做起，让大家先理解“认理”的概念，再上自动化。

4.2 第二个版本：嵌入框架的自动上下文

第二个版本，把上下文的创建和传递交给框架层。以Java的Spring Boot为例，我是通过一个HandlerInterceptor实现的：

public class ContextInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { Context ctx = ContextFactory.create(request); ContextHolder.set(ctx); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { ContextHolder.clear(); } }

在配置类里注册这个拦截器：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new ContextInterceptor()); } }

之后任何业务代码里，只需要一行就能拿到当前上下文：

Context ctx = ContextHolder.get();

这个版本的好处是从此业务方法不再需要透传Context参数了，代码清爽很多。但我必须提醒：这里有个关键前提，就是请求必须经过拦截器。如果项目里有定时任务、MQ消费者、RPC回调这些“非HTTP入口”，拦截器覆盖不到，就必须自己写对应的入口包装逻辑。

我在实际落地时，把非HTTP入口统一封装成一个ContextRunner工具，任何Runnable/Callable丢进去，自动完成上下文创建、执行、清理三件事。这样所有入口都走同一套逻辑，不会出现HTTP请求有上下文、消息消费者没上下文的割裂状态。

4.3 第三个版本：异步链路与线程池穿透

进阶版本解决异步链路的问题。先看Java里线程池的场景，核心代码如下：

public class ContextAwareRunnable implements Runnable { private final Context ctx; private final Runnable delegate; public ContextAwareRunnable(Context ctx, Runnable delegate) { this.ctx = ctx; this.delegate = delegate; } @Override public void run() { ContextHolder.set(ctx); try { delegate.run(); } finally { ContextHolder.clear(); } } }

提交任务时，包装一层：

executor.submit(new ContextAwareRunnable(ContextHolder.get(), () -> { // 业务逻辑，这里可以用 ContextHolder.get() 获取上下文 }));

Node.js这边更干净，因为AsyncLocalStorage是原生支持的：

const { AsyncLocalStorage } = require('async_hooks'); const storage = new AsyncLocalStorage(); function middleware(req, res, next) { const ctx = { traceId: req.headers['x-trace-id'], userId: parseToken(req) }; storage.run(ctx, () => next()); } function getContext() { return storage.getStore(); } // 业务代码里任何地方 const ctx = getContext();

但Node这边有个非常隐蔽的坑：如果用AsyncLocalStorage的run包裹了某个Promise，而这个Promise内部又发起了不受run控制的资源（比如手动创建的ChildProcess、某些老库内部的Promise），上下文就续不上。遇到这种情况没有银弹，只能逐个排查哪个库不兼容。我后来把框架里所有异步入口都统一收口，禁止业务代码直接创建裸Promise之外的重型异步资源，这个问题才根绝。

4.4 跨服务传递：让上下文跟着请求走

单机版处理完了，分布式环境下的跨服务传递就是下一个大问题。服务A调用服务B，服务B怎么知道当前是哪个用户？哪个环境？

做法是在HTTP客户端里自动注入上下文相关的请求头。以Java的RestTemplate为例，做一层拦截器：

public class ContextPropagationInterceptor implements ClientHttpRequestInterceptor { @Override public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException { Context ctx = ContextHolder.get(); if (ctx != null) { request.getHeaders().set("X-Trace-Id", ctx.getTraceId()); request.getHeaders().set("X-User-Id", ctx.getUserId()); request.getHeaders().set("X-Env-Tag", ctx.getEnvTag()); } return execution.execute(request, body); } }

服务B端，刚才写的ContextInterceptor会自动解析这些请求头并重建上下文。这样，一次完整的调用链从头到尾，每个服务都能看到同一个traceId、同一个envTag。排查问题时按住traceId一搜，整条链路的日志全部拉出来，效率提升是质的飞跃。

我建议所有还在用“手动塞请求头、手动解析请求头”的团队，尽快把这一层自动化做掉。这属于投入产出比极高的改造，做一次，后面所有新老接口都自动获得全链路追踪能力。

4.5 Redis与数据库的上下文感知

上下文模式还能应用到基础组件上。比如Redis，同一个服务实例里，不同租户的数据需要隔离。传统做法是给每个租户的key加前缀，业务代码里每条Redis命令都要记得拼前缀，漏一条就串数据。

有了context-mode之后，Redis客户端可以在执行命令前自动拼上租户前缀：

public class TenantAwareRedisTemplate extends StringRedisTemplate { @Override public <T> T execute(RedisCallback<T> action) { Context ctx = ContextHolder.get(); String prefix = (ctx != null && ctx.getTenantId() != null) ? ctx.getTenantId() + ":" : ""; return super.execute((connection) -> { // 包装 connection，让所有 key 自动加上前缀 return action.doInRedis(new PrefixingRedisConnection(connection, prefix)); }); } }

数据库连接也可以做类似的处理。比如多租户场景里，不同租户要用不同的数据库连接串，通过上下文里的tenantId动态路由数据源。这块可以用Spring的AbstractRoutingDataSource实现，关键代码就一行：

@Override protected Object determineCurrentLookupKey() { Context ctx = ContextHolder.get(); return ctx != null ? ctx.getTenantId() : "default"; }

这个动态路由能力，让我在项目里省去了部署多套环境的成本。每个租户的数据物理隔离，但服务是共享的，运维压力一下子小了很多。

5. 常见问题与排查技巧实录

5.1 “上下文丢失了”如何排查

在分布式链路里，最容易遇到的现象就是：服务A日志里有traceId，但调用服务B后，服务B的日志就没有traceId了。我整理了一套排查路径，遇到这个问题直接按顺序查：

1. 确认服务A发出请求前上下文还存在。在HTTP客户端拦截器里打一条DEBUG日志，看看能不能读到ContextHolder.get()。
2. 确认请求头真的传过去了。很多框架会自动过滤掉一些请求头，比如某些网关会剔除带X-前缀的请求头，需要在网关卡口放行。
3. 确认服务B的入口拦截器真的执行了。有些Spring Boot项目配置了WebMvcConfigurer但没加@Configuration注解，拦截器根本没注册，必现丢失。

这三步排查完，基本能解决90%的丢失问题。剩下10%的情况，多发生在异步链路里，得按5.2的方案处理。

5.2 异步场景下的四种典型坑

第一种坑：主线程和子线程上下文串了。Java的线程池复用机制决定了，线程执行完任务后不会销毁，而是回到池子里等下一个任务。如果不在任务结束前清理上下文，下一个任务就会读到上一个任务残留的数据。解决方案前面说了，就是ContextAwareRunnable包装加finally清理，这种问题一旦用上包装器就彻底不会出现。

第二种坑：InheritableThreadLocal只传一层。任务A提交了子任务B，如果A也是线程池里的线程，B能拿到A的上下文；但如果B又提交了任务C，C就拿不到了。我的建议是一律手动传递，不要依赖InheritableThreadLocal的自动传播。

第三种坑：异步框架自行管理线程。比如Spring的@Async注解、MQ的消费者线程池，默认不受你代码控制。处理方式是在这些框架的自定义配置里，加上上下文的创建包装逻辑。

第四种坑：Node.js中异步链断裂。常见于三方库内部管理了异步资源，导致AsyncLocalStorage里的context失效。这种问题的排查思路比较直接：在getContext()返回null的地方往回追，看看是不是最近某次await之后才失效的，然后定位到具体库，要么换实现方案、要么包一层手动传参。

5.3 上下文数据“脏”了怎么办

这里说的“脏”，是指context里读出了跟当前请求不符的数据。在国内访问量大的服务里，这是一个必踩的坑，没必要从业务代码层面找原因，几乎都是生命周期没管好。

就拿最典型的场景来说：某次请求在处理过程中抛了一个业务异常，拦截器的afterCompletion没有被Spring正确调用。这时候ThreadLocal里的Context没有清理，线程回到池子里之后，下一个请求就把它当成自己的上下文了。

排查这种问题，我教你一个“土办法但异常好用”的技巧：在Context对象里记录创建时的traceId和线程名。当前请求的traceId一旦跟Context里的对不上，立刻报警。这个报警抓到的错误，几乎100%指向没有及时清理的残留上下文。

另外也检查一下业务代码里有没有人直接把Context对象存进了共享缓存、静态变量、类成员变量。之前见过一个团队把Context放在Spring单例Bean的成员变量里，那真是灾难，这个Bean一被并发访问，上下文就混乱了。正确做法是Context永远存在线程局部、协程局部或者显式传参中，绝对不进共享区。

5.4 性能损耗实测

有人会担心，每次请求创建销毁上下文，会不会有性能损耗？我在一个日均千万请求的服务上做了压测对比。第一种是裸请求不做任何上下文处理，第二种是走了完整context-mode链路。两者的QPS差距大约在2%左右，而且最大的开销不是ThreadLocal的读写，而是创建Context对象时的请求头解析和字符串处理。

这意味着，如果线上服务已经有比较重的中间件链，context-mode的额外开销几乎可以忽略不计。真正需要注意的，反而是别在Context对象里塞太大、太重的数据。我见过有人在Context里存了一个几十KB的业务对象，然后就发现内存占用上去了。Context对象应该保持轻量——我自己的铁律是里面只放字符串和基础类型，一旦发现有人在里面放了对象，代码评审直接驳回。

6. 实战改造案例：从全局变量到context-mode

6.1 原状与痛点

之前接手过一个老项目，典型的多租户SaaS系统，代码里全是全局静态变量管理当前租户信息。大概是这样的结构：

public class TenantHolder { public static Tenant currentTenant; }

这个TenantHolder在请求进来时被设置，理论上用完要清空。但实际上，只要有一个接口忘了清空，后面所有的请求全部串租户。生产环境出现过几次严重事故后，团队决定引入context-mode做整改。

6.2 改造步骤

改造不是一蹴而就的，我分成了四个阶段：

第一阶段要把所有读TenantHolder.currentTenant的代码改成ContextHolder.get().getTenant()，逻辑上没有大变动，主要是搜索替换。第二阶段开始有真正的收益——入口自动清理上下文，串租户的问题直接根除。第三阶段是硬骨头，因为老项目里异步入口特别多，有些隐藏在第三方库的回调里，得逐个建包装并验证。

6.3 改造后的效果

改造完成后我们做了几项验证：

• 并发压测下租户隔离准确率100%，专门写了一个“扫荡”测试用例，并发模拟不同租户操作，最后核对数据归属。
• 全链路日志统一带上了traceId，从网关到DB慢查询，一条链捞到底，平均排查故障的时间从小时级降到了分钟级。
• 新功能开发时，不再需要关心租户信息从哪来——从Context拿就是了。

这个项目的经历让我坚定了一个信念：上下文管理不能靠自觉，要靠架构。只要架构上让“走上下文”成为唯一可行的路径，团队就不会再走回全局变量的老路。

7. 后续可扩展的方向

7.1 与可观测性体系打通

context-mode与OpenTelemetry、SkyWalking这类可观测系统有天然的结合点。Context里的traceId、spanId可以直接作为Trace数据、Span数据的基础字段，改造成本极低。真正的利好是，业务数据与链路数据的关联度更高了——比如在日志里顺手打上当前的tenantId和userId，日志分析系统就能做租户维度的质量看板、用户维度的行为追踪。

7.2 上下文驱动的动态降级

基于上下文里的envTag，还可以做“按请求降级”的精细开关。比如当前请求来自某个灰度批次，或者来自某个资源紧张的租户，系统可以按上下文动态调整超时时间、限流阈值，甚至直接返回缓存。这种策略用context-mode实现非常顺手——策略决策时直接读上下文，加上决策表配置，代码层面几乎零改动。

7.3 从请求级到任务级

context-mode不只适用于HTTP请求，批处理任务同样适用。跑一个数据清洗的离线任务时，为整个任务创建一个上下文，任务内所有的读库、写库、打日志都带上统一的批次标识，出错时按批次回滚也方便。很多批处理项目之所以难排查，就是因为缺少这个“任务级上下文”——每条记录的处理过程都是孤立的，出了问题只能靠猜。

我在一个定时报表的项目里就用上了这一招：每个任务跑之前，先创建上下文并记录任务ID，跑完统一清理。后来遇到一次报表数据异常，我顺着上下文里的任务ID把一个万多条记录的批次全部定位出来，半小时内就锁定了问题SQL。要是没有任务级上下文，这个排查过程至少要一两天。

我个人在实际操作中的体会是，context-mode的价值不在于某一个具体的类库或代码片段，而在于一种“先明确当前场景，再执行具体动作”的思维定式。每当你准备写一个跟“当前是哪个用户、哪个环境、哪次请求”有关的逻辑时，先停下来问一句：“这个信息从哪里来？”如果答案是“从全局变量拿的”或者“我记不清了”，那就要警觉了——一致性地把这类问题交给上下文对象处理，系统的复杂度上限会被撑高很多，这也是我在多个项目里验证过的。