1. 从“上下文模式”说起一个被低估的工程概念第一次看到“context-mode”这个词很多人会以为是某个新出的框架或者库。其实不是。它更像是一种设计思路一种在系统里管理“上下文”这件事的工程模式。你可以在前端状态管理里见到它可以在后端请求链路里见到它也可以在大模型应用的会话管理里见到它。名字听起来抽象但落到代码里它解决的是一个非常具体的问题当多个模块、多个请求、多个用户同时需要读写同一份“上下文”时怎么保证数据不串、不丢、不乱。我最早接触这个概念是在做一个多轮对话系统的时候。当时系统里有一个全局的会话对象所有模块都直接引用它。结果就是A用户的对话历史偶尔会出现在B用户的界面上排查了两天才发现是异步回调里闭包捕获了错误的上下文引用。那次之后我才意识到上下文管理不是“随便传个对象”那么简单它需要一套明确的模式来约束。这篇文章适合谁看如果你正在做以下任何一件事那context-mode的讨论就跟你有关做多轮对话、Agent编排、会话状态管理做前端复杂表单或跨页面状态共享做后端微服务链路追踪、请求级缓存做任何需要“在多个异步环节中保持同一份数据一致性”的系统我会从设计思路、核心机制、实操落地、问题排查四个层面把context-mode这件事讲透。不是教科书式的定义而是我在实际项目里踩过坑之后总结出来的东西。2. 上下文模式到底在解决什么问题2.1 上下文不是“全局变量”的遮羞布很多人一提到上下文第一反应就是“搞个全局对象存着呗”。这在单线程、单用户的脚本里没问题但一旦进入并发场景全局对象就是灾难。上下文模式的核心价值是把“全局可变状态”转化为“受控的作用域状态”。举个生活化的例子。你去理发店前台给你一个手牌理发师、洗头工、收银员都认这个手牌。手牌就是你的上下文标识每个人拿到手牌后去系统里查对应的记录而不是所有人共享一个记事本。如果所有人共享一个记事本那同时来十个客人就乱套了。context-mode要做的就是这件事给每个独立的执行单元分配一个上下文标识所有操作都基于这个标识去读写而不是直接操作一个共享的大对象。2.2 三个典型场景下的上下文需求差异不同场景对上下文的要求差别很大不能一刀切。我整理了一个对比表场景类型上下文生命周期并发粒度典型痛点前端表单跨步骤用户操作期间单用户多步骤步骤间数据丢失、回退后状态不一致后端请求链路单次请求多请求并发异步回调中上下文丢失、链路追踪断链多轮对话系统整个会话多用户多会话会话串扰、历史消息膨胀、上下文窗口溢出这张表是我在实际项目中反复验证过的。你会发现虽然都叫“上下文”但生命周期和并发粒度完全不同。前端表单的上下文可能只活几分钟而后端请求的上下文可能只活几百毫秒对话系统的上下文可能活几小时甚至几天。设计context-mode时第一步就是明确你的上下文属于哪一类。2.3 为什么不用简单的参数传递有人会问我直接把上下文对象当参数一层层传下去不就行了可以但有几个问题。第一参数穿透。当调用链有七八层的时候每一层函数签名里都要加一个context参数代码会变得非常臃肿。第二异步断裂。在JavaScript的Promise链或者Python的asyncio里参数传递在await或then之后很容易丢失。第三中间件难以介入。如果你想在某个环节统一给上下文加日志、加超时、加权限校验参数传递的方式很难做到无侵入。context-mode的思路是上下文不通过参数显式传递而是通过一种“隐式携带”的机制让同一执行流中的任何环节都能访问到它。这就是所谓的“上下文传播”。3. 核心机制拆解上下文如何创建、传播与销毁3.1 上下文的创建时机与作用域绑定上下文的创建时机非常关键。创建太早会包含无关数据创建太晚会丢失早期信息。我的经验是在请求入口或会话入口创建在出口销毁。以Node.js为例一个HTTP请求进来的时候在第一个中间件里创建上下文const { AsyncLocalStorage } require(async_hooks); const als new AsyncLocalStorage(); function contextMiddleware(req, res, next) { const ctx { requestId: generateId(), userId: req.headers[x-user-id] || anonymous, startTime: Date.now(), metadata: {} }; als.run(ctx, () { next(); }); }这里用了AsyncLocalStorage它是Node.js官方提供的异步上下文传播机制。als.run(ctx, callback)的作用是在callback及其所有异步衍生调用中als.getStore()都会返回同一个ctx对象。这就实现了“隐式携带”。注意AsyncLocalStorage在Node.js 12.17.0以上才稳定低版本需要用cls-hooked这类第三方库替代。但cls-hooked在Node.js 16之后有一些兼容性问题建议尽量升级Node版本。3.2 上下文传播的三种实现路径不同语言和运行时对上下文传播的支持不一样我把它归纳为三种路径路径一运行时原生支持。比如Node.js的AsyncLocalStorage、Go的context.Context、Java的ThreadLocal配合线程池传递。这类方案最干净不需要改业务代码。路径二框架层封装。比如React的Context API、Vue的provide/inject。这类方案适合UI层但要注意不要滥用否则会导致组件重渲染失控。路径三手动传递加装饰器。在没有原生支持的环境里只能通过参数传递但可以用装饰器或AOP的方式减少侵入。比如Python里可以用contextvars配合装饰器。选择哪条路径取决于你的技术栈和团队习惯。我的建议是能用原生就用原生不能用原生就在框架层做统一封装最次才选手动传递。3.3 上下文的销毁与资源回收上下文销毁这件事很多人会忽略。创建了不销毁就是内存泄漏。特别是在长连接场景下每个连接一个上下文连接不断开上下文就不释放时间一长内存就爆了。销毁的时机一般有两个一是请求响应结束二是会话超时。对于请求级上下文在响应发送完毕后销毁对于会话级上下文需要设置TTLTime To Live定期清理过期会话。// 会话级上下文的TTL清理示例 const sessionStore new Map(); const SESSION_TTL 30 * 60 * 1000; // 30分钟 function createSession(userId) { const sessionId generateId(); sessionStore.set(sessionId, { userId, createdAt: Date.now(), lastAccessAt: Date.now(), data: {} }); return sessionId; } // 定期清理过期会话 setInterval(() { const now Date.now(); for (const [id, session] of sessionStore) { if (now - session.lastAccessAt SESSION_TTL) { sessionStore.delete(id); } } }, 60 * 1000);实操心得TTL不要设得太短否则用户操作到一半会话就过期了也不要设得太长否则内存回收不及时。我一般会根据业务的操作时长分布来定取P95操作时长的两到三倍比较稳妥。4. 实操落地从零搭建一个上下文管理模式4.1 定义上下文的数据结构上下文里放什么直接决定了后续代码的复杂度。放太少到处都要额外查询放太多序列化和传输成本高。我的原则是只放“跨环节必须共享”的数据其余数据按需查询。一个典型的请求级上下文结构{ requestId: req_abc123, // 链路追踪标识 userId: user_456, // 用户标识 traceId: trace_xyz789, // 分布式追踪标识 startTime: 1700000000000, // 请求开始时间 locale: zh-CN, // 语言偏好 featureFlags: {}, // 功能开关快照 metadata: {} // 业务自定义数据 }注意featureFlags这个字段。把功能开关的快照放在上下文里可以保证同一个请求内所有环节看到的功能开关状态是一致的。如果不这样做请求处理到一半开关变了就会出现前后逻辑不一致的问题。4.2 在中间件层统一注入上下文中间件是注入上下文的最佳位置因为它在业务逻辑之前执行且对所有路由生效。以Express为例const { AsyncLocalStorage } require(async_hooks); const als new AsyncLocalStorage(); // 上下文注入中间件 app.use((req, res, next) { const ctx { requestId: req.headers[x-request-id] || generateId(), userId: req.headers[x-user-id] || anonymous, startTime: Date.now(), locale: req.headers[accept-language] || zh-CN, featureFlags: loadFeatureFlags(req.headers[x-user-id]), metadata: {} }; als.run(ctx, () { // 响应结束时记录耗时 res.on(finish, () { const duration Date.now() - ctx.startTime; logger.info({ requestId: ctx.requestId, userId: ctx.userId, duration, path: req.path, status: res.statusCode }); }); next(); }); }); // 业务代码中获取上下文 function getContext() { return als.getStore(); }这段代码做了三件事创建上下文、注入上下文、在响应结束时记录日志。日志里带上了requestId和userId后续排查问题时可以直接按这两个字段过滤。4.3 上下文在异步链路中的传递验证注入之后必须验证上下文在异步链路中是否真的能传递下去。我写了一个简单的验证脚本async function testContextPropagation() { const ctx getContext(); console.log(同步环节:, ctx.requestId); await new Promise(resolve setTimeout(resolve, 10)); console.log(setTimeout之后:, getContext().requestId); await Promise.resolve(); console.log(Promise之后:, getContext().requestId); await new Promise(resolve { process.nextTick(() { console.log(nextTick之后:, getContext().requestId); resolve(); }); }); const results await Promise.all([ asyncOperation1(), asyncOperation2() ]); console.log(并发操作之后:, getContext().requestId); }实测下来AsyncLocalStorage在setTimeout、Promise、nextTick、Promise.all这些常见异步场景下都能正确传递。但有一个坑如果你用了某些第三方库它们内部用了自己的异步调度机制可能会丢失上下文。比如某些数据库连接池的回调、某些消息队列的消费者回调。遇到这种情况需要在库的回调入口手动重新绑定上下文。4.4 上下文与日志系统的整合上下文最大的价值之一就是让日志有了“归属”。没有上下文的日志是一盘散沙有了上下文每条日志都能追溯到具体的请求和用户。// 日志封装 function log(level, message, extra {}) { const ctx getContext() || {}; const entry { timestamp: new Date().toISOString(), level, message, requestId: ctx.requestId, userId: ctx.userId, traceId: ctx.traceId, ...extra }; console.log(JSON.stringify(entry)); } // 使用 log(info, 用户查询订单, { orderId: order_001 }); log(error, 库存扣减失败, { skuId: sku_002, reason: insufficient });这样输出的日志是结构化的JSON可以直接被日志采集系统解析。排查问题时用requestId一搜整个请求链路的所有日志都出来了。5. 常见问题与排查技巧实录5.1 上下文丢失的典型场景与定位方法上下文丢失是最常见的问题。表现是在某个环节getContext()返回undefined。我整理了几种典型场景丢失场景原因解决方案第三方库回调库内部用了独立的异步调度在回调入口手动绑定上下文事件监听器事件触发时已脱离原异步链创建监听器时捕获上下文触发时恢复定时任务定时器在上下文销毁后触发定时任务独立创建上下文跨进程调用上下文无法跨进程自动传播通过请求头或消息属性显式传递定位方法很简单在怀疑丢失的地方打印getContext()看返回什么。如果返回undefined就往上游找看是在哪一步断的。5.2 上下文数据膨胀的治理策略上下文用久了很容易变成“什么都往里塞”的垃圾桶。我见过一个项目上下文对象里塞了几十个字段序列化之后有几十KB每次跨服务调用都要传输性能很差。治理策略有三条第一定期审计。每个月review一次上下文里的字段问三个问题这个字段真的需要跨环节共享吗能不能改成按需查询能不能放到metadata里按需加载第二设置大小上限。在上下文创建时检查字段数量超过阈值就告警。第三区分“热数据”和“冷数据”。热数据放上下文冷数据放外部存储上下文里只存一个引用ID。5.3 多线程与协程环境下的上下文隔离在Java的线程池或者Python的协程池里上下文隔离是个大问题。线程池里的线程是复用的如果上一个任务的上下文没清理干净下一个任务就会读到脏数据。Java里的做法是用ThreadLocal配合try-finally清理public void handleRequest(Request req) { try { Context ctx new Context(req); ContextHolder.set(ctx); // 业务逻辑 } finally { ContextHolder.clear(); // 必须清理 } }Python的asyncio里用contextvarsimport contextvars request_context contextvars.ContextVar(request_context) async def handle_request(request): ctx create_context(request) token request_context.set(ctx) try: await process(ctx) finally: request_context.reset(token)注意contextvars的set和reset必须成对出现否则会污染后续任务。我踩过一次坑在异常分支里忘了reset结果后面所有请求都读到了错误的上下文。5.4 上下文版本兼容与灰度发布当上下文结构发生变化时比如新增字段、重命名字段需要考虑版本兼容。特别是在微服务架构下不同服务可能部署了不同版本的代码新旧上下文结构并存。我的做法是在上下文里加一个version字段消费方根据版本号做兼容处理function readContextField(ctx, fieldName) { if (ctx.version 2 fieldName newField) { return ctx.newField; } // 兼容旧版本 return ctx.oldField; }灰度发布时先让新版本服务同时支持新旧两种上下文等所有服务都升级完毕再移除旧字段的兼容代码。6. 上下文模式在大模型应用中的特殊考量6.1 对话上下文与请求上下文的区别大模型应用里的“上下文”和传统后端请求的上下文有本质区别。传统请求上下文是“一次请求内共享的数据”而对话上下文是“跨多次请求累积的对话历史”。这两者需要分开管理。我的做法是请求上下文用AsyncLocalStorage管理对话上下文用独立的会话存储管理。请求上下文里只放一个sessionId指向对话上下文。// 请求上下文 { requestId: req_001, userId: user_456, sessionId: sess_789 // 指向对话上下文 } // 对话上下文独立存储 { sessionId: sess_789, userId: user_456, messages: [ { role: user, content: ... }, { role: assistant, content: ... } ], createdAt: 1700000000000, lastAccessAt: 1700000100000 }6.2 上下文窗口溢出的处理策略大模型的上下文窗口是有限的对话历史不能无限增长。常见的处理策略有三种策略一滑动窗口。只保留最近N轮对话超出的丢弃。简单但会丢失早期信息。策略二摘要压缩。把早期对话用模型总结成一段摘要保留摘要加最近N轮。信息保留更完整但需要额外的模型调用。策略三向量检索。把历史对话存入向量库每轮根据当前问题检索相关历史。适合长对话但实现复杂度高。我一般用策略二在对话轮数超过阈值时触发摘要。摘要的prompt大概是“请用200字以内总结以下对话的关键信息保留用户偏好、已确认的事实和未完成的任务。”6.3 多用户并发下的会话隔离验证多用户并发时会话串扰是最危险的问题。我写过一个压力测试脚本模拟100个用户同时对话每个用户发送10轮消息然后检查每个用户的对话历史是否只包含自己的消息。async function testSessionIsolation() { const users Array.from({ length: 100 }, (_, i) user_${i}); const results await Promise.all( users.map(async (userId) { const sessionId await createSession(userId); for (let i 0; i 10; i) { await sendMessage(sessionId, 消息${i}); } const history await getHistory(sessionId); const hasOtherUserMessage history.some( msg msg.userId ! userId ); return { userId, hasOtherUserMessage }; }) ); const leaked results.filter(r r.hasOtherUserMessage); console.log(串扰用户数: ${leaked.length}); }这个测试跑下来如果串扰数为0说明会话隔离是可靠的。如果有串扰就要检查sessionId的生成和查找逻辑看是否有并发写入冲突。7. 一些踩坑之后的经验之谈上下文模式这件事说起来简单做起来细节很多。我最大的体会是不要试图用一个上下文解决所有问题。请求级上下文、会话级上下文、用户级上下文它们的生命周期和并发特性完全不同混在一起管理只会让代码越来越乱。另一个体会是上下文的字段宁少勿多。每加一个字段都要问自己这个字段真的需要跨环节共享吗如果只是某个环节自己用的就放在那个环节的局部变量里不要污染上下文。还有一个容易被忽略的点上下文的序列化成本。如果你要把上下文跨进程传递序列化和反序列化的开销就不能忽视。我见过一个项目上下文里放了一个大数组每次跨服务调用都要序列化几百KBQPS一高就成了瓶颈。后来把大数组改成按需查询性能立刻上来了。最后分享一个小技巧在开发环境里可以给上下文加一个debug字段记录每个环节对上下文的读写操作。上线前把这个字段关掉。这样排查上下文相关问题时能直接看到完整的读写轨迹比打断点高效得多。这个模式后续还可以往几个方向扩展一是上下文与权限系统的结合把权限校验结果缓存在上下文里避免重复计算二是上下文与链路追踪的深度整合把span信息直接放进上下文三是上下文的自动化测试用mock上下文来验证各环节的行为。这些方向我在后续项目里会继续实践有新的心得再整理出来。 
长河君 · 2026/10/20 4:29:12 · 阅读 1.2k 上下文模式实战：从异步链路到多轮对话的上下文管理
1. 从“上下文模式”说起一个被低估的工程概念第一次看到“context-mode”这个词很多人会以为是某个新出的框架或者库。其实不是。它更像是一种设计思路一种在系统里管理“上下文”这件事的工程模式。你可以在前端状态管理里见到它可以在后端请求链路里见到它也可以在大模型应用的会话管理里见到它。名字听起来抽象但落到代码里它解决的是一个非常具体的问题当多个模块、多个请求、多个用户同时需要读写同一份“上下文”时怎么保证数据不串、不丢、不乱。我最早接触这个概念是在做一个多轮对话系统的时候。当时系统里有一个全局的会话对象所有模块都直接引用它。结果就是A用户的对话历史偶尔会出现在B用户的界面上排查了两天才发现是异步回调里闭包捕获了错误的上下文引用。那次之后我才意识到上下文管理不是“随便传个对象”那么简单它需要一套明确的模式来约束。这篇文章适合谁看如果你正在做以下任何一件事那context-mode的讨论就跟你有关做多轮对话、Agent编排、会话状态管理做前端复杂表单或跨页面状态共享做后端微服务链路追踪、请求级缓存做任何需要“在多个异步环节中保持同一份数据一致性”的系统我会从设计思路、核心机制、实操落地、问题排查四个层面把context-mode这件事讲透。不是教科书式的定义而是我在实际项目里踩过坑之后总结出来的东西。2. 上下文模式到底在解决什么问题2.1 上下文不是“全局变量”的遮羞布很多人一提到上下文第一反应就是“搞个全局对象存着呗”。这在单线程、单用户的脚本里没问题但一旦进入并发场景全局对象就是灾难。上下文模式的核心价值是把“全局可变状态”转化为“受控的作用域状态”。举个生活化的例子。你去理发店前台给你一个手牌理发师、洗头工、收银员都认这个手牌。手牌就是你的上下文标识每个人拿到手牌后去系统里查对应的记录而不是所有人共享一个记事本。如果所有人共享一个记事本那同时来十个客人就乱套了。context-mode要做的就是这件事给每个独立的执行单元分配一个上下文标识所有操作都基于这个标识去读写而不是直接操作一个共享的大对象。2.2 三个典型场景下的上下文需求差异不同场景对上下文的要求差别很大不能一刀切。我整理了一个对比表场景类型上下文生命周期并发粒度典型痛点前端表单跨步骤用户操作期间单用户多步骤步骤间数据丢失、回退后状态不一致后端请求链路单次请求多请求并发异步回调中上下文丢失、链路追踪断链多轮对话系统整个会话多用户多会话会话串扰、历史消息膨胀、上下文窗口溢出这张表是我在实际项目中反复验证过的。你会发现虽然都叫“上下文”但生命周期和并发粒度完全不同。前端表单的上下文可能只活几分钟而后端请求的上下文可能只活几百毫秒对话系统的上下文可能活几小时甚至几天。设计context-mode时第一步就是明确你的上下文属于哪一类。2.3 为什么不用简单的参数传递有人会问我直接把上下文对象当参数一层层传下去不就行了可以但有几个问题。第一参数穿透。当调用链有七八层的时候每一层函数签名里都要加一个context参数代码会变得非常臃肿。第二异步断裂。在JavaScript的Promise链或者Python的asyncio里参数传递在await或then之后很容易丢失。第三中间件难以介入。如果你想在某个环节统一给上下文加日志、加超时、加权限校验参数传递的方式很难做到无侵入。context-mode的思路是上下文不通过参数显式传递而是通过一种“隐式携带”的机制让同一执行流中的任何环节都能访问到它。这就是所谓的“上下文传播”。3. 核心机制拆解上下文如何创建、传播与销毁3.1 上下文的创建时机与作用域绑定上下文的创建时机非常关键。创建太早会包含无关数据创建太晚会丢失早期信息。我的经验是在请求入口或会话入口创建在出口销毁。以Node.js为例一个HTTP请求进来的时候在第一个中间件里创建上下文const { AsyncLocalStorage } require(async_hooks); const als new AsyncLocalStorage(); function contextMiddleware(req, res, next) { const ctx { requestId: generateId(), userId: req.headers[x-user-id] || anonymous, startTime: Date.now(), metadata: {} }; als.run(ctx, () { next(); }); }这里用了AsyncLocalStorage它是Node.js官方提供的异步上下文传播机制。als.run(ctx, callback)的作用是在callback及其所有异步衍生调用中als.getStore()都会返回同一个ctx对象。这就实现了“隐式携带”。注意AsyncLocalStorage在Node.js 12.17.0以上才稳定低版本需要用cls-hooked这类第三方库替代。但cls-hooked在Node.js 16之后有一些兼容性问题建议尽量升级Node版本。3.2 上下文传播的三种实现路径不同语言和运行时对上下文传播的支持不一样我把它归纳为三种路径路径一运行时原生支持。比如Node.js的AsyncLocalStorage、Go的context.Context、Java的ThreadLocal配合线程池传递。这类方案最干净不需要改业务代码。路径二框架层封装。比如React的Context API、Vue的provide/inject。这类方案适合UI层但要注意不要滥用否则会导致组件重渲染失控。路径三手动传递加装饰器。在没有原生支持的环境里只能通过参数传递但可以用装饰器或AOP的方式减少侵入。比如Python里可以用contextvars配合装饰器。选择哪条路径取决于你的技术栈和团队习惯。我的建议是能用原生就用原生不能用原生就在框架层做统一封装最次才选手动传递。3.3 上下文的销毁与资源回收上下文销毁这件事很多人会忽略。创建了不销毁就是内存泄漏。特别是在长连接场景下每个连接一个上下文连接不断开上下文就不释放时间一长内存就爆了。销毁的时机一般有两个一是请求响应结束二是会话超时。对于请求级上下文在响应发送完毕后销毁对于会话级上下文需要设置TTLTime To Live定期清理过期会话。// 会话级上下文的TTL清理示例 const sessionStore new Map(); const SESSION_TTL 30 * 60 * 1000; // 30分钟 function createSession(userId) { const sessionId generateId(); sessionStore.set(sessionId, { userId, createdAt: Date.now(), lastAccessAt: Date.now(), data: {} }); return sessionId; } // 定期清理过期会话 setInterval(() { const now Date.now(); for (const [id, session] of sessionStore) { if (now - session.lastAccessAt SESSION_TTL) { sessionStore.delete(id); } } }, 60 * 1000);实操心得TTL不要设得太短否则用户操作到一半会话就过期了也不要设得太长否则内存回收不及时。我一般会根据业务的操作时长分布来定取P95操作时长的两到三倍比较稳妥。4. 实操落地从零搭建一个上下文管理模式4.1 定义上下文的数据结构上下文里放什么直接决定了后续代码的复杂度。放太少到处都要额外查询放太多序列化和传输成本高。我的原则是只放“跨环节必须共享”的数据其余数据按需查询。一个典型的请求级上下文结构{ requestId: req_abc123, // 链路追踪标识 userId: user_456, // 用户标识 traceId: trace_xyz789, // 分布式追踪标识 startTime: 1700000000000, // 请求开始时间 locale: zh-CN, // 语言偏好 featureFlags: {}, // 功能开关快照 metadata: {} // 业务自定义数据 }注意featureFlags这个字段。把功能开关的快照放在上下文里可以保证同一个请求内所有环节看到的功能开关状态是一致的。如果不这样做请求处理到一半开关变了就会出现前后逻辑不一致的问题。4.2 在中间件层统一注入上下文中间件是注入上下文的最佳位置因为它在业务逻辑之前执行且对所有路由生效。以Express为例const { AsyncLocalStorage } require(async_hooks); const als new AsyncLocalStorage(); // 上下文注入中间件 app.use((req, res, next) { const ctx { requestId: req.headers[x-request-id] || generateId(), userId: req.headers[x-user-id] || anonymous, startTime: Date.now(), locale: req.headers[accept-language] || zh-CN, featureFlags: loadFeatureFlags(req.headers[x-user-id]), metadata: {} }; als.run(ctx, () { // 响应结束时记录耗时 res.on(finish, () { const duration Date.now() - ctx.startTime; logger.info({ requestId: ctx.requestId, userId: ctx.userId, duration, path: req.path, status: res.statusCode }); }); next(); }); }); // 业务代码中获取上下文 function getContext() { return als.getStore(); }这段代码做了三件事创建上下文、注入上下文、在响应结束时记录日志。日志里带上了requestId和userId后续排查问题时可以直接按这两个字段过滤。4.3 上下文在异步链路中的传递验证注入之后必须验证上下文在异步链路中是否真的能传递下去。我写了一个简单的验证脚本async function testContextPropagation() { const ctx getContext(); console.log(同步环节:, ctx.requestId); await new Promise(resolve setTimeout(resolve, 10)); console.log(setTimeout之后:, getContext().requestId); await Promise.resolve(); console.log(Promise之后:, getContext().requestId); await new Promise(resolve { process.nextTick(() { console.log(nextTick之后:, getContext().requestId); resolve(); }); }); const results await Promise.all([ asyncOperation1(), asyncOperation2() ]); console.log(并发操作之后:, getContext().requestId); }实测下来AsyncLocalStorage在setTimeout、Promise、nextTick、Promise.all这些常见异步场景下都能正确传递。但有一个坑如果你用了某些第三方库它们内部用了自己的异步调度机制可能会丢失上下文。比如某些数据库连接池的回调、某些消息队列的消费者回调。遇到这种情况需要在库的回调入口手动重新绑定上下文。4.4 上下文与日志系统的整合上下文最大的价值之一就是让日志有了“归属”。没有上下文的日志是一盘散沙有了上下文每条日志都能追溯到具体的请求和用户。// 日志封装 function log(level, message, extra {}) { const ctx getContext() || {}; const entry { timestamp: new Date().toISOString(), level, message, requestId: ctx.requestId, userId: ctx.userId, traceId: ctx.traceId, ...extra }; console.log(JSON.stringify(entry)); } // 使用 log(info, 用户查询订单, { orderId: order_001 }); log(error, 库存扣减失败, { skuId: sku_002, reason: insufficient });这样输出的日志是结构化的JSON可以直接被日志采集系统解析。排查问题时用requestId一搜整个请求链路的所有日志都出来了。5. 常见问题与排查技巧实录5.1 上下文丢失的典型场景与定位方法上下文丢失是最常见的问题。表现是在某个环节getContext()返回undefined。我整理了几种典型场景丢失场景原因解决方案第三方库回调库内部用了独立的异步调度在回调入口手动绑定上下文事件监听器事件触发时已脱离原异步链创建监听器时捕获上下文触发时恢复定时任务定时器在上下文销毁后触发定时任务独立创建上下文跨进程调用上下文无法跨进程自动传播通过请求头或消息属性显式传递定位方法很简单在怀疑丢失的地方打印getContext()看返回什么。如果返回undefined就往上游找看是在哪一步断的。5.2 上下文数据膨胀的治理策略上下文用久了很容易变成“什么都往里塞”的垃圾桶。我见过一个项目上下文对象里塞了几十个字段序列化之后有几十KB每次跨服务调用都要传输性能很差。治理策略有三条第一定期审计。每个月review一次上下文里的字段问三个问题这个字段真的需要跨环节共享吗能不能改成按需查询能不能放到metadata里按需加载第二设置大小上限。在上下文创建时检查字段数量超过阈值就告警。第三区分“热数据”和“冷数据”。热数据放上下文冷数据放外部存储上下文里只存一个引用ID。5.3 多线程与协程环境下的上下文隔离在Java的线程池或者Python的协程池里上下文隔离是个大问题。线程池里的线程是复用的如果上一个任务的上下文没清理干净下一个任务就会读到脏数据。Java里的做法是用ThreadLocal配合try-finally清理public void handleRequest(Request req) { try { Context ctx new Context(req); ContextHolder.set(ctx); // 业务逻辑 } finally { ContextHolder.clear(); // 必须清理 } }Python的asyncio里用contextvarsimport contextvars request_context contextvars.ContextVar(request_context) async def handle_request(request): ctx create_context(request) token request_context.set(ctx) try: await process(ctx) finally: request_context.reset(token)注意contextvars的set和reset必须成对出现否则会污染后续任务。我踩过一次坑在异常分支里忘了reset结果后面所有请求都读到了错误的上下文。5.4 上下文版本兼容与灰度发布当上下文结构发生变化时比如新增字段、重命名字段需要考虑版本兼容。特别是在微服务架构下不同服务可能部署了不同版本的代码新旧上下文结构并存。我的做法是在上下文里加一个version字段消费方根据版本号做兼容处理function readContextField(ctx, fieldName) { if (ctx.version 2 fieldName newField) { return ctx.newField; } // 兼容旧版本 return ctx.oldField; }灰度发布时先让新版本服务同时支持新旧两种上下文等所有服务都升级完毕再移除旧字段的兼容代码。6. 上下文模式在大模型应用中的特殊考量6.1 对话上下文与请求上下文的区别大模型应用里的“上下文”和传统后端请求的上下文有本质区别。传统请求上下文是“一次请求内共享的数据”而对话上下文是“跨多次请求累积的对话历史”。这两者需要分开管理。我的做法是请求上下文用AsyncLocalStorage管理对话上下文用独立的会话存储管理。请求上下文里只放一个sessionId指向对话上下文。// 请求上下文 { requestId: req_001, userId: user_456, sessionId: sess_789 // 指向对话上下文 } // 对话上下文独立存储 { sessionId: sess_789, userId: user_456, messages: [ { role: user, content: ... }, { role: assistant, content: ... } ], createdAt: 1700000000000, lastAccessAt: 1700000100000 }6.2 上下文窗口溢出的处理策略大模型的上下文窗口是有限的对话历史不能无限增长。常见的处理策略有三种策略一滑动窗口。只保留最近N轮对话超出的丢弃。简单但会丢失早期信息。策略二摘要压缩。把早期对话用模型总结成一段摘要保留摘要加最近N轮。信息保留更完整但需要额外的模型调用。策略三向量检索。把历史对话存入向量库每轮根据当前问题检索相关历史。适合长对话但实现复杂度高。我一般用策略二在对话轮数超过阈值时触发摘要。摘要的prompt大概是“请用200字以内总结以下对话的关键信息保留用户偏好、已确认的事实和未完成的任务。”6.3 多用户并发下的会话隔离验证多用户并发时会话串扰是最危险的问题。我写过一个压力测试脚本模拟100个用户同时对话每个用户发送10轮消息然后检查每个用户的对话历史是否只包含自己的消息。async function testSessionIsolation() { const users Array.from({ length: 100 }, (_, i) user_${i}); const results await Promise.all( users.map(async (userId) { const sessionId await createSession(userId); for (let i 0; i 10; i) { await sendMessage(sessionId, 消息${i}); } const history await getHistory(sessionId); const hasOtherUserMessage history.some( msg msg.userId ! userId ); return { userId, hasOtherUserMessage }; }) ); const leaked results.filter(r r.hasOtherUserMessage); console.log(串扰用户数: ${leaked.length}); }这个测试跑下来如果串扰数为0说明会话隔离是可靠的。如果有串扰就要检查sessionId的生成和查找逻辑看是否有并发写入冲突。7. 一些踩坑之后的经验之谈上下文模式这件事说起来简单做起来细节很多。我最大的体会是不要试图用一个上下文解决所有问题。请求级上下文、会话级上下文、用户级上下文它们的生命周期和并发特性完全不同混在一起管理只会让代码越来越乱。另一个体会是上下文的字段宁少勿多。每加一个字段都要问自己这个字段真的需要跨环节共享吗如果只是某个环节自己用的就放在那个环节的局部变量里不要污染上下文。还有一个容易被忽略的点上下文的序列化成本。如果你要把上下文跨进程传递序列化和反序列化的开销就不能忽视。我见过一个项目上下文里放了一个大数组每次跨服务调用都要序列化几百KBQPS一高就成了瓶颈。后来把大数组改成按需查询性能立刻上来了。最后分享一个小技巧在开发环境里可以给上下文加一个debug字段记录每个环节对上下文的读写操作。上线前把这个字段关掉。这样排查上下文相关问题时能直接看到完整的读写轨迹比打断点高效得多。这个模式后续还可以往几个方向扩展一是上下文与权限系统的结合把权限校验结果缓存在上下文里避免重复计算二是上下文与链路追踪的深度整合把span信息直接放进上下文三是上下文的自动化测试用mock上下文来验证各环节的行为。这些方向我在后续项目里会继续实践有新的心得再整理出来。