1. 从"context-mode"这个词说起：它到底指什么

第一次看到"context-mode"这个标题，很多人会下意识地把它当成某个具体框架的配置项，或者某个库里的一个枚举值。但如果你在工程一线待过几年，就会发现这个词其实指向一个更底层、更普遍的问题：同一段逻辑，在不同上下文里应该表现出不同的行为模式。这不是某个语言独有的特性，而是所有稍微复杂一点的系统都绕不开的设计命题。

我最早接触这个概念，是在处理一个多端渲染的项目时。同一份数据模型，在列表页只需要展示摘要，在详情页需要完整字段，在编辑态又需要带上校验规则和脏标记。最初的做法是写三套渲染函数，结果维护成本爆炸——改一个字段要同步改三处，漏一处就是线上事故。后来我们把"当前处于什么上下文"抽象成一个显式的模式参数，让同一套核心逻辑根据模式走不同分支，代码量直接砍掉一半，bug 率也明显下降。这就是 context-mode 思维最朴素的价值：用模式切换替代逻辑复制。

所以这篇内容不是讲某个具体 API 怎么调用，而是把 context-mode 当作一个设计范式来拆解。它适合谁看？如果你正在被"同一功能多场景适配"折磨，如果你写的代码里到处是if (isEdit) ... else if (isPreview) ...这种散落各处的判断，如果你在带团队时发现新人总是搞不清"这段逻辑到底在哪个场景生效"，那这篇就是写给你的。我会从它解决的真实问题讲起，拆解几种常见的实现路径，给出可直接抄的代码骨架，最后重点讲那些文档里不会写、只有踩过才知道的坑。

需要先说明一点：context-mode 不是一个标准化的术语，不同团队、不同项目里它的具体形态可能差别很大。有的把它做成一个全局状态，有的做成函数入参，有的做成依赖注入的上下文对象。但万变不离其宗，核心都是把"当前处于什么模式"这件事显式化、集中化、可传递化。理解了这一点，后面所有的实现细节你都能自己推导出来。

2. 为什么散落的模式判断迟早会失控

2.1 一个真实项目的演化轨迹

我拿一个虚构但极具代表性的项目来举例，叫它"某跨平台内容系统"。这个系统要同时服务三种场景：移动端只读浏览、桌面端可编辑、后台管理端带审核流。最初版本里，开发者用了一个全局变量currentScene，在需要区分的地方直接读它：

function renderField(field) { if (currentScene === 'mobile') { return renderReadonly(field); } else if (currentScene === 'desktop') { return renderEditable(field); } else if (currentScene === 'admin') { return renderWithAudit(field); } }

这个写法在只有三五个字段的时候没问题。但当字段数量涨到几十个，场景增加到五种，问题就来了。首先是判断逻辑重复：几乎每个渲染函数里都有类似的三段式 if-else，改一处场景名要全局搜索替换。其次是隐式依赖：renderField表面上只接收field，实际上还偷偷依赖全局的currentScene，你单独测试这个函数时根本不知道要预设什么环境。最后是组合爆炸：当"移动端 + 审核中"这种交叉场景出现时，原来的三段式 if-else 根本表达不了，只能继续嵌套，代码迅速变成意大利面条。

这个演化轨迹不是个例。我见过太多项目都是从"就一个全局变量嘛，简单"开始，最后变成没人敢动的祖传代码。根本原因在于：模式判断被分散到了各个角落，而不是集中管理。每散落一处，就多一个可能不一致的点，多一个测试盲区，多一个新人理解成本。

2.2 散落判断的三宗罪

把问题归纳一下，散落的模式判断主要有三个致命伤。

第一是一致性无法保证。假设产品要求"移动端在审核态下隐藏敏感字段"，这个规则如果写在渲染函数里，那导出功能、搜索功能、统计功能里是不是也要各自实现一遍？只要有一处漏了，就是数据泄露级别的 bug。而如果模式判断是集中的，你只需要在一个地方定义"审核态下敏感字段不可见"，所有下游自动继承。

第二是测试成本指数上升。散落的判断意味着每个函数都要为所有模式组合写测试用例。三个模式、五个函数，就是十五个测试场景。而集中管理后，模式切换逻辑本身只需要测一次，业务函数只需要测"给定模式下的行为"，测试矩阵大幅缩小。

