1. 为什么说"context-mode"是一种工程模式，而不是一个传参技巧
先讲一件真事。去年我们上线了一个高并发的活动页，上线当晚就收到反馈：部分用户看到的订单详情是别人的。一开始以为是缓存key设计错了，查了半天缓存没问题，后来发现是ThreadLocal里的userId在Tomcat线程池复用的时候没有清理，用户A的上下文被后一个请求的用户B读到了。
这个事故让我彻底意识到一个事情：上下文（context）从来不是一个简单的传参手段，它是一套关于"状态如何随调用流动"的工程模式。技术圈里经常提到context-mode这个关键词，但大部分讨论都停留在某个具体框架的API层面，很少有人把它当成一种独立的设计模式去系统梳理。这篇文章我想把我在多个项目里对上下文模式的思考、踩坑、落地规范和排错方法一次性讲透，给被参数透传折磨、被全局变量坑过、准备设计全链路上下文的工程师一份可以直接参考的实践总结。
1.1 上下文到底在传什么
很多新手第一次接触Context时，会把它理解成"一个装着数据的袋子"，需要什么就从里面取。这个比喻是错的。正确理解应该是：上下文是"调用链路的环境快照"。
想象一封快递从发货人到收货人，每个中转站都要知道：谁发的、寄给谁、保价多少、走什么通道。你不需要让运费计算、仓库拣货、配送员都认识发货人和收货人的全部信息，他们只需要知道"这一单"需要的那几个字段。这些字段不是业务输入的一部分，却是整个链路正常运转所依赖的公共信息。
放到程序里，业务入参是用户主动提交的（比如下单的商品ID、数量），而上下文里放的是环境信息（比如当前登录用户、租户ID、请求追踪ID、语言偏好、权限范围）。这些信息的特点是：几乎每个环节都用得上，但它们不该由业务代码逐层签名传递。把环境信息拆成独立参数塞进每个方法，接口会快速膨胀；放在全局变量里，并发场景直接爆炸。上下文模式就是为了解决这个问题存在的——它把环境信息附加到调用链路上，让链路上的任意节点都能读取，同时又不污染业务方法的签名。
1.2 显式传参、全局变量、上下文模式的三角关系
三种方案说白了就是一个取舍图谱：显式传参最透明但最啰嗦，全局变量最省事但最危险，上下文模式处在两者之间，兼顾了可用性和可控性。我做了个对比表，团队里新人对这套认知理解得很快：
| 方案 | 代码可读性 | 并发安全性 | 跨层传递成本 | 故障排查难度 |
|---|---|---|---|---|
| 显式传参 | 高，调用关系清晰 | 高，变量只在栈内 | 高，每层签名都要改 | 低，参数从哪来一目了然 |
| 全局变量 | 低，隐式依赖到处都是 | 低，需要处理锁和线程隔离 | 低，随处可读可写 | 高，写入点无法追踪 |
| 上下文模式 | 中，入口包装后链路内隐式可见 | 中，取决于实现方式 | 中，需要统一封装 | 中，靠规范约束写入点 |
从这张表能看出来，上下文模式并非十全十美。它把一部分透明性换成了便利性。真正的问题在于：很多项目用着上下文模式，却没有配套的规范，结果就是上下文变成了一个"任何人都能往里丢东西的公共背包"，最后比全局变量还难排查。
1.3 上下文模式的两个关键属性：作用域与生命周期
我后来在设计上下文基础设施时，只盯两件事：作用域（scope）和生命周期（lifecycle）。
作用域决定了上下文能被谁看到。请求级的上下文只存活在一次HTTP请求的调用链里，线程级上下文只对当前线程可见，进程级上下文是JVM/Node进程内共享，跨服务级别则通过协议头在某次RPC调用中传递。这些作用域必须清晰定义，不然就会出现"我在A线程里set了上下文，结果B线程到处找它"这种诡异的bug。
生命周期更关键。上下文几乎总是和某个入口事件绑定：一个HTTP请求进来时创建，响应返回时销毁；一条消息被消费时创建，消费完成时销毁；一个定时任务开始执行时创建，执行完毕时销毁。如果生命周期管理不好，最常见的结果就是上下文泄漏——它比内存泄漏更隐蔽，不占内存，但会串数据。上面的用户数据串号事故就是典型的生命周期失控。
所以，上下文模式可以类比成有边界的通道，而不是一个无限大的背包。你需要严格控制什么东西在通道口进入，什么时候关闭闸门，以及通道在跨线程、跨服务穿越时如何把内容无损地带过去。
2. 不同技术栈里的"context-mode"长什么样
上下文模式听起来很抽象，但几乎所有主流技术栈里都有对应的原生实现，名字都叫Context，形态却完全不一样。我想要提醒大家的是：这些Context本质上共享同一套设计理念，但各自的边界和能力不同，别指望Go的context能当缓存用，也别把Android的Context理解成纯数据容器。
2.1 UI框架里的Context注入：React Context与Android Context
React的Context可能是前端同学最先接触的上下文模式。它的核心价值是解决props drilling问题——深层子组件需要某份数据，但中间层组件不需要这份数据，如果逐层传props，每一层都得写一堆透传代码。React Context创建了一条"组件树内暗线"，让深层组件直接消费Provider提供的数据。
const UserContext = React.createContext(null); function App() { const [user] = useState({ id: 10086, name: "阿哲" }); return ( <UserContext.Provider value={user}> <OrderPage /> </UserContext.Provider> ); } function OrderPage() { // 中间组件完全不需要感知 user return <OrderDetail />; } function OrderDetail() { const user = useContext(UserContext); return <div>{user.name}的订单</div>; }这个例子里的App就像是请求入口，Provider充当了上下文写入层，useContext则让任意深度的组件都能读取。注意一个细节：React Context的Provider销毁时，scope内的数据就随之消失，生命周期由组件树自动管理，所以React童鞋很少遇到"上下文没清理"的困扰。
Android里的Context则是另一种形态。Activity、Service、Application都是Context，它承载了资源获取、组件启动、系统服务访问等多种能力。每个Context的生命周期和它对应的组件一致，所以Android的Context天生就不能跨组件共享，这也是"Application Context和Activity Context能不能混用"这类经典面试题的来源。它更像是一个"环境句柄"，而不是纯数据容器，但其核心还是同一件事：让处于特定环境中的代码能够访问该环境提供的能力与信息。
2.2 并发场景里的上下文载体：Go的context.Context与Java的ThreadLocal
Go语言的context.Context是我见过设计得最克制的上下文实现。它的官方定位有两层：一是控制能力（超时、取消、Deadline），二是携带少量请求域数据（WithValue）。Go团队甚至建议WithValue只用来存"进程或API无关的请求域数据"，不要当普通HashMap用。
ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond) defer cancel() req, err := http.NewRequestWithContext(ctx, "GET", targetURL, nil) resp, err := client.Do(req)这是最经典的用法：从父context衍生一个带超时的子context，传给HTTP请求。所有下游只要是同一个ctx派生出来的，超时控制就能贯穿整个调用链。这也是Go社区约定"第一个参数传ctx"背后的逻辑——ctx就是调用链的控制通道，你不传它，下游就没有任何办法感知上层的取消和超时。
Java生态里对应的则是ThreadLocal。ThreadLocal把数据绑定到当前线程，核心思想是线程隔离。在Web应用中，Tomcat对每个请求分配一个工作线程，处理过程中所有代码都能通过ThreadLocal读取当前请求的身份信息，非常方便。但ThreadLocal有个著名的坑：线程池复用线程，如果请求处理完没有清理ThreadLocal，下一个请求复用到同一线程，就会读到上一个请求留下的脏数据，用户A看到用户B的数据就是这么来的。
TransmittableThreadLocal（TTL）是在这个场景下的重要补充。它解决了"父线程的本地变量怎么传给子线程"的异步透传问题。在下面的第4部分我会专门给出它的使用场景和避坑方法。
2.3 服务间传递：协议头、Trace Baggage与消息元数据
单进程内的上下文用线程或组件树来承载，那跨服务的上下文传递呢？答案是在协议层做文章。最常见的是HTTP请求头约定：网关解析登录状态后，把userId、tenantId写入自定义Header（比如X-User-Id、X-Tenant-Id），下游服务从Header读入后，再set到本地的ThreadLocal或context里。
这个模式是分布式链路追踪的基础。traceId和parentSpanId就是这样逐跳传递的。OpenTelemetry还有一个标准化的Baggage概念，专门用来在跨服务传播时携带业务上下文。它的作用和HTTP自定义Header类似，但有了统一规范，不同语言、不同框架的接入成本会低很多。
有消息队列（MQ）的项目要注意：消息消费者没有HTTP请求头可以读取，所以生产者发送消息时，要把traceId、tenantId这类上下文作为消息属性（message property）一并发送；消费者在消息入口把它提取出来，重新初始化本地上下文。很多团队在这一环会漏掉，导致消息处理链路里的日志无法和触发它的HTTP请求关联起来，排查问题的时候链路断掉，非常痛苦。
2.4 反模式清单：什么不该放进上下文
上下文是"窄门"，不是什么都能往里面塞的货舱。我总结了一个检查清单，任何想进上下文的字段，先过一遍这张表：
| 字段类型 | 举例 | 是否建议入上下文 | 原因 |
|---|---|---|---|
| 身份与权限 | userId、groupId、角色、VIP等级 | 是 | 横切关注点，处处需要 |
| 租户与地区 | tenantId、locale、时区 | 是 | 多租户隔离核心要素 |
| 调用链追踪 | traceId、spanId、来源App | 是 | 全链路可观测性基础 |
| 配置开关 | 用户级开关、功能flag | 视情况 | 简单值可以，复杂配置靠配置中心 |
| 大数据对象 | 图片字节流、文件内容、大JSON | 绝对不要 | 上下文随链路复制，IO和内存开销巨大 |
| 重量级服务 | Service实例、数据库连接池 | 绝对不要 | 这不是业务对象的容器，拿Spring/DI那套去用Context违背了它的设计初衷 |
| 频繁变化的业务状态 | 购物车内容、表单草稿 | 不建议 | 上下文应当偏静态，动态业务状态应走显式传参 |
一个很简单的判断原则：你问自己"这个字段万一在链路中途丢了，整个功能是直接错乱还是优雅降级？"如果是直接错乱，说明它很重要但未必适合放上下文，可能更需要显式设计；如果能优雅降级，说明它确实是环境信息，适合放上下文。
3. 从零搭建一套"上下文模式"基础设施时的关键决策
聊完原理和形态，进入实战环节。如果现在让我在一个从零开始的项目里落地上下文模式，我会按照下面的顺序推进。这部分不是教你调某个API，而是给你一整套可以复用的工程方案。
3.1 三个入口：请求入口、消息入口、任务入口
上下文模式的第一个原则：只允许在入口处写入上下文，业务代码里禁止set。那么入口都长什么样？在一个常见的后端服务里，有三类入口：
- Web请求入口：HTTP请求进入Controller前的拦截器/过滤器
- 消息消费入口：MQ消费者拉取到消息后的处理回调
- 定时任务入口：任务调度框架触发执行时的初始化阶段
对应的初始化逻辑也应该统一封装，我习惯用一个ContextHolder工具类加统一拦截器来处理。
public class ContextInit { public static void initFromHttp(HttpServletRequest request) { RequestContext ctx = new RequestContext(); ctx.setUserId(parseHeader(request, "X-User-Id")); ctx.setTenantId(parseHeader(request, "X-Tenant-Id")); ctx.setTraceId(parseHeader(request, "X-Trace-Id")); ContextHolder.set(ctx); } }拦截器在preHandle里调用initFromHttp，在afterCompletion里调用ContextHolder.clear()。消息入口就是消费时初始化、处理完在finally里清理。这里最容易踩的坑是：消息监听器往往跑在线程池里，而且一批消息可能复用同一个线程，所以"用完即清理"比HTTP场景更重要，否则最容易串消息。
3.2 字段命名与不可变约束
上下文里的字段一定要立好命名规范。要保证不同的团队在同一个上下文命名空间里不会互相打架。我推荐用前缀区分："ctx.userId"、"ctx.tenantId"、"ctx.deviceId"，而不要裸写"uid"、"orgId"。把整个Context设计成不可变快照，业务代码只读，任何需要修改上下文的场景都视为设计缺陷。
这里具体可以用一个不可变接口约束：
public interface RequestContext { Long getUserId(); Long getTenantId(); String getTraceId(); Locale getLocale(); }内部实现类有一个Builder，入口处统一构造。这样写的好处是：业务代码拿到的是接口，怎么set不了？直接不暴露setter，从类型层面堵住了"业务层随手改上下文"的路。这是我在多次review中被教育出来的一个点——上下文模式能不能落地，很多时候不取决于工具，取决于你从编译期就挡住错误用法。
3.3 跨线程透传与跨服务透传
单线程内用ThreadLocal或者函数参数传递上下文都很方便，一旦进入异步场景就会出问题。Java的线程池场景，我推荐引入TransmittableThreadLocal，它能把父线程的上下文快照自动传给子线程，在执行完后再恢复父线程的值。用法很简洁：
TransmittableThreadLocal<RequestContext> contextHolder = new TransmittableThreadLocal<>();配合TTL提供的TtlRunnable或TtlExecutors包装线程池，就不用自己手写快照拷贝了。Go这边要简单一些，因为context.Context本身就是显式参数，你只需要保证每个goroutine创建时都传入了正确的ctx即可。但要注意别用裸go关键字启动goroutine后又拿不到ctx，这种情况下应该把ctx作为参数传进新goroutine。
跨服务透传就是中间件自动处理。服务A发起HTTP调用时，从ContextHolder取出traceId、tenantId、userId，写入出站请求Header；服务B的入口拦截器读取这些Header，重新构造本地Context。这样一次跨服务调用的完整链路里，上下文是"从Header来，到Header去"，业务代码完全无感知。
3.4 兜底策略：上下文缺失时的优雅降级
没有任何系统是100%稳定传递的。总有漏网之鱼：某个老模块没接入上下文、某个外部回调丢失了Header、某个第三方SDK的线程池没有透传。这时候如果你的代码直接读ContextHolder.get().getUserId()，大概率空指针。
我的兜底策略是提供一个safeGet方法：
public static Long currentUserId() { RequestContext ctx = ContextHolder.get(); return ctx == null ? null : ctx.getUserId(); }对于必须要有登录态的接口，校验失败就返回401；对于可选的上下文，缺了就给默认值并打印一条warn日志。关键点是：在兜底的地方要打日志，这样能帮你快速发现还有哪些链路没有接入上下文透传，而不是无声无息地降级。上下文缺失的问题有一个特点：它不像功能报错那样明显，如果每次都静默降级，这个问题就永远修不完了。
3.5 在测试与压测环境里模拟上下文
测试上下文模式最容易翻车。常见的是：单元测试里调用某个service方法，方法里偷偷用了ContextHolder，测试环境没有线程上下文，直接NPE。所以我会给项目提供一个TestFixture，专门用来构造测试上下文：
RequestContext ctx = TestContextBuilder.create() .user(10086L) .tenant(1L) .trace("test-trace-id") .build(); ContextHolder.set(ctx);另外，压测环境里上下文容易出现的问题是线程复用导致上下文串数据集。做压测时不要用固定的userId，最好用并发独立的随机用户集合，每个请求的上下文字段数据要跟着并发数走。不然数据库连接、缓存结果、权限逻辑都可能互相干扰，压出来的数据完全不可信。
4. 排错实录：三个"上下文事故"的完整排查链路
上下文引发的bug，症状千奇百怪，但其实都有迹可循。这一节把我在真实项目里遇到过的三类典型事故完整复盘一遍，给你参考排查思路，比直接甩结论有用得多。
4.1 事故一：线程池里读不到userId，异步任务全部"匿名"运行
现象：用户触发了一个导出任务，后台异步生成Excel。刚上线时一切正常，某天开始大量用户反馈导出文件生成失败，日志里出现"导出者不存在"的报错。
排查过程：一开始以为是用户中心接口出了问题，因为导出任务里要先调用户中心查昵称和头像。但用户中心说接口一直正常，压力也不大。然后我们拿到一条完整日志，从入口请求追踪到导出异常，发现异常点从"查用户中心"变成"从上下文获取用户ID"这里就没了。继续往下查，发现导出任务执行线程的名字带POOL-，明显是异步线程池。再翻代码，提交导出任务时用的是ExecutorService.submit，没有做任何上下文快照透传，所以子线程里ContextHolder是空的。
根因：线程池边界没有做上下文透传。主线程在HTTP请求里有上下文，子线程是和主线程隔离的，自然读不到。
修复：把执行器包装成TtlExecutors，并在提交Runnable/Callable时使用TtlRunnable。改动非常小：
ExecutorService executor = TtlExecutors.getTtlExecutorService(rawExecutor); // 提交任务时，TTL会自动把父线程的上下文快照带进子线程 executor.submit(() -> exportData(userId, startTime));4.2 事故二：ThreadLocal没有清理，用户A的数据跑到用户B的页面
现象：开头提到的活动页数据串号事故。用户A的订单详情出现在用户B的页面上，频次不高，偶尔出现，客服那边一天能收到几十条投诉。
排查过程：这种偶发性问题最怕没有排查思路。我们先把疑点放在缓存上，查了一遍Redis的key设计，没发现问题。后来抓了一个复现请求，同时打印了Tomcat工作线程ID，发现两个串号用户的请求恰好命中同一个线程。继续在ThreadLocal.set的位置打日志，发现第二个请求进来时，当前线程的ThreadLocal里已经存在userId了，而这个userId是前一个请求还没来得及清理的。
继续追下去，原来某次技术升级时，有人把拦截器里的ContextHolder.clear()删掉了，理由是"反正每次请求都会重新set，覆盖掉就好"。这恰恰是最要命的逻辑：你覆盖掉之前如果中间有异常，set逻辑被跳过，旧数据就一直留在ThreadLocal里。
根因：ThreadLocal生命周期管理失效，线程复用导致脏上下文传播。
修复：拦截器里采用标准的try-finally清理模式，而不是图省事只用set覆盖。代码要写成这样：
try { ContextHolder.set(buildContext()); chain.doFilter(request, response); } finally { ContextHolder.clear(); }注意：无论上下文是否被正常初始化，finally里的clear都必须执行。这一行代码应该写进团队代码规范，没有任何例外。
4.3 事故三：Go context.WithTimeout传导到所有下游，一次慢查询拖垮整条链路
现象：一个Go微服务频繁报错，错误信息是"context deadline exceeded"。但单独看这个服务的接口，响应都很快，没理由超时。这个报错集中在调用某个外部存储的环节。
排查过程：先看了外部存储的监控，P99延迟正常，排除存储本身变慢。然后在报错日志里找到了上游的traceId，去链路追踪系统里拉出整条调用链，发现入口服务设置的client超时时间是500ms，但整条链路经过两个内部服务、一次Redis访问、一次外部API调用，到外部存储这一跳时，剩余超时时间已经不足100ms。它其实不是慢，而是整个链路的预算被前面几跳瓜分完了，加上网络抖动就触发了deadline。
更深一层的问题在于：入口服务在构造ctx时用了context.WithTimeout(500ms)，然后把这个ctx作为参数传给所有下游。调用链越长，每个环节能分到的剩余时间就越少，最后一个环节哪怕只耗了50ms也容易超时。
根因：超时上下文是全链路共享预算，入口给的超时太短，未按环节数量预留余量。
修复思路：入口服务的超时时间要按整条链路的预估耗时来设定，且每跳之间保留网络与排队余量。更重要的是区分"调用控制的超时"和"业务处理的超时"，前者应该用更宽松的预算，后者在具体环节内单独控制。这个坑也让我意识到：引入上下文模式时，团队需要对"ctx里携带的控制语义"建立共识，否则一个WithTimeout会把整个服务树都勒住。
4.4 上下文问题的一般排查思路
把我遇到的这些事提炼成一张排查速查表，遇到类似症状直接对表找方向：
| 现象特征 | 优先怀疑的上下文类型 | 主要检查点 |
|---|---|---|
| 权限频繁被拒、登录态丢失 | 身份上下文 | 线程池是否透传、Header是否丢失、入口是否初始化 |
| 偶发数据串号、用户数据错乱 | 作用域隔离 | ThreadLocal/Context清理逻辑、线程池复用 |
| 大量超时、下游接口被拖垮 | 控制上下文 | 入口超时预算、WithTimeout设置位置、ctx树派生次数 |
| 日志里traceId对不上、链路断连 | 追踪上下文 | MQ消息属性、跨服务Header透传、异步线程透传 |
| 压测数据诡异、随机性报错 | 测试上下文 | 是否固定userId、上下文是否被并发修改 |
5. 回忆一次架构演进：从"全局变量大杂烩"到"上下文模式规范化"
前面讲的都是方法和工具，这一节我想讲一次亲历的架构演进。这段过程对我理解context-mode的影响很大，也解释了为什么我现在反复强调"上下文模式必须规范化"。
5.1 早期：几百个全局静态变量与"上帝类"
很多老项目都经历过这个阶段。全局静态类里堆着几十上百个常量和状态变量，什么用户ID、租户ID、请求来源、当前语言……所有模块都直接读写它。这个阶段的痛点远不只是并发安全，更重要的是你根本不知道某个值是在哪里被改掉的，改了它会影响谁。全局可变变量让整个系统的调用关系变得混沌，代码review就是在赌谁的运气好。
5.2 第二阶段：过度修正，接口签名膨胀
后来团队做了一次大重构，口号是"消灭全局变量"。做法是把所有之前放在全局变量里的字段，都改成方法参数透传。结果是，一个下单方法要从Controller一路传userId、tenantId、deviceId、channel、lang等七八个环境参数到底层，接口签名长达十几行。哪层忘传，下游就静默出错，比全局变量的"玄学问题"甚至更难定位。
5.3 第三阶段：引入上下文模式并立下的规范
再后来就是引入上下文模式，把横切信息收敛进请求上下文，业务参数只保留真正的业务字段。和第二阶段相比，代码行数、接口签名长度、review争议都大幅下降了。注意：上下文本身是隐式依赖，要让它可控，必须立规矩。我们立下的规范和前面第3部分讲的基本一致：只允许入口写、业务层只读、线程边界必须透传、用完必须清理。这套规则写进团队规范后，上下文相关的事故率开始明显下降。
5.4 诚实的复盘：上下文模式的局限性
规范化之后，项目是干净了，但我对上下文模式的态度也冷静了。它不是银弹。上下文模式最大的代价是"隐式依赖"——你看到某个方法读userId，无法从签名上判断它依赖了上下文里的什么。这给代码阅读和自动化分析增加了一些难度。
我的经验是：核心业务参数应该永远是显式传参，上下文只承载横切关注点。判断标准也很简单——"如果这个值丢了/变了，是业务逻辑不对，还是环境信息不对？"前者必须走参数，后者才适合放上下文。把这两个混在一起，就是技术债的开始。
6. 把"context-mode"用好，最后要守住这几条线
写到这里，该把最重要的经验收敛成几条原则了。这些原则是我在若干次踩坑和复盘之后沉淀下来的，每次新项目启动上下文建设时，我都会把它们放到README最显眼的位置。
6.1 铁律一：写入点必须收敛在入口
上下文要么别用，要用就必须限制写入权限。入口之外任何set操作，都应该被code review拦下。实现上可以做一层封装：业务代码拿到的是只读接口，写入用的Builder/ContextHolder.set只在基础设施层代码里可见。如果团队规模不大，靠Review习惯也够用，但有一定规模之后建议用静态扫描规则兜底。
6.2 铁律二：异步边界必须显式透传
跨线程、跨进程、跨服务的每一道边界，都要有显式处理方案。Java里用TTL、Go里把ctx作为参数传给goroutine、跨服务靠中间件读写Header。最忌讳的是"异步就完事了，上下文不管了"——这种项目早晚要出一个串号或丢上下文的事故。
6.3 铁律三：任何上下文字段，都要能回答三个问题
每一份放进上下文的字段，写代码的人必须能脱口回答三个问题：从哪来？哪些环节在读？丢了会怎样？回答不上来，说明这个字段还不该进上下文。这个问题的意义在于逼你建立上下文的"数据字典"，而不是让上下文变成一个黑盒。
我可以再分享一个实用做法：在项目里给上下文字段建一个维持的markdown文档，哪怕只有几行字，也要写清楚字段名称、类型、来源、消费方、缺失时的策略。时间长了你会发现，这份文档比很多设计文档都有用，排查上下文问题全靠它当索引。
6.4 铁律之外：推荐配置与工具检查
- 接入链路追踪系统，让traceId成为上下文的标配字段，排错时把上下文问题放回全链路视图里看，定位效率翻倍。
- 使用静态检查或CI规则，扫描是否有业务包直接调用了ContextHolder.set，出现即构建失败。
- 在测试用例里覆盖"上下文缺失"场景，主动验证safeGet降级逻辑是否生效。
- 压测脚本里使用随机上下文数据集合，避免线程复用导致的上下文串扰污染压测结果。
做了这么多项目，我对上下文模式的态度从最初的反感，变成了敬畏。反感是因为它曾给我带来过串号事故的惊吓；敬畏是因为，只要生命周期管住了、写入边界守住了、异步透传做实了，它确实是解决横切状态传递问题的最合适方案。如果你现在正被接口参数膨胀或者全局状态混乱折磨，不妨拿这篇文章的思路做一次上下文审计：先列出当前系统中所有"环境信息"字段，再看它们是否经历了统一的入口初始化、是否在异步边界有明确透传、是否在出口有可靠清理。这三点只要补到位，绝大多数上下文相关的坑都能提前绕开。
