1. 一次线上事故，让我开始重新审视“context”这件事
先说个真实经历。去年年中，我们团队维护的一个中台服务突然出现用户数据串号投诉。现象非常诡异：用户A登录后，在某些接口里能看到用户B的订单信息，概率不高，但每次出现都是实打实的数据越权，客服炸了，技术侧也一脸懵。
一开始我怀疑是缓存key冲突，排查了一整天，redis的key都带上了userId，没发现问题。后来怀疑是数据库连接池的会话污染，检查了MyBatis的拦截器、事务传播机制，也没找到突破口。最后是翻了全链路日志，才在一个非常不起眼的地方发现了端倪：服务里有一个全局的单例工具类，内部维护了一个静态的ThreadLocal变量，用来临时存放“当前登录用户”。请求进来时，拦截器把用户信息塞进去，处理完再清理。
问题就出在这个ThreadLocal上。我们服务用了异步线程池处理部分任务，而线程池里的线程是复用的。某个请求没有在finally块里清理ThreadLocal，线程归还池子后，下一个请求恰好被分配到同一个线程，就读取到了上一个用户残留的信息。数据串号就是这么来的。
那次事故之后，我对所有“隐式共享状态”的方案都极度警惕。也是从那时候起，我把团队内部一套关于上下文传递、隔离、生命周期的约定整理成了一个明确的工程模式，我们内部直接叫它context-mode。
如果你也遇到过类似的灵异问题：偶发性数据错乱、测试环境正常但线上间歇性出错、同一个函数在不同调用方那里行为不一致，那这篇文章很可能帮你省下几个通宵。我会从后端请求级上下文、并发链路追踪、前端状态共享三个维度，把 context-mode 这个模式讲透，包括代码、踩坑和适用边界。
2. 先把“context-mode”定义清楚：它到底是什么，不是什么
“context-mode”不是一个严格意义上的学术术语，也不是某个框架的官方命名，而是一类工程实践的统称。我给它下的定义是：把一次业务操作所需的全部环境信息（身份、租户、请求ID、语言、超时时间、链路追踪ID等），封装成一个显式的上下文对象，并让它按照明确的规则在整条调用链中传递、继承、终止。
这个定义里有三个关键词：显式、生命周期、传递规则。我先逐个拆开讲。
2.1 上下文到底是什么，我为什么需要它
想象一下你点外卖。你下单的那一刻，系统需要知道你是谁、送到哪里、有没有优惠券、备注要不要辣。这些信息如果散落在各个服务里，每个环节都到数据库里去查一遍，那不仅慢，而且不同环节拿到的信息可能不一致。更好的做法是：下单请求一开始，就把这些信息组装成一个“订单上下文”，随订单流转到后厨、配送、客服各个环节。谁需要什么，直接从上下文里取。
在软件系统里，这个“订单上下文”对应的就是上下文对象。一次HTTP请求进来，我们需要知道当前用户是谁、来自哪个租户、请求ID是什么、登录态是否过期、是否需要记录审计日志。这些信息如果全部塞进方法参数，会让每个接口方法的签名变得非常臃肿；如果用全局变量或静态变量，就会面临我刚才提到的那种串号风险。
context-mode 的核心主张就是：上下文应该像快递单一样随包裹走，而不是像公告栏一样贴在墙上让所有人看。
2.2 三种常见的反模式，我踩过的坑
在定义清楚之前，先说说大家最容易犯的几种错误，这些我都踩过。
一是隐式全局上下文。用静态变量、ThreadLocal、application scope的Bean存储“当前用户”。这类方案最大的问题是生命周期不可控。只要有一个请求忘了清理，就可能导致数据串号。你可能会说“我用的是框架自带的SecurityContext，框架帮我清理”，但框架只能保证它自己管理的部分，你自己塞进去的自定义数据，框架根本不知道什么时候该清。
二是参数地狱。每个方法的签名都带上userId、tenantId、requestId、language、traceId。刚开始三五个参数还能忍，随着需求迭代，参数列表越来越长，甚至出现传错顺序的低级错误。更尴尬的是，有些环节根本用不到这些参数，但你为了能把数据传下去，还是得透传。
三是跨调用链路的上下文断裂。前端传过来的token，在网关层解析出用户信息后，调用下游服务时没把身份信息带过去。下游服务只能根据IP或临时token再去查一遍用户，不仅慢，还可能因为缓存没命中而拿到错误身份。这就是很多分布式系统里“登录了但功能不可用”的常见来源。
2.3 context-mode 的三条核心约定
我整理成三条，团队内做code review时直接对照这三条来检查：
- 上下文必须显式创建，显式传递。允许使用框架的隐式机制（比如线程局部变量）做临时持有，但必须在入口处显式初始化，在出口处显式清理，绝不能依赖“恰好被清理”这种运气。
- 上下文生命周期必须与业务操作生命周期对齐。一个请求一个上下文，一个消息任务一个上下文，一个定时任务批次一个上下文。上下文不能比业务操作活得更久，更不能跨多个不相关的操作存活。
- 上下文内容遵循最小化原则。只放那些“贯穿全链路但不属于任何单一业务逻辑”的数据。能通过查询拿到的数据、仅在单个函数内使用的数据，都不该进上下文。
这三条原则，我们在不同技术栈里都有对应的落地姿势。下面我用 Node.js 和 Go 各给一个完整的实战案例。
3. 后端落地一：用 AsyncLocalStorage 实现请求级上下文隔离
先给Node.js/TypeScript 场景。Node.js 服务是事件循环单线程模型，天然没有线程安全问题，但它有另一个问题：异步操作会在不同的事件循环周期里执行，如果上下文只是存在一个普通变量里，它在await之后可能会丢失。
这个问题的最佳解是AsyncLocalStorage。它由 Node.js 官方提供，专门用于在异步链路中传递上下文。我直接把项目中沉淀的完整实现贴出来。
3.1 为什么是 AsyncLocalStorage 而不是挂到 global
很多刚接触 Node.js 的同学会把“全局变量”当救命稻草：global.user = ...，反正单线程不会并发出错。但单线程只是不会同时执行两段代码，不代表不会交错执行。一个请求在 await 数据库查询时，另一个请求的代码可能就在同一个线程里跑起来了。你用 global 存用户信息，永远无法确定当前这个 await 后面，global 里的内容到底是谁的。
AsyncLocalStorage 的原理可以通俗理解为：它给每条异步调用链贴了一个隐形标签。你在链路的起点run一个store，这条链路上所有同步和异步的代码，都能通过getStore()拿到同一个上下文对象，天然隔离、互不干扰。
3.2 完整的中间件实现
// context.ts import { AsyncLocalStorage } from 'node:async_hooks'; import { randomUUID } from 'node:crypto'; export interface RequestContext { requestId: string; userId?: string; tenantId?: string; sessionId?: string; startTime: number; extra: Record<string, unknown>; } export const contextStorage = new AsyncLocalStorage<RequestContext>(); export function getContext(): RequestContext | undefined { return contextStorage.getStore(); } export function getRequestId(): string { return getContext()?.requestId ?? 'unknown'; } export function getUser(): string | undefined { return getContext()?.userId; }// middleware.ts import { NextFunction, Request, Response } from 'express'; import { contextStorage, RequestContext } from './context'; import { randomUUID } from 'node:crypto'; export function contextMiddleware( req: Request, res: Response, next: NextFunction ) { // 从请求头里取，网关层一般会附带这些信息 const token = req.headers['authorization']?.replace('Bearer ', ''); const userId = parseUserIdFromToken(token); // 解析逻辑略，实际项目里常用jwt或session const context: RequestContext = { requestId: req.headers['x-request-id'] ?? randomUUID(), userId, tenantId: req.headers['x-tenant-id'] as string | undefined, startTime: Date.now(), extra: {}, }; // 用run包裹整个请求生命周期 contextStorage.run(context, () => { // 确保响应结束时清理，其实run结束自动清理，但显式标记更保险 res.on('finish', () => { const duration = Date.now() - context.startTime; console.log(`[req] ${context.requestId} ${req.method} ${req.url} ${duration}ms`); }); next(); }); }// 任意业务代码中 import { getContext, getUser, getRequestId } from './context'; export async function fetchUserOrders() { const ctx = getContext(); if (!ctx?.userId) { throw new Error('未登录'); } // 直接把userId传给数据层查询，而不是从参数里一层层透传 const orders = await queryOrders(ctx.userId); return orders; }这段代码的核心价值在于：业务逻辑完全不感知上下文是怎么传进来的。无论是拦截器、中间件还是AOP，入口处run一下，业务代码里直接get，不需要改动任何函数签名。
3.3 生产环境里的几个坑，我挨个填过
第一，AsyncLocalStorage.run里的回调必须同步返回。你不能写成contextStorage.run(context, async () => { ... })然后指望run外面await到结果。异步操作在run内部执行当然没问题，但run本身不等待Promise。我推荐在中间件里用next()，或者在网关入口用contextStorage.run(..., () => main())这种同步调用，异步操作自然发生在链路内部。
第二，日志系统必须接上 requestId。否则上下文倒是隔离了，但排障时你还是看不出哪条日志属于哪个请求。我用的是 pino，可以直接在child里绑定：
const logger = pino().child({ requestId: getRequestId() });第三，别把整个数据库查询结果塞进extra里。上下文是常驻内存的，塞了大数据对象，请求结束后GC都救不了你。我见过有人往extra里放了一个1MB的报表对象，说是“后面可能要用”，结果内存直接告警。上下文只放索引、ID、枚举这类小字段，实时需要的大数据永远去缓存或数据库里取。
4. 后端落地二：Go 的 context.Context 与超时控制的正确姿势
如果说 Node.js 的 AsyncLocalStorage 是“幕后黑手”，那么 Go 的context.Context就是明牌了。Go 语言把上下文做成了标准库，江湖规矩是“context 必须是函数第一个参数”，变量名统一叫ctx。
4.1 为什么 Go 的规矩是“第一个参数传 ctx”
Go 没有异常机制，也没有线程局部变量，它的并发模型是 goroutine，一个 goroutine 里还能再开 goroutine。你根本没法用静态变量表示“当前请求”，因为同一个请求可能同时跑着几十个 goroutine。所以 Go 选择了最笨但最靠谱的方式：显式传递。
这也决定了 Go 的 context-mode 长这样：
context.Background()：整个应用的根上下文，基本只在main函数和测试里出现。context.TODO()：当你还没想好该传哪个上下文时，先用它占位，但绝不能上线。context.WithCancel/context.WithTimeout/context.WithDeadline/context.WithValue：从父上下文派生子上下文，构成一棵树。
4.2 一个完整的超时控制实战
我写过最多的 Go 服务就是从HTTP请求到数据库查询的链路。下面是一个典型的超时链路控制场景：
package main import ( "context" "database/sql" "fmt" "net/http" "time" ) func handler(db *sql.DB) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { // 从请求上下文派生一个带超时的子上下文 ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second) defer cancel() uid := r.Header.Get("X-User-Id") result, err := queryOrders(ctx, db, uid) if err != nil { // 超时或数据库错误，统一处理 http.Error(w, err.Error(), http.StatusGatewayTimeout) return } fmt.Fprintf(w, "orders: %v", result) } } func queryOrders(ctx context.Context, db *sql.DB, uid string) ([]string, error) { // 这个查询会接收ctx，数据库驱动会在ctx到期时取消查询 rows, err := db.QueryContext(ctx, "SELECT order_id FROM orders WHERE user_id = ?", uid) if err != nil { return nil, err } defer rows.Close() var ids []string for rows.Next() { var id string if err := rows.Scan(&id); err != nil { return nil, err } ids = append(ids, id) } return ids, rows.Err() }这个例子里最关键的是defer cancel()。很多人写成ctx, cancel := context.WithTimeout(...)之后忘了调用cancel，等超时触发自动取消。但如果你在超时前就成功返回了，子上下文不会被主动释放，它挂载的定时器会一直活着，直到超时那一刻才触发，高并发下会积累海量定时器，造成内存泄漏。所以defer cancel()不是可选项，是必选项。
4.3 一个我强烈反对的做法：往 context.WithValue 里塞业务参数
每次看到有人写出ctx = context.WithValue(ctx, "userId", userId)这种代码，我都想多问一句：你真的没有别的地方能传吗？
Go 官方文档对WithValue的定位是：仅用于传递跨API边界的请求级数据，比如 trace ID、认证信息、客户端IP。它不该承载核心业务参数。原因有三个：
一是不安全。WithValue返回的 value 是interface{}类型，编译期不做类型检查，取的时候还要做类型断言。一旦key拼错或者类型不对，运行时直接panic。
二是不可靠。子协程如果没有继承 ctx，值就取不到；而 Go lint 又禁止把 ctx 存在结构体里，所以只靠 value 传递业务参数，链路稍长就容易丢。
三是难以测试。一个函数依赖ctx.Value("userId")，意味着它的行为被隐藏参数控制了，单测还得先构造一个塞满值的ctx，非常别扭。
我见过一个老服务，从请求到消息队列到消费端，全靠 ctx.Value 传递用户ID，最后排查问题的时候，光是把整个链路里所有的key列出来就花了半天。这种代码，维护成本极高。
5. 前端视角：React Context 与“上下文模式”的边界
前面聊的都是后端，但 context-mode 在前端同样有价值，而且前端的坑比后端更隐蔽。
5.1 React Context 不是状态管理器，这是一个常见的错位
很多人把 React 的 Context API 当成全局状态管理器，随手建一个AppContext，把用户信息、主题、语言、购物车、各种配置全部塞进去。然后组件一多，你会发现：只要任何一个值变了，所有消费这个 Context 的组件全部重新渲染。这就是性能问题的源头。
Context API 的本质是依赖注入，它的设计目标是解决“跨层级传参”的问题，让你不用在每个中间组件上写props透传。它不是状态管理器，不具备选择器机制，也不该承载高频变化的业务状态。
5.2 我在前端项目中把 context-mode 落地的姿势
我对前端 context-mode 的实践，总结起来是四个原则：
原则一：按领域拆分 Context，而不是一个大而全的 AppContext。我把用户信息拆成AuthContext，把主题拆成ThemeContext，把多语言拆成LocaleContext。每个 Context 只负责一件独立的事，互不影响。组件消费数据时按需取用，拆开之后渲染范围也自然收窄。
原则二：Context 里的值尽量保持稳定。用useMemo包住 value，让依赖没变时引用不变，从而减少不必要的重新渲染。这个点新手最容易漏：
const AuthContext = createContext<AuthState>({ user: null, status: 'loading' }); export function AuthProvider({ children }: { children: React.ReactNode }) { const [user, setUser] = useState<User | null>(null); const [status, setStatus] = useState<'loading' | 'authenticated' | 'unauthenticated'>('loading'); // 没有useMemo时，每次render都会生成新对象，所有子组件跟着重渲染 const value = useMemo( () => ({ user, status, login: async (token: string) => { setStatus('loading'); const u = await fetchUser(token); setUser(u); setStatus('authenticated'); }, logout: () => { setUser(null); setStatus('unauthenticated'); }, }), [user, status] ); return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>; }原则三：高频变化的数据别放 Context，请交给请求库或组件本地 state。比如某个列表的轮询数据，用useState加useEffect拉取即可，不需要全局广播。只有那些“登录状态、路由信息、主题偏好”这类几乎不变的全局数据才适合 Context。
原则四：提供自定义 hook 作为唯一访问入口。业务组件里不直接useContext(AuthContext)，而是useAuth()。这样将来如果要从 Context 切换到外部状态库，只需改 hook 内部实现，业务组件一行都不用动：
export function useAuth() { const ctx = useContext(AuthContext); if (!ctx) { throw new Error('useAuth must be used within AuthProvider'); } return ctx; }5.3 前端 context-mode 最常见的三个误用，我逐个排过
误用一是把 Context 当成全局 store 存接口数据。页面一加载就把“所有好奇的数据”塞进 Context，美其名曰“缓存”或“共享”，结果数据过期了都不知道。
误用二是在 Context.Provider 的 value 里直接写内联对象，每天被 rerender 问题折磨。
误用三是缺少 Provider 的兜底保护。没有 Provider 时useContext返回默认值，但默认值经常是 undefined，业务代码容易空指针。我一般会设立“必须有 Provider”的约束，做不到就抛错，把问题暴露在启动阶段，总比运行时偶尔崩溃好。
6. context-mode 的边界：这些场景我劝你别硬套
任何模式都有适用范围，context-mode 也不是银弹。我踩过几次硬套的坑，分享几个“别用”的反向清单。
6.1 跨模块的长生命周期任务
context-mode 适合“一次操作内”的数据传递，不适合“跨天”的数据保留。比如用户的偏好设置、上次登录时间，这种数据放进 Redis 或数据库里慢慢读就行，放上下文里纯属占内存。
6.2 需要序列化和持久化的数据
一个 context 对象如果被序列化传给了消息队列，队列消费者再根据 context 恢复现场，这个模式看起来很美，但实施起来有大量边界：某些字段字段可能包含函数、数据库连接、复杂的不可序列化对象。我的建议是：消息队列里只传 ID 和必要条件，消费者自己重新组装上下文。
6.3 两层架构之间的“协议耦合”
如果你的 context 被上游服务设计成“万能的”，下游也依赖这个万能 context 里的很多字段，那上下游之间就形成了隐式协议耦合。上游改一个字段名，下游可能无声无息地挂掉。正确做法：通过 RPC 或 HTTP 接口显式定义参数，在接口边界做一次上下文到参数的显式映射。
7. 我在实际项目里沉淀的五条 context-mode 检查清单
最后把我内部分享时常用的一张检查清单放出来，你可以直接拿去当 code review 的参照。
第一，每个入口是否显式初始化了上下文？包括HTTP入口、消息消费入口、定时任务入口。定时任务尤其容易被忽略，因为它没有明确的“请求”，但一个批处理任务同样是一次需要隔离的生命周期。
第二，上下文内容是否足够小？我给自己定的标准是：context 里对象不超过 5 个字段，字段类型为 string、number、boolean、枚举 ID。超过就拆，或者重新考虑是否有必要放进去。
第三，异步操作是否无感继承了上下文？Node.js 用 AsyncLocalStorage，Go 用显式 ctx，Java 用 TransmittableThreadLocal（普通 ThreadLocal 在异步线程池下会丢）。如果你还在用原生 ThreadLocal 配线程池，一定要自查清理逻辑。
第四，日志里能不能靠 requestId 串联全链路？这是验证 context-mode 是否生效的最直接方式。打开日志系统，随便挑一个请求ID，从网关到数据库，所有日志应该能串成一条线。
第五，单元测试是否覆盖了“并发交叉”场景？我写过的一次最有效的测试，是用 100 个并发请求同时打某个接口，在每个请求里打印自己的用户ID，断言每个请求拿到的身份跟请求头一致。这种测试用 Node.js 的Promise.all或者 Go 的sync.WaitGroup很好写，能一次性暴露所有隐式共享问题。
写在最后
那次 ThreadLocal 引发的串号事故，最终修复只用了十分钟，但排查花了整整两天。之后我把所有涉及“上下文”的代码全部重构成显式模式，在 Node.js 服务里全部接上 AsyncLocalStorage，在 Go 服务里严格落实“第一个参数传 ctx”，前端也重新梳理了 Context 的边界。一年多过去，没有再出现过一次数据串号、身份错乱或上下文泄漏的问题。
如果你也正在被类似的偶发错误折磨，我建议你先别急着改业务代码，花半小时看看项目里所有“当前用户”“当前租户”“当前请求ID”是怎么传递的。如果它们出现在全局变量、静态变量、ThreadLocal 或者 props 地狱里，那你大概率找到了问题的种子。把上下文当成一等公民来设计，初期会觉得多余，长期看能省掉你无数个排查之夜。