第三是扩展时牵一发动全身。新增一个模式，散落写法要改所有判断点；集中写法只需要在模式定义处加一项，再补充该模式特有的分支即可。这个差异在项目初期不明显，但到了中期，就是"改一天"和"改一周"的区别。

这里有个反直觉的点：很多人觉得集中管理会增加抽象层，让代码更复杂。但实测下来，只要抽象得当，集中管理反而让代码更简单，因为它消除了重复，而重复才是复杂度的真正来源。

2.3 什么情况下可以不用 context-mode

也不是所有场景都值得上这套设计。如果满足以下全部条件，用简单的布尔参数就够了：模式只有两种、判断点不超过三个、未来半年内没有扩展计划。比如一个纯展示组件，只有"亮色/暗色"两种主题，那传个isDark布尔值完全够用，硬套模式对象反而是过度设计。

判断标准很简单：当你发现同一个判断在三个以上地方出现，或者模式数量超过两个，或者模式之间开始出现组合需求时，就该考虑引入 context-mode 了。这个阈值是我自己踩坑总结的，不一定绝对，但作为参考线很好用。

3. 几种主流的 context-mode 实现路径对比

3.1 全局状态式：最直接但最危险

全局状态式就是把当前模式存在一个全局可访问的地方，所有函数直接读。实现最简单，一行let currentMode = 'default'加一个 setter 就完事。但它的问题和它的简单一样明显：隐式依赖、难以测试、并发不安全。

在单线程、单用户的场景下（比如一个纯前端页面），全局状态式勉强能用。但一旦涉及服务端渲染、多请求并发、或者同一进程内处理多个用户上下文，全局状态就会串味。我见过一个服务端项目，用全局变量存当前用户的语言偏好，结果高并发下 A 用户的请求读到了 B 用户的语言设置，排查了两天才定位到。所以全局状态式我的建议是：除非你能保证整个生命周期内只有一个上下文，否则不要用。

3.2 参数传递式：显式但啰嗦

参数传递式就是把模式作为函数入参，一层层往下传。它最大的优点是显式：看函数签名就知道它依赖什么模式，测试时直接传参即可，没有任何隐藏状态。缺点是透传成本高：如果调用链有十层，中间八层函数根本不用模式，却也要在签名里带着它，纯属噪音。

这个问题的经典解法是"上下文对象"：把所有跨层传递的东西打包成一个context对象，需要用的层从里面取，不需要的层原样透传。这样至少签名稳定，加新字段不用改所有中间层。但透传本身还是免不了，只是从传多个参数变成传一个对象。

3.3 依赖注入式：解耦但需要框架支撑

依赖注入式是把模式作为一个可注入的依赖，由容器在运行时决定注入哪个实现。这是最解耦的方案，业务代码完全不关心模式从哪来，只关心"我拿到的是一个符合接口的对象"。但它需要 DI 容器或类似的框架支撑，在小型项目里引入成本偏高。

我个人的经验是：中大型项目、多人协作、生命周期长的，值得上依赖注入；小型工具、一次性脚本、原型验证，参数传递式足够。全局状态式基本可以排除，除非是极其简单的单上下文场景。

3.4 三种路径的横向对比

这张表不是让你照搬，而是帮你快速定位自己项目该选哪条路。选型的核心就一句话：上下文越复杂、生命周期越长、并发越高，就越往依赖注入靠；反之参数传递就够。

4. 手写一个可复用的 context-mode 骨架

4.1 模式定义：用枚举而非字符串

第一步是把模式定义清楚。很多人图省事直接用字符串'edit'、'view'，结果拼写错误要到运行时才暴露。正确做法是用常量或枚举：

const ContextMode = Object.freeze({ VIEW: 'view', EDIT: 'edit', AUDIT: 'audit', EXPORT: 'export' });

Object.freeze防止运行时被意外修改。如果你的语言支持真正的枚举（比如 TypeScript 的 enum 或 Rust 的 enum），优先用原生枚举，还能获得编译期检查。

4.2 上下文对象：承载模式与相关数据

模式本身往往不够，还需要携带与该模式相关的数据。比如编辑模式需要脏字段集合，审核模式需要审核人信息。把这些打包成一个上下文对象：

