先聊一个我最近反复在技术评审里听到的词：context-mode。如果你去翻一些中大型项目的代码，会发现很多模块在运行时都要回答同一个问题——“我现在到底处于什么场景？”是开发环境还是线上？是哪个租户在调用？灰度批次里有我吗？这个问题的答案，直接决定了日志打到哪、缓存读哪份、功能开不开。可惜大多数项目处理这个问题的方式，是散落各处的 if 判断和全局变量，改一处崩三处。context-mode 就是我把这套答案收敛成一个显式机制的实践总结。
这篇文章适合正在做服务端架构、中间件设计、或者维护一个多环境多租户业务系统的开发者。无论你是后端主程、全栈工程师还是技术负责人，只要你的系统里出现过“不同环境行为不一致”“不同用户看到不同功能”“同一段代码在测试环境正常、线上就翻车”这类问题，这篇文章的整套思路都能直接套用。我会把设计动机、核心机制、落地步骤、常见坑一次讲透，代码以 TypeScript 示例为主，但思路不限于任何语言。
1. 内容整体设计与思路拆解
1.1 从混乱的散装判断说起
先还原一个很典型的现场。某个业务服务里，代码大概长这样：
function getDiscountPrice(userId: string, productId: string) { const isVip = checkVip(userId); const isNewUser = checkNewUser(userId); const env = process.env.NODE_ENV; let discount = 1; if (env === 'development') { discount = 0.5; // 本地随便打折 } if (isNewUser) { discount = Math.min(discount, 0.8); } if (isVip) { discount = Math.min(discount, 0.85); } // 某运营活动临时加的 if (global.__campaignEnabled && global.__campaignUserIdList.includes(userId)) { discount = Math.min(discount, 0.7); } return getPrice(productId) * discount; }这段代码的问题不在业务逻辑本身，而在于“当前处于什么模式”这件事被拆得七零八落：环境变量读一个、全局变量读一个、用户画像查一个、活动名单再查一个。这些信息在调用链路的各个角落被零散地读取和判断，彼此之间没有统一的结构。
我见过更离谱的情况是：有人为了在测试环境临时验证一个功能，直接在代码里写if (userId === '某个测试号') return ...，结果这个测试号忘了删，跟着上线走了三个月。后来排查一个线上数据异常，查了两天才发现是这个硬编码分支在作怪。
这种散装判断带来的直接后果有三个：
- 可读性差。新同事接手代码，根本不知道一个请求进来到底会命中哪些分支。
- 可测试性差。单元测试里要 mock 一堆环境变量和全局状态，用例写起来像在搭积木。
- 可追溯性差。线上出问题，你很难回答“这个请求当时处于什么上下文”。
context-mode 的核心思路，就是把这些散落的判断收敛到一个显式的上下文对象里，让业务代码只回答“基于当前上下文，我该怎么做”，而不需要自己去拼凑“当前上下文到底是什么”。
1.2 context-mode 要回答的三个问题
在设计一套 context-mode 机制时，我习惯先问自己三个问题，这三个问题的答案基本上就定义清楚了上下文的全部维度。
第一个问题是“我在哪个环境/模式”。这个最容易理解，就是 development、test、staging、production 这类环境标识，也包括系统内部的运行模式，比如“只读模式”“维护模式”“降级模式”。区别在于，环境标识通常是部署时确定的，而运行模式可能是运行中动态切换的。
第二个问题是“我在为谁工作”。这个维度通常指租户、用户、应用、设备等调用主体。多租户系统里，不同租户的数据隔离规则、功能配额、计价策略完全不同；即使同一个租户，不同用户角色能看到的菜单和按钮也不一样。把主体信息放进上下文，而不是让每个方法都去查一次会话，能省掉大量重复的查询逻辑。
第三个问题是“当前有哪些开关在生效”。功能开关、灰度批次、实验分组，这类信息的特点是变化频率高、影响范围大。今天这个功能对 10% 用户开放，明天改成 30%，如果这些信息散落在代码判断里，每次调整都要发版；如果收进上下文，调整配置就能即时生效。
这三个问题叠在一起，就构成一个完整的 context。设计的时候不要一开始就追求大而全，先把这三类维度定义好，后续要加维度时再往上下文对象里加字段，比一开始设计一个无所不包的“上帝上下文”要可靠得多。
1.3 它和状态模式、策略模式的区别
很多同事第一次听说 context-mode，会把它和设计模式里的状态模式、策略模式搞混。我在这里用一个简单的对比说清楚。
状态模式关注的是“一个对象内部的状态如何流转”。比如订单状态从待支付变成已支付，再变成已发货，每个状态对应不同的行为。状态的改变是由内部事件驱动的，而且通常有明确的状态机约束。
策略模式关注的是“同一个接口可以有多种算法实现”。比如排序策略、加密策略，运行时机灵地选择一种策略执行，策略之间是平级可替换的。
context-mode 关注的是“系统处于什么运行场景”。它不描述单个对象的状态，也不封装具体算法，它描述的是调用发生的环境。策略模式回答“用哪种算法”，状态模式回答“对象现在处于什么状态”，context-mode 回答“当前调用发生在什么环境、什么主体、什么开关组合之下”。
用生活里的例子类比：去餐厅吃饭，状态模式是你这桌菜从下单到上桌的进度，策略模式是你要选米饭还是面条，context-mode 是你坐的是普通区还是包间、是工作日午市还是周末晚市——你的用餐环境决定了你能点的套餐、能享受的折扣、能使用的服务。
理解了这一层，就不会在设计时把业务状态机硬塞进上下文里，也不会把上下文当成万能缓存来放各种临时数据。
1.4 为什么大多数项目没有把它做成一个“模式”
既然 context-mode 的思路听起来这么顺理成章，为什么大多数项目里的代码还是散装判断？我观察下来主要有三个原因。
第一个原因是命名问题。“context”这个词在编程世界里太泛滥了，有编程语言的 Context、有框架的 Context、有日志的 Context，一说“把上下文对象传下去”，很多人的第一反应是“这不就是参数吗，有什么好设计的”。实际上 context-mode 是一个显式的架构约定，不是随手传一两个参数。
第二个原因是抽象层级问题。很多人把上下文当成工具函数，只封装了一个getCurrentUser()，却没有把环境、租户、开关一起建模。等到需要再加维度的时候，发现到处都要改，于是放弃治疗，继续写散装判断。
第三个原因是团队惯性。一个系统如果一开始没有上下文的概念，后面每个人都往里面加自己的“快捷方式”，久而久之代码就成了一锅粥。重构的代价看起来很大，于是大家宁可继续打补丁。
我个人的经验是：越早建立上下文抽象，收益越大。哪怕系统还不复杂，先把环境、租户、用户三个维度建模好，后面加功能开关、灰度逻辑时，就有了一个天然的挂载点，不会再把代码搅成一团。
2. 核心细节解析与实操要点
2.1 上下文对象长什么样
先给出一个最基础的上下文对象定义：
export type EnvMode = 'local' | 'dev' | 'test' | 'staging' | 'prod'; export type RuntimeMode = 'normal' | 'readonly' | 'maintenance' | 'degraded'; export interface AppContext { // 环境维度 env: EnvMode; runtimeMode: RuntimeMode; // 主体维度 tenantId: string; userId: string; userRole: string; // 开关维度 flags: Record<string, boolean>; // 追踪维度，用于日志和排查 requestId: string; }这个对象的设计有几个关键点。
字段分组要清晰。我用注释把字段分成环境、主体、开关、追踪四组。这样阅读代码的人一眼就能知道每类信息放在哪里，新增维度时也能找到对应的分组。
对象应该尽量不可变。特别是环境和租户这类核心字段，一旦上下文建立就不允许中途修改。开关类字段可以做成不可变集合，切换开关时创建一个新的上下文而不是改动旧对象。不可变设计能避免很多“这个请求跑到一半，上下文被另一个协程改了”的诡异问题。
开关字段用Record<string, boolean>而不是逐个命名。原因是功能开关的数量会持续增长，如果每个开关都写成独立字段，上下文对象会膨胀得很厉害。用字典结构后，新增一个开关只需要在配置里加一个 key，不需要改类型定义。
requestId 必须放进去。排障时最重要的第一件事就是定位一次请求的完整链路，requestId 放在上下文里，业务代码记日志时统一带上，比让每个模块自己生成日志标识要靠谱得多。
2.2 模式切换器怎么设计
有了上下文对象，还需要一个管理器来负责上下文的创建、进入、退出。核心设计如下：
export class ContextManager { private static stack: AppContext[] = []; static enter(ctx: AppContext): () => void { ContextManager.stack.push(ctx); return () => { ContextManager.stack.pop(); }; } static current(): AppContext { const ctx = ContextManager.stack[ContextManager.stack.length - 1]; if (!ctx) { throw new Error('AppContext not initialized'); } return ctx; } static withContext<T>(ctx: AppContext, fn: () => T): T { ContextManager.enter(ctx); try { return fn(); } finally { ContextManager.stack.pop(); } } }这个设计是用栈来管理上下文。为什么用栈而不是简单地赋值给一个全局变量？因为一个请求内部可能还有子任务，子任务可能需要临时切换到另一种模式。比如主请求是普通用户模式，内部调用一个内部管理接口时需要临时切到管理员模式，执行完再切回来。栈结构天然支持这种嵌套场景。
withContext方法是我用得最多的入口。它保证了无论业务逻辑执行成功还是抛异常，最后都会把上下文弹出栈，不会污染后续请求。这个模式跟很多语言里的 RAII 思路一致，用起来最安全。
这里有一个必须强调的细节：在高并发场景下，这套栈必须跟请求的异步上下文绑定，而不能是全局唯一的栈。在 Node.js 里可以用AsyncLocalStorage来实现，在 Java 里可以借助ThreadLocal或TransmittableThreadLocal。如果用一个纯全局栈，并发请求之间的上下文会互相覆盖，这是最常见也最危险的坑。
2.3 作用域与传递方式怎么选
上下文从入口到业务代码，有几种传递方式，我整理了一个对比。
| 传递方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 显式方法参数 | 直观、无隐藏依赖 | 侵入性强，改造成本高 | 单层调用链的小系统 |
| 全局栈/异步本地变量 | 侵入性低，调用自然 | 有隐藏依赖，需严格管理生命周期 | 中大型请求链路 |
| 依赖注入容器 | 生命周期可控，测试友好 | 框架绑定强，新手理解成本高 | 使用成熟 DI 框架的团队 |
我的建议是组合使用：请求入口处通过中间件创建上下文并放入异步上下文中，业务代码通过ContextManager.current()获取；如果某个函数是纯函数，不想依赖上下文，就把需要的字段作为参数显式传入。这个组合既保证了大部分代码的简洁，又保留了纯函数的可测试性。
有一点要特别注意：上下文不要跨消息边界传播。比如一个请求接收到消息后投递到消息队列，消费端不应该直接使用生产端的上下文，而应该把必要的信息（tenantId、userId、env）从消息体里取出，重新创建一个消费端上下文。跨边界的上下文传播会让你分不清数据是在哪个环节产生的，排障时非常痛苦。
2.4 生命周期管理的四个关键点
上下文的生命周期看似简单，实际上有四个关键点容易被忽略。
第一是创建时机。上下文应该在请求入口创建，越早越好。常见做法是在 HTTP 中间件、消息消费拦截器、定时任务调度器里统一创建。不要在业务代码里到处手动创建，否则入口不统一，上下文就容易漏配。
第二是传播范围。一次请求内的异步子任务要能自动继承上下文。Node.js 的AsyncLocalStorage可以跨 async 操作传递数据，用它可以省掉大量手动透传的代码。但要注意，AsyncLocalStorage只覆盖异步资源，对于 worker_threads、子进程这类场景，需要手动序列化上下文再传出去。
第三是销毁时机。上下文一定要在请求结束时清理干净，否则会泄漏到线程池的下一个任务里。用withContext这类带 finally 的封装，能很好地保证清理。日志里出现“两个请求的 requestId 串了”，多半就是销毁这步没做好。
第四是兜底策略。ContextManager.current()在栈为空时应该抛异常还是返回默认值？我的选择是抛异常，并且异常信息要足够明确，比如“AppContext not initialized, please check request entry middleware”。这样可以尽早暴露那些漏配上下文的调用路径，而不是让代码带着一个空的上下文继续跑，最后在某个角落里产生奇怪的数据。
3. 实操过程与核心环节实现
3.1 第一步：盘点你的模式维度
动手写代码之前，先花半天时间盘点系统里到底有哪些会变化的行为维度。拿一个典型的多租户 SaaS 系统举例，我通常会列出这样一张表：
| 维度 | 取值示例 | 影响 |
|---|---|---|
| 环境 | local、dev、test、prod | 日志级别、资源地址、密钥 |
| 租户 | tenantA、tenantB | 数据隔离、功能配额、菜单 |
| 用户角色 | admin、editor、viewer | 权限范围、操作审计 |
| 功能开关 | newDashboard、betaAPI | 功能可见性 |
| 运行模式 | normal、maintenance | 读写限制、熔断行为 |
这张表不需要一次画全，你先画出能想到的维度，后面随着业务演进再增补。关键是每个维度都要能回答两个问题：它会在什么时候变、它变了之后哪些行为要跟着变。
这时你会立刻发现，很多维度目前的实现是藏在代码里的。比如“租户能不能用导出功能”可能写在TenantService.canExport()里，而判断条件是查数据库配置。把这类逻辑收进上下文之后，业务代码不再需要反复查，性能也会好一些。
3.2 第二步：定义上下文类型与枚举
盘点完维度，就可以落成代码了。上面的AppContext接口已经给了基础模板，这里再补充一个“功能开关集合”的构建方法：
export function buildFlagSet(source: Record<string, boolean>, userId: string): Record<string, boolean> { const result: Record<string, boolean> = {}; for (const [key, enabled] of Object.entries(source)) { if (key.startsWith('gray_')) { // 灰度开关，按用户哈希决定是否命中 result[key] = isUserInGray(userId, key); } else { result[key] = enabled; } } return result; } function isUserInGray(userId: string, flagKey: string): boolean { // 用用户ID加开关名做稳定哈希，保证同一个用户对同一个开关始终命同一次 const seed = hash(`${flagKey}:${userId}`); return seed % 100 < 30; // 灰度比例30% }这段代码展示了一个关键技巧：功能开关不一定要从配置里读，有些开关需要按用户动态计算。灰度开关和普通开关用同一个接口表达，业务代码不感知差异，统一从ctx.flags里读，这就是上下文抽象的价值。
定义枚举时，我建议用字符串枚举而不是数字枚举。字符串枚举在日志和错误信息里可读性好很多，排障时不用再猜1代表什么模式。代码实现里也尽量不要用魔法字符串，集中定义成常量，避免拼写错误带出一堆隐蔽问题。
3.3 第三步：实现入口解析与中间件
上下文需要在一个统一的入口处创建。以 Express 为例，中间件可以这样写：
import { AsyncLocalStorage } from 'async_hooks'; export const contextStorage = new AsyncLocalStorage<AppContext>(); export function contextMiddleware(req: Request, res: Response, next: NextFunction) { const tenantId = resolveTenant(req); const userId = resolveUser(req); const env = resolveEnv(); const runtimeMode = resolveRuntimeMode(); const flags = resolveFlags(req); const ctx: AppContext = { env, runtimeMode, tenantId, userId, userRole: resolveRole(userId), flags, requestId: req.headers['x-request-id'] ?? generateRequestId(), }; contextStorage.run(ctx, () => { next(); }); }入口中间件只做三件事：解析原始请求信息、组装 AppContext、调用run进入上下文作用域。业务代码里不要再去解析 header、解析 token，统一从ContextManager.current()获取。
解析步骤里最容易犯的错是：每个维度都去查一次数据库。比如解析 userRole 时查用户表、解析 tenantConfig 时查租户配置表，一个中间件下来打了好几轮库。建议把高频且变更不频繁的配置做成缓存，或者合并到一次查询里批量取回。入口链路的性能直接影响所有请求的延迟，这一层一定要盯紧。
3.4 第四步：让业务代码只认上下文
引入 context-mode 之后，重构的核心是把散装的判断替换成上下文读取。重构前：
function getDiscountPrice(userId: string, productId: string) { let discount = 1; const env = process.env.NODE_ENV; if (env === 'development') discount = 0.5; if (checkNewUser(userId)) discount = Math.min(discount, 0.8); if (checkVip(userId)) discount = Math.min(discount, 0.85); return getPrice(productId) * discount; }重构后：
function getDiscountPrice(productId: string) { const ctx = ContextManager.current(); let discount = 1; if (ctx.env === 'local' || ctx.env === 'dev') discount = 0.5; if (ctx.userRole === 'new_user') discount = Math.min(discount, 0.8); if (ctx.userRole === 'vip') discount = Math.min(discount, 0.85); if (ctx.flags['promo_autumn']) discount = Math.min(discount, 0.7); return getPrice(productId) * discount; }对比之下，重构后的函数签名少了一个 userId 参数，因为用户信息已经从上下文里拿到了。很多业务函数其实并不需要关心“用户是谁”，只需要知道“当前用户是什么角色”“当前环境是什么”，从上下文读取比层层传参清晰得多。
这里要注意一个度：不是所有参数都应该塞进上下文。跟具体业务强相关的参数，比如订单金额、商品数量、查询页码，这些应该继续作为函数参数显式传递。上下文只承载“横切面”的通用信息，不要让业务参数和上下文字段混在一起。
3.5 灰度流量分配的参数计算
很多系统都要做灰度发布，context-mode 和灰度结合得很紧密。这里我详细说一下灰度比例的计算过程，方便你直接套用。
假设某个开关newCheckoutFlow要开放 30% 的流量。我们需要保证同一个用户每次请求都命中同一个分组，否则用户第一次走新流程、第二次走旧流程，体验会很割裂，数据对比也没法做。
Step 1：构造稳定哈希输入
哈希输入不能只用 userId，因为同一个用户在不同灰度项目中如果都用userId % 100，那么当他同时在两个灰度名单里时，他会一直落在相同的分位数上，灰度组之间的用户重叠度会非常高。解决方法是把开关名也拼进去：seed = hash(flagKey + ':' + userId)。
Step 2：计算哈希值
用一个稳定的哈希函数，比如 FNV-1a、MurmurHash。不要用 JavaScript 内置的Math.random()，它每次运行结果不同，无法满足稳定性要求。示意代码：
function hash(input: string): number { let h = 2166136261; for (let i = 0; i < input.length; i++) { h ^= input.charCodeAt(i); h = Math.imul(h, 16777619); } return h >>> 0; }Step 3：映射到百分位
const bucket = hash(${flagKey}:${userId}) % 100;
如果bucket < 30，说明该用户命中新流程，否则走旧流程。
这个计算过程在构建 flags 时执行一次，之后整个请求生命周期内从上下文读取结果即可。灰度比例调整时只需要改配置，比如从 30 改成 50，无需发版。从 30% 升到 50% 时，原来命中新流程的用户依然命中，原来没命中的用户里有一部分会进入新流程，这就是大家都知道的“单向灰度增长”特性。
3.6 上线前的验证清单
context-mode 重构完成后，千万不要急着上线。我总结了一组验证清单，建议逐项打勾：
- [ ] 所有入口（HTTP、消息、定时任务）都创建了上下文，没有漏配。
- [ ] 异步子任务能自动继承父任务的上下文。
- [ ] 请求结束时上下文被正确清理，没有串到下一个请求。
- [ ] 单元测试覆盖了环境切换、租户隔离、开关启停三条主链路。
- [ ] 灰度开关的稳定性验证：同一用户连续多次请求，命中的分组一致。
- [ ] 日志里所有关键业务行为都带着 requestId，可以通过 requestId 串联整条链路。
- [ ] 线上有兜底监控：当上下文缺失时，
current()抛异常，相关错误监控能第一时间上报。
这套清单看起来琐碎，但每一条背后都对应着一个我之前踩过的真实坑。比如异步继承没做好，排查了一个星期才发现是上下文在 await 之后丢失了。把这些检查固化下来，能帮团队省下大量排查时间。
4. 常见问题与排查技巧实录
4.1 上下文串扰：A 请求带了 B 的上下文
表现：线上日志里，两个不同的 requestId 对应的 userId 是一样的，或者一个请求查出了另一个租户的数据。
最常见的根因是全局栈/ThreadLocal 的生命周期没有绑对。线程池里的线程会被复用，如果上下文在请求结束时没有清理，下一个复用到该线程的任务就会读到上一个任务的残留数据。
排查步骤：
- 在入口中间件创建上下文时打一条日志，记录 requestId 和线程/异步资源 ID。
- 在业务代码打印上下文时同样记录这些 ID，两相对比，就能看出上下文是哪个环节串的。
- 检查所有异步任务、线程池、消息消费逻辑是否正确使用了带继承功能的上下文容器。
修复方式：统一入口创建、使用withContext/run包裹、在 finally 里清理。绝对不要出现“没有清理的全局上下文”。
4.2 切换丢失：异步子任务读不到上下文
表现：接口主流程正常，但内部发出去的异步任务或者定时任务里调用ContextManager.current()抛异常，提示“AppContext not initialized”。
原因是上下文没有跨异步边界传播。Node.js 里常见的触发场景是：用setTimeout或原生Promise创建的异步回调不在AsyncLocalStorage的传播范围内？实际上AsyncLocalStorage覆盖了大部分异步资源，但也有例外，比如worker_threads、child_process、原生插件回调。
排查步骤：
- 先确认异步任务的入口处是否被
withContext包裹。如果是在线程池回调里启动的，上下文自然带不过去。 - 如果是消息队列消费，消费端必须根据消息体重建上下文，不能指望上游的上下文自动传过来。
- 如果是
setImmediate/process.nextTick这类调度器，确认使用的是支持传播的封装版本。
修复方式：为异步入口补充withContext包裹，或者显式传递必要字段重建上下文。务必要在“子任务入口”创建上下文，不要在“父任务”里依赖自动穿透。
4.3 性能开销：频繁创建上下文对象
表现：接入 context-mode 后，QPS 出现轻微下降，接口 p99 延迟上升了几个毫秒。
通常是因为每个请求在入口处解析上下文时做了太多重活：解析 token 查了用户表、查了租户配置、查了十几个功能开关，每次都是实打实的数据库或者 Redis 请求。
优化手段：
- 减少同步调用。把能合并的查询合并成一次批量查询，或者做成异步预加载。
- 加缓存。用户角色、租户配置、开关配置这些变更不频繁的数据，用本地缓存或者 Redis 缓存，TTL 设个 30 秒到 5 分钟。
- 缩短上下文中的无效字段。有的团队把大对象塞进上下文，每次请求都复制一遍，白白增加内存占用和 GC 压力。
- 用
AsyncLocalStorage.run内部的对象引用而不是深拷贝。上下文对象本身应该不可变，但不要每次都JSON.parse(JSON.stringify(...))复制一份。
实测下来，合理优化后 context-mode 带来的开销可以控制在微秒级别，远小于一次数据库查询的零头，不会成为性能瓶颈。
4.4 调试困难：上下文不可见
表现：出了问题想查某个请求一路上的上下文变化，但日志里只有业务字段，没有环境、租户、开关信息，排障全靠猜。
解决思路是在日志系统里统一打印上下文摘要。不要在每个业务日志里手动拼字段，接一个日志装饰器：
function logWithContext(level: string, message: string) { const ctx = ContextManager.current(); const summary = { requestId: ctx.requestId, tenantId: ctx.tenantId, env: ctx.env, runtimeMode: ctx.runtimeMode, flags: ctx.flags, }; logger[level](message, summary); }所有业务模块统一用logWithContext打日志，线上排障时按 requestId 聚合日志，就能看到这个请求在哪个时刻处于什么样的上下文，再结合业务日志定位问题，效率会高非常多。
还有一个技巧：中间件里可以定期给慢请求输出一份“上下文快照”。比如某个请求处理超过 500ms，就记录一下当前上下文里的字段值，看看是不是某个灰度开关或者某个租户特有配置导致走了慢分支。这个快照信息在性能排查时价值极高。
4.5 常见问题速查表
| 问题 | 可能原因 | 快速排查方法 | 推荐修复 |
|---|---|---|---|
| 上下文串扰 | 全局栈未清理 | 对比 requestId 与线程 ID | 用带生命周期的容器，finally 清理 |
| 异步读不到上下文 | 跨边界未传播 | 检查异步入口是否有 run 包裹 | 子任务入口重建上下文 |
| 性能下降 | 入口解析太重 | 看入口中间件的调用链耗时 | 批量查询、加缓存、减少深拷贝 |
| 日志里看不到上下文 | 没有统一日志装饰器 | 检查业务模块日志输出 | 接 logWithContext 统一打印 |
| 开关不生效 | 灰度哈希不稳定 | 多次调用对比命中分组 | 换成稳定的 FNV/Murmur 哈希 |
| 上下文缺失异常频发 | 有入口漏配 | 查所有入口中间件覆盖情况 | 补充入口创建、加兜底异常上报 |
最后说一个我自己在实际工作中的体会：context-mode 这种抽象，最值钱的地方不在于代码写得多优雅，而在于它让整个团队对“系统处于什么场景”这件事形成了共同语言。以前评审方案时说“这个功能要在测试环境开、灰度环境开一半、线上给白名单用户开”，全靠嘴巴讲，代码里到处是补丁；现在一份上下文定义拍在那里，大家讨论问题都是“这个开关放进 flags 还是单独维度”“这个入口的上下文该不该继承父请求”，讨论质量完全不一样。
如果你正准备在项目里引入这套机制，我给你的建议是：不要追求一步到位，先做最基础的环境、租户、用户三个维度，跑通一条链路再说。等上下文真正在团队里扎下根，再慢慢把功能开关、灰度逻辑、运行模式加进去。它真正的价值不是第一天就体现出来的，而是在系统越来越复杂、新同事越来越多的时候，你才发现当初这个抽象替所有人省掉了多少不必要的沟通成本和排查时间。
