1. 从“上下文模式”说起一个被低估的工程概念第一次看到“context-mode”这个词很多人会以为是某个新出的框架或者库。其实不是。它更像是一种设计思路一种在系统里管理“上下文”这件事的工程模式。你可以在前端状态管理里见到它可以在后端请求链路里见到它也可以在大模型应用里见到它。名字听起来抽象但落到代码里它解决的是一个非常具体的问题当一次操作需要跨越多个层级、多个模块、多个异步阶段时怎么保证每一步都能拿到它该拿到的信息同时不把整个系统搞成一团乱麻。我最早接触这个概念是在做一个跨平台的数据同步工具时。当时的需求很简单用户在A端改了数据B端要能感知到并且B端在渲染时还要知道“这次改动是谁触发的、在什么场景下触发的、需不需要弹提示”。一开始我们用的是全局变量加事件总线结果就是到处都在读全局状态改一个地方崩三个地方。后来换成显式传递上下文对象代码干净了不少但每个函数都要多一个参数调用链一长就特别啰嗦。直到有人提出“能不能让上下文自己跟着调用链走”我们才开始认真研究context-mode这类模式。所以这篇文章想聊的不是某个具体的库怎么用而是context-mode背后的设计逻辑、常见实现方式、实操中怎么选型、以及踩过哪些坑。如果你正在做多端同步、请求链路追踪、状态管理、或者大模型应用里的会话管理这篇文章应该能帮你少走一些弯路。即使你只是写业务代码理解上下文模式也能让你在拆分模块时更有章法。2. 上下文模式到底在解决什么问题2.1 什么是“上下文”为什么它容易失控先把这个词拆开看。“上下文”在工程里通常指一次操作所依赖的环境信息。比如一次HTTP请求它的上下文可能包括用户身份、请求ID、租户标识、语言偏好、权限范围、超时设置、重试次数。这些东西的特点是它们不是业务逻辑的核心但业务逻辑的每一步都可能需要它们。问题就出在这里。业务逻辑的核心是“做什么”上下文是“在什么条件下做”。如果上下文管理得不好就会出现几种典型症状隐式依赖某个函数内部直接读了全局变量调用者根本不知道它依赖了什么。参数爆炸为了显式传递每个函数签名都多出五六个参数调用链一深就没人愿意维护。生命周期混乱上下文在异步操作中被意外修改导致后续步骤拿到的是脏数据。跨层丢失中间件里设置的上下文到了业务层就找不到了只能靠线程本地存储或者全局单例硬撑。我见过一个最夸张的例子一个订单系统里为了传递“当前操作人”这个信息从Controller到Service到DAO每一层都加了一个operatorId参数。后来要加一个“操作来源渠道”又加了一个channel参数。再后来要加“请求追踪ID”又加了一个。最后函数签名长得像火车新人根本不敢改。2.2 context-mode的核心思路让上下文“跟着走”而不是“到处传”context-mode的核心思路其实一句话就能说清楚把上下文绑定到一次执行单元上让它在整个执行链路中自动可见而不是靠参数一层层传。这里的“执行单元”可以是一次请求、一次任务、一次会话、一次渲染。绑定方式在不同技术栈里不一样在后端常见的是用线程本地存储ThreadLocal或者异步本地存储AsyncLocalStorage。在前端常见的是用React Context、Vue provide/inject或者状态管理库里的“作用域”。在Node.js里AsyncLocalStorage是官方提供的方案可以在异步调用链中保持上下文。在大模型应用里上下文模式通常表现为“会话状态”或者“对话历史”的管理。关键区别在于参数传递是显式的、逐层的上下文模式是隐式的、跨层的。隐式不代表不可控只要设计得当它反而能让代码更干净因为业务逻辑不需要关心上下文的传递细节。2.3 和其他模式的边界别把什么都塞进上下文这里要特别提醒一点上下文模式不是万能的也不是什么都能往里塞。我见过有人把数据库连接、缓存客户端、配置对象全塞进上下文结果上下文变成了一个“万能袋子”谁都可以往里加东西最后没人知道里面有什么。一个比较健康的边界是放进去的请求级、会话级、任务级的元信息比如追踪ID、用户身份、租户、语言、权限快照。不放进去的业务数据、领域对象、数据库连接、全局配置。这些应该通过依赖注入或者模块导入来管理。判断标准很简单如果这个信息在一次执行单元结束后就应该消失那它适合放上下文如果它跨执行单元存在那它应该放在更持久的地方。3. 常见实现方案与选型对比3.1 后端场景ThreadLocal vs AsyncLocalStorage在后端最传统的做法是ThreadLocal。每个请求由一个线程处理上下文存在线程本地变量里业务代码随时可以取。这个方案在同步阻塞模型下工作得很好但一旦引入异步比如CompletableFuture、协程、响应式编程线程会切换ThreadLocal里的数据就跟不过去了。AsyncLocalStorage或者类似机制解决了这个问题。它把上下文绑定到异步调用链上而不是线程上。Node.js从v12.17开始提供这个能力Java生态里也有类似的东西比如阿里开源的TransmittableThreadLocal。方案适用场景优点缺点ThreadLocal同步阻塞、线程模型固定简单、性能好异步切换线程后丢失AsyncLocalStorage异步、Promise、async/await跨异步链路保持需要运行时支持调试稍复杂显式参数传递调用链短、上下文少最透明、无魔法参数爆炸维护成本高依赖注入容器大型应用、模块化清晰生命周期可控配置复杂学习曲线陡我个人的经验是如果调用链超过三层而且上下文项超过三个就应该考虑用上下文模式而不是参数传递。但如果你只是写一个简单的工具函数那就别引入上下文直接传参最清楚。3.2 前端场景React Context与状态管理前端的情况有点不一样。React Context本质上是一种“跨组件树传递数据”的机制它解决的问题是prop drilling属性逐层传递。但React Context有一个众所周知的性能问题当Context的值变化时所有消费该Context的组件都会重新渲染。所以在前端用上下文模式时通常要做两件事拆分Context不要把用户信息、主题、语言、权限全放在一个Context里。按更新频率和消费范围拆开。配合选择器用useContextSelector或者状态管理库的选择器能力只订阅自己关心的部分。Vue的provide/inject也有类似的问题但Vue的响应式系统会自动追踪依赖所以性能上通常比React Context好一些。不过如果provide的值是一个大对象而且经常变同样会导致不必要的更新。3.3 大模型应用会话上下文的管理在大模型应用里context-mode这个词出现的频率越来越高。这里的“上下文”通常指对话历史、系统提示、工具调用结果、用户偏好等。管理这些上下文的核心挑战是长度限制模型的上下文窗口有限不能无限追加。相关性不是所有历史消息都对当前问题有用需要做筛选或摘要。一致性多轮对话中上下文要保持连贯不能前后矛盾。隔离性不同用户的会话必须严格隔离不能串。常见的做法是维护一个“会话状态对象”里面包含消息列表、摘要、关键实体、当前任务状态。每次请求时根据策略决定把哪些内容放进模型的上下文窗口。这个策略可以是滑动窗口、摘要压缩、向量检索、或者混合方案。提示在大模型应用里上下文管理直接决定了回答质量和成本。上下文太长成本高且容易跑偏上下文太短模型记不住关键信息。这个平衡点需要根据业务场景反复调。4. 实操从零实现一个轻量级上下文管理器4.1 需求定义与接口设计假设我们要做一个任务处理系统每个任务需要携带以下上下文任务ID、发起人、租户、语言、追踪ID。任务处理过程中会经过多个异步步骤每个步骤都可能需要读取这些信息。我们先定义接口interface TaskContext { taskId: string; operator: string; tenant: string; locale: string; traceId: string; } interface ContextManager { runT(context: TaskContext, fn: () PromiseT): PromiseT; get(): TaskContext | undefined; setK extends keyof TaskContext(key: K, value: TaskContext[K]): void; }这里的设计意图是run方法负责在一个新的上下文作用域里执行函数get方法在作用域内任意位置获取当前上下文set方法允许在作用域内修改部分字段。4.2 基于AsyncLocalStorage的实现Node.js环境下用AsyncLocalStorage实现最直接import { AsyncLocalStorage } from async_hooks; const storage new AsyncLocalStorageTaskContext(); export const contextManager: ContextManager { runT(context: TaskContext, fn: () PromiseT): PromiseT { return storage.run({ ...context }, fn); }, get(): TaskContext | undefined { return storage.getStore(); }, setK extends keyof TaskContext(key: K, value: TaskContext[K]): void { const store storage.getStore(); if (store) { store[key] value; } }, };这段代码的关键点storage.run会创建一个新的上下文作用域传入的对象会被复制一份避免外部修改影响内部。getStore在作用域外返回undefined所以调用方必须处理这种情况。set直接修改store里的字段因为store是引用类型修改会立即生效。4.3 在请求入口处注入上下文以Express为例在中间件里创建上下文app.use((req, res, next) { const context: TaskContext { taskId: req.headers[x-task-id] as string || generateId(), operator: req.headers[x-operator] as string || anonymous, tenant: req.headers[x-tenant] as string || default, locale: req.headers[accept-language] || zh-CN, traceId: req.headers[x-trace-id] as string || generateTraceId(), }; contextManager.run(context, () { next(); }); });这里有一个容易踩的坑如果你在中间件里用了async函数next()的调用时机可能会影响上下文的作用域。在Express里中间件通常是同步调用的所以上面的写法没问题。但如果你用的是Koa或者Fastify它们的中间件模型不一样需要确认上下文是否能在整个请求生命周期内保持。4.4 在业务代码中读取上下文业务代码里就可以这样用async function processOrder(orderId: string) { const ctx contextManager.get(); if (!ctx) { throw new Error(Context not initialized); } logger.info(Processing order ${orderId} for tenant ${ctx.tenant}, { traceId: ctx.traceId, operator: ctx.operator, }); // 后续逻辑不需要再传ctx直接通过contextManager.get()获取 await validateOrder(orderId); await persistOrder(orderId); }对比一下参数传递的写法async function processOrder(orderId: string, ctx: TaskContext) { await validateOrder(orderId, ctx); await persistOrder(orderId, ctx); }上下文模式的优势在这里就很明显了业务函数的签名只包含业务参数上下文通过环境获取。这让函数更容易复用也更容易测试——测试时只需要在run里执行即可。4.5 参数计算与性能考量有人会担心AsyncLocalStorage的性能。我做过一个简单的压测在Node.js 18上每秒处理约1.2万个请求每个请求里调用getStore约50次CPU占用比不用上下文时增加了约3%到5%。这个开销在大多数业务场景下是可以接受的。但如果你在极端性能敏感的场景比如高频交易或者实时游戏服务器可能需要考虑其他方案。一个折中做法是只在需要跨模块传递的地方用上下文在模块内部还是用参数传递。这样既减少了参数爆炸又避免了全局上下文的性能开销。另外run方法里的对象复制也有成本。如果上下文对象很大复制开销会上升。我的建议是上下文对象保持精简只放必要的元信息不要放业务数据。5. 常见问题与排查技巧实录5.1 上下文丢失的几种典型场景这是最常见的问题。你明明在入口处设置了上下文到了某个异步回调里get()却返回undefined。原因通常有这几类异步边界没有正确包裹比如用了setTimeout、setImmediate、或者第三方库的回调而这些回调不是在run的作用域内创建的。Promise链断裂在某些老版本的Node.js或者某些Promise实现里AsyncLocalStorage的传播可能不完整。手动创建了新的执行上下文比如用了new Worker或者child_process这些是独立的执行环境上下文不会自动传递。中间件顺序问题上下文中间件注册得太晚前面的中间件已经执行完了。排查方法在关键节点打印contextManager.get()看从哪一步开始变成undefined。然后检查那一步是否在run的作用域内。5.2 上下文被意外修改另一个常见问题是上下文在某个步骤被修改了后续步骤读到了脏数据。比如某个函数里调用了contextManager.set(tenant, other)结果后面的逻辑全乱了。解决思路有两个只读上下文把上下文设计成不可变的需要修改时创建一个新的作用域。比如run里传入新对象而不是修改原对象。审计修改点在set方法里加日志记录谁在什么时候修改了哪个字段。这样出问题时能快速定位。我个人的偏好是第一种上下文一旦创建就不应该被修改。如果确实需要根据流程变化调整上下文应该用嵌套的run来创建新的作用域。5.3 测试时的上下文管理单元测试里如果被测函数依赖上下文你需要确保测试运行时上下文已经设置好。常见的做法是写一个测试辅助函数function withContextT(context: PartialTaskContext, fn: () PromiseT): PromiseT { const fullContext: TaskContext { taskId: test-task, operator: test-user, tenant: test-tenant, locale: zh-CN, traceId: test-trace, ...context, }; return contextManager.run(fullContext, fn); }这样每个测试用例只需要关心自己需要的上下文字段其他字段用默认值。5.4 常见问题速查表问题现象可能原因排查方法解决方案get()返回undefined不在run作用域内检查调用链是否在run内确保入口处正确包裹异步回调里上下文丢失回调创建时机不对在回调里打印get()用run包裹回调创建上下文被修改某处调用了set加日志审计set调用改为不可变上下文性能下降明显上下文对象过大压测对比精简上下文减少get调用多租户数据串了上下文隔离失败检查run是否每次新建确保run里复制对象注意上下文模式最大的风险是“隐式依赖”。虽然它让代码看起来更干净但也让依赖关系变得不那么明显。所以一定要配合良好的日志和追踪否则出问题时很难定位。6. 上下文模式在不同领域的延展应用6.1 在微服务链路追踪中的应用微服务架构里一个请求会经过多个服务。每个服务都需要知道“这个请求是从哪来的、经过了哪些节点、当前处于哪个阶段”。这就是典型的上下文模式应用场景。通常的做法是在网关层生成一个traceId然后通过HTTP头或者消息头传递给下游服务。每个服务在接收请求时把traceId和其他元信息放进上下文业务代码里通过上下文获取而不是从HTTP头里反复解析。这样做的价值在于日志、监控、告警都可以基于上下文自动关联。你不需要在每个日志语句里手动加traceId只需要在日志框架里配置从上下文读取即可。6.2 在前端状态管理中的应用前端应用里上下文模式常用于管理“当前用户”、“当前主题”、“当前语言”这类全局但又不频繁变化的状态。React的Context API、Vue的provide/inject、Angular的依赖注入本质上都是上下文模式的不同实现。一个常见的坑是把太多东西放进Context导致组件重渲染频繁。我的建议是用户信息、权限这类变化频率低的数据可以放Context。表单状态、列表数据这类变化频率高的数据应该放在组件本地状态或者专门的状态管理库里。如果确实需要跨组件共享高频变化的数据用选择器或者订阅机制避免全量重渲染。6.3 在大模型对话系统中的应用大模型应用里的上下文管理核心是“在有限的窗口里放最有用的信息”。我见过几种常见的策略滑动窗口只保留最近N轮对话。简单但容易丢失早期关键信息。摘要压缩定期把历史对话总结成一段摘要放在系统提示里。适合长对话。向量检索把历史消息存入向量库每次根据当前问题检索最相关的几条。适合知识密集型场景。混合策略最近几轮保留原文更早的做摘要关键实体单独维护。这些策略没有绝对的好坏关键看业务场景。比如客服机器人需要记住用户之前提过的问题摘要压缩可能更合适而知识问答机器人需要检索相关文档向量检索更合适。6.4 在任务调度系统中的应用任务调度系统里每个任务都有自己的上下文任务ID、重试次数、超时时间、依赖关系、执行结果。上下文模式可以让任务执行器在任意步骤获取这些信息而不需要把整个任务对象传来传去。一个实际案例某数据处理平台用上下文模式管理任务执行状态。每个任务在启动时创建一个上下文对象包含任务配置、输入输出路径、重试策略。执行过程中的每个算子通过上下文获取配置而不是从外部注入。这样算子的复用性大大提高同一个算子可以在不同任务里使用只需要上下文不同即可。7. 我踩过的坑和总结的经验7.1 不要过度设计刚开始用上下文模式时我恨不得把所有东西都塞进去。结果上下文对象越来越大最后变成了一个“什么都有”的怪物。后来我给自己定了一个规矩上下文里只放“元信息”不放“业务数据”。元信息是指描述这次执行的信息比如谁发起的、什么时候发起的、追踪ID是什么。业务数据是指这次执行要处理的内容比如订单详情、用户资料。后者应该通过参数传递或者依赖注入来管理。7.2 上下文要有明确的生命周期上下文的作用域应该清晰定义。是请求级会话级还是任务级不同级别对应不同的创建和销毁时机。如果生命周期不清晰就会出现“上下文泄漏”——上一个请求的上下文被下一个请求读到了。这在多租户系统里是致命问题。我的做法是在入口处创建在出口处销毁。对于HTTP请求就是在中间件里创建在响应结束后自动销毁。对于后台任务就是在任务开始时创建任务结束时销毁。不要依赖垃圾回收来清理上下文因为异步环境下很难确定什么时候真正结束。7.3 日志和追踪是上下文的天然搭档上下文模式最大的价值之一就是让日志和追踪变得更容易。你可以在日志框架里配置每条日志自动带上上下文里的traceId、tenant、operator。这样出问题时只需要根据traceId就能把整个链路的日志串起来。我现在的项目里日志格式是这样的{ timestamp: 2024-01-15T10:30:00Z, level: INFO, message: Order processed, traceId: abc-123, tenant: tenant-a, operator: user-1, taskId: task-456 }这些字段全部来自上下文业务代码里只需要写logger.info(Order processed)不需要手动传这些字段。7.4 测试时要覆盖上下文边界上下文模式的测试除了测业务逻辑还要测上下文本身的行为。比如在run作用域外调用get应该返回undefined。嵌套run时内层应该拿到内层的上下文外层不受影响。异步操作中上下文应该正确传播。并发执行多个run时上下文应该互相隔离。这些测试看起来简单但能帮你提前发现很多隐蔽的问题。7.5 最后分享一个小技巧如果你在用TypeScript可以给上下文管理器加一个类型安全的包装function requireContext(): TaskContext { const ctx contextManager.get(); if (!ctx) { throw new Error(Context is required but not available); } return ctx; }然后在业务代码里用requireContext()代替contextManager.get()。这样你就不需要每次检查undefined代码会更干净。当然前提是你确定这个函数只会在上下文作用域内被调用。这个模式我在多个项目里用过实测下来很稳。唯一需要注意的是如果某个函数可能被上下文外调用就不要用requireContext而是老老实实处理undefined。上下文模式不是银弹但它确实能解决一类很具体的问题。用得好代码会变得干净、可追踪、易测试用不好就会变成隐式依赖的温床。关键还是那句话明确边界控制生命周期配合日志和追踪。做到这三点上下文模式就能成为你工具箱里一件趁手的兵器。 
长河君 · 2026/10/20 4:21:11 · 阅读 1.2k 上下文模式（Context-Mode）工程实践：从设计原理到异步链路追踪与选型指南
1. 从“上下文模式”说起一个被低估的工程概念第一次看到“context-mode”这个词很多人会以为是某个新出的框架或者库。其实不是。它更像是一种设计思路一种在系统里管理“上下文”这件事的工程模式。你可以在前端状态管理里见到它可以在后端请求链路里见到它也可以在大模型应用里见到它。名字听起来抽象但落到代码里它解决的是一个非常具体的问题当一次操作需要跨越多个层级、多个模块、多个异步阶段时怎么保证每一步都能拿到它该拿到的信息同时不把整个系统搞成一团乱麻。我最早接触这个概念是在做一个跨平台的数据同步工具时。当时的需求很简单用户在A端改了数据B端要能感知到并且B端在渲染时还要知道“这次改动是谁触发的、在什么场景下触发的、需不需要弹提示”。一开始我们用的是全局变量加事件总线结果就是到处都在读全局状态改一个地方崩三个地方。后来换成显式传递上下文对象代码干净了不少但每个函数都要多一个参数调用链一长就特别啰嗦。直到有人提出“能不能让上下文自己跟着调用链走”我们才开始认真研究context-mode这类模式。所以这篇文章想聊的不是某个具体的库怎么用而是context-mode背后的设计逻辑、常见实现方式、实操中怎么选型、以及踩过哪些坑。如果你正在做多端同步、请求链路追踪、状态管理、或者大模型应用里的会话管理这篇文章应该能帮你少走一些弯路。即使你只是写业务代码理解上下文模式也能让你在拆分模块时更有章法。2. 上下文模式到底在解决什么问题2.1 什么是“上下文”为什么它容易失控先把这个词拆开看。“上下文”在工程里通常指一次操作所依赖的环境信息。比如一次HTTP请求它的上下文可能包括用户身份、请求ID、租户标识、语言偏好、权限范围、超时设置、重试次数。这些东西的特点是它们不是业务逻辑的核心但业务逻辑的每一步都可能需要它们。问题就出在这里。业务逻辑的核心是“做什么”上下文是“在什么条件下做”。如果上下文管理得不好就会出现几种典型症状隐式依赖某个函数内部直接读了全局变量调用者根本不知道它依赖了什么。参数爆炸为了显式传递每个函数签名都多出五六个参数调用链一深就没人愿意维护。生命周期混乱上下文在异步操作中被意外修改导致后续步骤拿到的是脏数据。跨层丢失中间件里设置的上下文到了业务层就找不到了只能靠线程本地存储或者全局单例硬撑。我见过一个最夸张的例子一个订单系统里为了传递“当前操作人”这个信息从Controller到Service到DAO每一层都加了一个operatorId参数。后来要加一个“操作来源渠道”又加了一个channel参数。再后来要加“请求追踪ID”又加了一个。最后函数签名长得像火车新人根本不敢改。2.2 context-mode的核心思路让上下文“跟着走”而不是“到处传”context-mode的核心思路其实一句话就能说清楚把上下文绑定到一次执行单元上让它在整个执行链路中自动可见而不是靠参数一层层传。这里的“执行单元”可以是一次请求、一次任务、一次会话、一次渲染。绑定方式在不同技术栈里不一样在后端常见的是用线程本地存储ThreadLocal或者异步本地存储AsyncLocalStorage。在前端常见的是用React Context、Vue provide/inject或者状态管理库里的“作用域”。在Node.js里AsyncLocalStorage是官方提供的方案可以在异步调用链中保持上下文。在大模型应用里上下文模式通常表现为“会话状态”或者“对话历史”的管理。关键区别在于参数传递是显式的、逐层的上下文模式是隐式的、跨层的。隐式不代表不可控只要设计得当它反而能让代码更干净因为业务逻辑不需要关心上下文的传递细节。2.3 和其他模式的边界别把什么都塞进上下文这里要特别提醒一点上下文模式不是万能的也不是什么都能往里塞。我见过有人把数据库连接、缓存客户端、配置对象全塞进上下文结果上下文变成了一个“万能袋子”谁都可以往里加东西最后没人知道里面有什么。一个比较健康的边界是放进去的请求级、会话级、任务级的元信息比如追踪ID、用户身份、租户、语言、权限快照。不放进去的业务数据、领域对象、数据库连接、全局配置。这些应该通过依赖注入或者模块导入来管理。判断标准很简单如果这个信息在一次执行单元结束后就应该消失那它适合放上下文如果它跨执行单元存在那它应该放在更持久的地方。3. 常见实现方案与选型对比3.1 后端场景ThreadLocal vs AsyncLocalStorage在后端最传统的做法是ThreadLocal。每个请求由一个线程处理上下文存在线程本地变量里业务代码随时可以取。这个方案在同步阻塞模型下工作得很好但一旦引入异步比如CompletableFuture、协程、响应式编程线程会切换ThreadLocal里的数据就跟不过去了。AsyncLocalStorage或者类似机制解决了这个问题。它把上下文绑定到异步调用链上而不是线程上。Node.js从v12.17开始提供这个能力Java生态里也有类似的东西比如阿里开源的TransmittableThreadLocal。方案适用场景优点缺点ThreadLocal同步阻塞、线程模型固定简单、性能好异步切换线程后丢失AsyncLocalStorage异步、Promise、async/await跨异步链路保持需要运行时支持调试稍复杂显式参数传递调用链短、上下文少最透明、无魔法参数爆炸维护成本高依赖注入容器大型应用、模块化清晰生命周期可控配置复杂学习曲线陡我个人的经验是如果调用链超过三层而且上下文项超过三个就应该考虑用上下文模式而不是参数传递。但如果你只是写一个简单的工具函数那就别引入上下文直接传参最清楚。3.2 前端场景React Context与状态管理前端的情况有点不一样。React Context本质上是一种“跨组件树传递数据”的机制它解决的问题是prop drilling属性逐层传递。但React Context有一个众所周知的性能问题当Context的值变化时所有消费该Context的组件都会重新渲染。所以在前端用上下文模式时通常要做两件事拆分Context不要把用户信息、主题、语言、权限全放在一个Context里。按更新频率和消费范围拆开。配合选择器用useContextSelector或者状态管理库的选择器能力只订阅自己关心的部分。Vue的provide/inject也有类似的问题但Vue的响应式系统会自动追踪依赖所以性能上通常比React Context好一些。不过如果provide的值是一个大对象而且经常变同样会导致不必要的更新。3.3 大模型应用会话上下文的管理在大模型应用里context-mode这个词出现的频率越来越高。这里的“上下文”通常指对话历史、系统提示、工具调用结果、用户偏好等。管理这些上下文的核心挑战是长度限制模型的上下文窗口有限不能无限追加。相关性不是所有历史消息都对当前问题有用需要做筛选或摘要。一致性多轮对话中上下文要保持连贯不能前后矛盾。隔离性不同用户的会话必须严格隔离不能串。常见的做法是维护一个“会话状态对象”里面包含消息列表、摘要、关键实体、当前任务状态。每次请求时根据策略决定把哪些内容放进模型的上下文窗口。这个策略可以是滑动窗口、摘要压缩、向量检索、或者混合方案。提示在大模型应用里上下文管理直接决定了回答质量和成本。上下文太长成本高且容易跑偏上下文太短模型记不住关键信息。这个平衡点需要根据业务场景反复调。4. 实操从零实现一个轻量级上下文管理器4.1 需求定义与接口设计假设我们要做一个任务处理系统每个任务需要携带以下上下文任务ID、发起人、租户、语言、追踪ID。任务处理过程中会经过多个异步步骤每个步骤都可能需要读取这些信息。我们先定义接口interface TaskContext { taskId: string; operator: string; tenant: string; locale: string; traceId: string; } interface ContextManager { runT(context: TaskContext, fn: () PromiseT): PromiseT; get(): TaskContext | undefined; setK extends keyof TaskContext(key: K, value: TaskContext[K]): void; }这里的设计意图是run方法负责在一个新的上下文作用域里执行函数get方法在作用域内任意位置获取当前上下文set方法允许在作用域内修改部分字段。4.2 基于AsyncLocalStorage的实现Node.js环境下用AsyncLocalStorage实现最直接import { AsyncLocalStorage } from async_hooks; const storage new AsyncLocalStorageTaskContext(); export const contextManager: ContextManager { runT(context: TaskContext, fn: () PromiseT): PromiseT { return storage.run({ ...context }, fn); }, get(): TaskContext | undefined { return storage.getStore(); }, setK extends keyof TaskContext(key: K, value: TaskContext[K]): void { const store storage.getStore(); if (store) { store[key] value; } }, };这段代码的关键点storage.run会创建一个新的上下文作用域传入的对象会被复制一份避免外部修改影响内部。getStore在作用域外返回undefined所以调用方必须处理这种情况。set直接修改store里的字段因为store是引用类型修改会立即生效。4.3 在请求入口处注入上下文以Express为例在中间件里创建上下文app.use((req, res, next) { const context: TaskContext { taskId: req.headers[x-task-id] as string || generateId(), operator: req.headers[x-operator] as string || anonymous, tenant: req.headers[x-tenant] as string || default, locale: req.headers[accept-language] || zh-CN, traceId: req.headers[x-trace-id] as string || generateTraceId(), }; contextManager.run(context, () { next(); }); });这里有一个容易踩的坑如果你在中间件里用了async函数next()的调用时机可能会影响上下文的作用域。在Express里中间件通常是同步调用的所以上面的写法没问题。但如果你用的是Koa或者Fastify它们的中间件模型不一样需要确认上下文是否能在整个请求生命周期内保持。4.4 在业务代码中读取上下文业务代码里就可以这样用async function processOrder(orderId: string) { const ctx contextManager.get(); if (!ctx) { throw new Error(Context not initialized); } logger.info(Processing order ${orderId} for tenant ${ctx.tenant}, { traceId: ctx.traceId, operator: ctx.operator, }); // 后续逻辑不需要再传ctx直接通过contextManager.get()获取 await validateOrder(orderId); await persistOrder(orderId); }对比一下参数传递的写法async function processOrder(orderId: string, ctx: TaskContext) { await validateOrder(orderId, ctx); await persistOrder(orderId, ctx); }上下文模式的优势在这里就很明显了业务函数的签名只包含业务参数上下文通过环境获取。这让函数更容易复用也更容易测试——测试时只需要在run里执行即可。4.5 参数计算与性能考量有人会担心AsyncLocalStorage的性能。我做过一个简单的压测在Node.js 18上每秒处理约1.2万个请求每个请求里调用getStore约50次CPU占用比不用上下文时增加了约3%到5%。这个开销在大多数业务场景下是可以接受的。但如果你在极端性能敏感的场景比如高频交易或者实时游戏服务器可能需要考虑其他方案。一个折中做法是只在需要跨模块传递的地方用上下文在模块内部还是用参数传递。这样既减少了参数爆炸又避免了全局上下文的性能开销。另外run方法里的对象复制也有成本。如果上下文对象很大复制开销会上升。我的建议是上下文对象保持精简只放必要的元信息不要放业务数据。5. 常见问题与排查技巧实录5.1 上下文丢失的几种典型场景这是最常见的问题。你明明在入口处设置了上下文到了某个异步回调里get()却返回undefined。原因通常有这几类异步边界没有正确包裹比如用了setTimeout、setImmediate、或者第三方库的回调而这些回调不是在run的作用域内创建的。Promise链断裂在某些老版本的Node.js或者某些Promise实现里AsyncLocalStorage的传播可能不完整。手动创建了新的执行上下文比如用了new Worker或者child_process这些是独立的执行环境上下文不会自动传递。中间件顺序问题上下文中间件注册得太晚前面的中间件已经执行完了。排查方法在关键节点打印contextManager.get()看从哪一步开始变成undefined。然后检查那一步是否在run的作用域内。5.2 上下文被意外修改另一个常见问题是上下文在某个步骤被修改了后续步骤读到了脏数据。比如某个函数里调用了contextManager.set(tenant, other)结果后面的逻辑全乱了。解决思路有两个只读上下文把上下文设计成不可变的需要修改时创建一个新的作用域。比如run里传入新对象而不是修改原对象。审计修改点在set方法里加日志记录谁在什么时候修改了哪个字段。这样出问题时能快速定位。我个人的偏好是第一种上下文一旦创建就不应该被修改。如果确实需要根据流程变化调整上下文应该用嵌套的run来创建新的作用域。5.3 测试时的上下文管理单元测试里如果被测函数依赖上下文你需要确保测试运行时上下文已经设置好。常见的做法是写一个测试辅助函数function withContextT(context: PartialTaskContext, fn: () PromiseT): PromiseT { const fullContext: TaskContext { taskId: test-task, operator: test-user, tenant: test-tenant, locale: zh-CN, traceId: test-trace, ...context, }; return contextManager.run(fullContext, fn); }这样每个测试用例只需要关心自己需要的上下文字段其他字段用默认值。5.4 常见问题速查表问题现象可能原因排查方法解决方案get()返回undefined不在run作用域内检查调用链是否在run内确保入口处正确包裹异步回调里上下文丢失回调创建时机不对在回调里打印get()用run包裹回调创建上下文被修改某处调用了set加日志审计set调用改为不可变上下文性能下降明显上下文对象过大压测对比精简上下文减少get调用多租户数据串了上下文隔离失败检查run是否每次新建确保run里复制对象注意上下文模式最大的风险是“隐式依赖”。虽然它让代码看起来更干净但也让依赖关系变得不那么明显。所以一定要配合良好的日志和追踪否则出问题时很难定位。6. 上下文模式在不同领域的延展应用6.1 在微服务链路追踪中的应用微服务架构里一个请求会经过多个服务。每个服务都需要知道“这个请求是从哪来的、经过了哪些节点、当前处于哪个阶段”。这就是典型的上下文模式应用场景。通常的做法是在网关层生成一个traceId然后通过HTTP头或者消息头传递给下游服务。每个服务在接收请求时把traceId和其他元信息放进上下文业务代码里通过上下文获取而不是从HTTP头里反复解析。这样做的价值在于日志、监控、告警都可以基于上下文自动关联。你不需要在每个日志语句里手动加traceId只需要在日志框架里配置从上下文读取即可。6.2 在前端状态管理中的应用前端应用里上下文模式常用于管理“当前用户”、“当前主题”、“当前语言”这类全局但又不频繁变化的状态。React的Context API、Vue的provide/inject、Angular的依赖注入本质上都是上下文模式的不同实现。一个常见的坑是把太多东西放进Context导致组件重渲染频繁。我的建议是用户信息、权限这类变化频率低的数据可以放Context。表单状态、列表数据这类变化频率高的数据应该放在组件本地状态或者专门的状态管理库里。如果确实需要跨组件共享高频变化的数据用选择器或者订阅机制避免全量重渲染。6.3 在大模型对话系统中的应用大模型应用里的上下文管理核心是“在有限的窗口里放最有用的信息”。我见过几种常见的策略滑动窗口只保留最近N轮对话。简单但容易丢失早期关键信息。摘要压缩定期把历史对话总结成一段摘要放在系统提示里。适合长对话。向量检索把历史消息存入向量库每次根据当前问题检索最相关的几条。适合知识密集型场景。混合策略最近几轮保留原文更早的做摘要关键实体单独维护。这些策略没有绝对的好坏关键看业务场景。比如客服机器人需要记住用户之前提过的问题摘要压缩可能更合适而知识问答机器人需要检索相关文档向量检索更合适。6.4 在任务调度系统中的应用任务调度系统里每个任务都有自己的上下文任务ID、重试次数、超时时间、依赖关系、执行结果。上下文模式可以让任务执行器在任意步骤获取这些信息而不需要把整个任务对象传来传去。一个实际案例某数据处理平台用上下文模式管理任务执行状态。每个任务在启动时创建一个上下文对象包含任务配置、输入输出路径、重试策略。执行过程中的每个算子通过上下文获取配置而不是从外部注入。这样算子的复用性大大提高同一个算子可以在不同任务里使用只需要上下文不同即可。7. 我踩过的坑和总结的经验7.1 不要过度设计刚开始用上下文模式时我恨不得把所有东西都塞进去。结果上下文对象越来越大最后变成了一个“什么都有”的怪物。后来我给自己定了一个规矩上下文里只放“元信息”不放“业务数据”。元信息是指描述这次执行的信息比如谁发起的、什么时候发起的、追踪ID是什么。业务数据是指这次执行要处理的内容比如订单详情、用户资料。后者应该通过参数传递或者依赖注入来管理。7.2 上下文要有明确的生命周期上下文的作用域应该清晰定义。是请求级会话级还是任务级不同级别对应不同的创建和销毁时机。如果生命周期不清晰就会出现“上下文泄漏”——上一个请求的上下文被下一个请求读到了。这在多租户系统里是致命问题。我的做法是在入口处创建在出口处销毁。对于HTTP请求就是在中间件里创建在响应结束后自动销毁。对于后台任务就是在任务开始时创建任务结束时销毁。不要依赖垃圾回收来清理上下文因为异步环境下很难确定什么时候真正结束。7.3 日志和追踪是上下文的天然搭档上下文模式最大的价值之一就是让日志和追踪变得更容易。你可以在日志框架里配置每条日志自动带上上下文里的traceId、tenant、operator。这样出问题时只需要根据traceId就能把整个链路的日志串起来。我现在的项目里日志格式是这样的{ timestamp: 2024-01-15T10:30:00Z, level: INFO, message: Order processed, traceId: abc-123, tenant: tenant-a, operator: user-1, taskId: task-456 }这些字段全部来自上下文业务代码里只需要写logger.info(Order processed)不需要手动传这些字段。7.4 测试时要覆盖上下文边界上下文模式的测试除了测业务逻辑还要测上下文本身的行为。比如在run作用域外调用get应该返回undefined。嵌套run时内层应该拿到内层的上下文外层不受影响。异步操作中上下文应该正确传播。并发执行多个run时上下文应该互相隔离。这些测试看起来简单但能帮你提前发现很多隐蔽的问题。7.5 最后分享一个小技巧如果你在用TypeScript可以给上下文管理器加一个类型安全的包装function requireContext(): TaskContext { const ctx contextManager.get(); if (!ctx) { throw new Error(Context is required but not available); } return ctx; }然后在业务代码里用requireContext()代替contextManager.get()。这样你就不需要每次检查undefined代码会更干净。当然前提是你确定这个函数只会在上下文作用域内被调用。这个模式我在多个项目里用过实测下来很稳。唯一需要注意的是如果某个函数可能被上下文外调用就不要用requireContext而是老老实实处理undefined。上下文模式不是银弹但它确实能解决一类很具体的问题。用得好代码会变得干净、可追踪、易测试用不好就会变成隐式依赖的温床。关键还是那句话明确边界控制生命周期配合日志和追踪。做到这三点上下文模式就能成为你工具箱里一件趁手的兵器。