function createContext(mode, payload = {}) { if (!Object.values(ContextMode).includes(mode)) { throw new Error(`Unknown context mode: ${mode}`); } return { mode, payload, is(m) { return this.mode === m; }, isAny(...modes) { return modes.includes(this.mode); } }; }

这里加了is和isAny两个辅助方法，让下游判断更简洁。注意构造函数里做了模式合法性校验，非法模式在创建时就报错，而不是等到使用时才出问题，这是快速失败原则的体现。

4.3 行为分发：策略表替代 if-else 链

有了上下文对象，接下来是行为分发。不要写一长串 if-else，用策略表：

const fieldRenderers = { [ContextMode.VIEW]: (field) => renderReadonly(field), [ContextMode.EDIT]: (field) => renderEditable(field), [ContextMode.AUDIT]: (field) => renderWithAudit(field), [ContextMode.EXPORT]: (field) => renderPlain(field) }; function renderField(field, ctx) { const renderer = fieldRenderers[ctx.mode]; if (!renderer) { throw new Error(`No renderer for mode: ${ctx.mode}`); } return renderer(field); }

策略表的好处是新增模式只需加一行，而且所有模式的处理逻辑一目了然。如果某个模式需要特殊的前置处理，可以在调用 renderer 之前统一做，避免每个 renderer 里重复。

4.4 组合模式的处理：优先级与降级

真实项目里经常遇到组合场景，比如"审核态下的编辑"既要走审核逻辑又要走编辑逻辑。这时候需要定义优先级：

const modePriority = [ ContextMode.AUDIT, ContextMode.EDIT, ContextMode.EXPORT, ContextMode.VIEW ]; function resolveMode(modes) { for (const m of modePriority) { if (modes.includes(m)) return m; } return ContextMode.VIEW; }

这段逻辑的意思是：当多个模式同时存在时，按优先级取最高的那个作为主模式。优先级顺序不是拍脑袋定的，而是根据业务规则：审核态最严格，所以优先级最高；编辑态次之；导出态再次；只读态兜底。优先级一定要和产品、测试对齐后再写死，不要藏在代码里让后人猜。

5. 落地时最容易踩的五个坑

5.1 坑一：模式判断散落在业务逻辑深处

最常见的错误是：虽然定义了上下文对象，但在业务函数里还是到处if (ctx.mode === 'edit')。这等于换汤不换药，只是把全局变量换成了参数，散落的问题一点没解决。正确做法是把模式判断尽量上提到分发层，业务函数只处理"当前模式下的具体行为"，不关心自己是怎么被选中的。

我见过一个项目，上下文对象传得好好的，结果在某个深层函数里又出现了if (ctx.is('edit'))，而这个判断本可以在分发层解决。这种"漏网之鱼"是最难排查的，因为它破坏了整个设计的统一性。建议在代码评审时专门检查：业务函数里是否出现了模式判断，出现就要问一句"这个判断能不能上提"。

5.2 坑二：模式与状态混为一谈

模式和状态是两回事。模式是"当前处于哪种工作方式"，状态是"当前数据是什么样"。比如"编辑模式"是模式，"有未保存修改"是状态。很多人把两者混在一起，导致模式对象越来越臃肿，最后变成一个什么都装的垃圾袋。

正确的边界是：模式决定行为分支，状态决定分支内的具体表现。编辑模式下，字段是否可编辑由模式决定；字段当前值是什么，由状态决定。两者分开管理，各自演化，互不干扰。

5.3 坑三：忘记处理未知模式

新增模式时，如果某个分发点忘了加对应处理，运行时就会拿到 undefined 然后崩溃。防御性做法是在分发层统一兜底：

function safeDispatch(table, mode, fallback) { return table[mode] || fallback; }

兜底策略要慎重：能报错就报错，不要静默降级。静默降级会让问题隐藏，等到用户反馈时已经晚了。我倾向于在开发环境直接抛错，生产环境记录日志并降级到最安全的模式（通常是只读）。

5.4 坑四：模式切换时的副作用没清理

从编辑模式切到只读模式时，如果编辑态留下的临时数据、定时器、事件监听没清理，就会造成内存泄漏或状态污染。每次模式切换都应该是一个明确的清理点。我的做法是给上下文对象加一个dispose钩子，切换前调用：

function switchMode(ctx, newMode) { if (ctx.onExit) ctx.onExit(); const next = createContext(newMode, ctx.payload); if (next.onEnter) next.onEnter(); return next; }

这样每个模式可以定义自己的进入和退出逻辑，切换时自动执行，不会遗漏。

5.5 坑五：测试只测单模式，不测切换

单模式测试只能保证"在某个模式下行为正确"，但模式切换才是 bug 高发区。我建议至少补三类测试：切换前后的状态一致性、切换时的清理是否执行、非法切换是否被拦截。这三类测试写起来不复杂，但能拦住大部分线上问题。

6. 从模式到机制：让 context-mode 真正产生复利

6.1 把模式变成可观测的指标

模式一旦集中管理，就顺带获得了一个好处：可以埋点统计各模式的使用频率和切换路径。这些数据对产品决策极有价值。比如你发现 80% 的用户从不进入编辑模式，那编辑功能的投入产出比就要重新评估；你发现用户频繁在审核和编辑之间来回切，那说明这两个模式的边界设计可能有问题。

埋点很简单，在createContext和switchMode里加一行日志上报即可。关键是要提前和产品对齐要采集哪些维度，别等上线了才发现数据不够用。

6.2 用模式驱动权限与审计

模式天然适合承载权限语义。审核模式意味着更高的权限要求，导出模式意味着数据要脱敏。把这些规则挂在模式定义上，而不是散落在各处：

const modePolicy = { [ContextMode.AUDIT]: { requiresRole: 'auditor', auditLog: true }, [ContextMode.EXPORT]: { requiresRole: 'member', maskSensitive: true }, [ContextMode.EDIT]: { requiresRole: 'editor', auditLog: true }, [ContextMode.VIEW]: { requiresRole: 'guest', auditLog: false } };

这样权限校验和审计日志都变成模式切换的自动副作用，不需要在每个业务函数里手动检查。安全相关的逻辑越集中越好，因为集中才能审计，分散必然有遗漏。

6.3 模式作为团队沟通的通用语言

这一点听起来虚，但实际价值很高。当团队里所有人都用同一套模式名称沟通时，"这个功能在审核态下怎么表现"就变成一个精确的问题，而不是模糊的讨论。产品、开发、测试可以围绕模式清单对齐需求，测试可以按模式矩阵设计用例，新人可以按模式理解系统。

我带的团队里，每个项目的模式清单都会写进设计文档的第一页，包含每个模式的定义、触发条件、行为差异、权限要求。这份文档成了需求评审的基准，很多歧义在评审阶段就被消除了。context-mode 最大的复利不在代码层面，而在沟通层面。

7. 我在实际项目里的一些体会

最后分享几个零散但实用的经验。

第一，模式数量控制在七个以内。超过七个，人脑就很难同时记住所有模式的差异，判断也容易出错。如果业务真的需要更多模式，考虑分层：先分大类，大类下再分小类，而不是平铺一堆模式。

第二，模式命名用业务语言，不用技术语言。叫audit比叫readonlyWithLog好，因为前者是业务概念，后者是实现细节。业务概念稳定，实现细节会变。命名跟着业务走，代码寿命更长。

第三，给每个模式写一句人话描述。比如"审核模式：审核员查看待审内容，可批准或驳回，敏感字段可见但操作留痕"。这句话放在模式定义旁边，比任何注释都有用，新人一看就懂。

第四，模式切换要有明确的用户可见反馈。用户从浏览切到编辑，界面应该有明显变化，否则用户不知道自己现在处于什么状态，容易误操作。这个反馈可以是按钮状态、颜色变化、或者一个模式指示器。

第五，定期回顾模式清单。业务在变，模式也会过时。我建议每个季度过一遍模式清单，问三个问题：有没有模式已经没人用了？有没有新模式需求？现有模式的边界还清晰吗？这个习惯能防止模式体系慢慢腐化。

context-mode 说到底是一种把隐式约定变成显式契约的工程实践。它不炫技，不复杂，但能实实在在降低系统的理解成本和维护成本。如果你现在的项目里还有散落各处的模式判断，不妨从下一个功能开始，试着把它们收拢起来。收拢的过程本身，就是一次对系统理解的梳理。