1. 从“context-mode”说起：一个被低估的工程概念

第一次看到“context-mode”这个词，很多人会以为是某个新出的框架或者库。其实不是。它更像是一种工程思维的切换开关——在开发过程中，主动区分“当前上下文”和“全局状态”，并据此决定代码的组织方式、数据的流转路径、以及模块之间的耦合程度。

我最早接触这个概念是在做一个多标签页后台管理系统的时候。当时每个标签页都要维护自己的筛选条件、分页状态、排序规则，但同时又共享用户信息、权限列表、字典数据。一开始我把所有状态都塞进一个全局store，结果就是：切换标签页时，上一个页面的筛选条件会“污染”下一个页面；刷新页面后，某些临时状态又莫名其妙丢失。后来我把状态拆成两层：全局上下文放用户、权限、字典；页面上下文放筛选、分页、临时选中项。代码量没增加多少，但bug率直接降了七成。

这就是context-mode的核心价值：它不解决具体的技术问题，它解决的是“状态该放在哪里”这个架构层面的问题。适合谁参考？我觉得三类人最需要：一是正在做中大型前端应用的开发者，二是经常被“状态不同步”问题困扰的后端接口设计者，三是任何需要管理多层级、多生命周期数据的工程师。

注意：context-mode不是某个具体工具或库的专利，它是一种跨语言、跨框架的通用思路。你在React、Vue、Flutter、甚至后端服务里都能用。

2. 核心思路拆解：为什么需要区分上下文模式

2.1 全局状态与局部状态的边界在哪里

很多项目一开始都是“全局状态一把梭”。用户信息、主题配置、当前页面数据、弹窗开关，全放在一个store里。小项目没问题，一旦页面超过十个、组件超过五十个，问题就来了。

我总结了一个简单的判断标准：如果一个状态在离开当前页面后就不再需要，那它就不应该进入全局上下文。比如一个订单列表页的“当前页码”，用户切换到商品列表页后，这个页码就没有意义了。它属于页面上下文，应该随页面组件的销毁而销毁。

反过来，用户登录后的token、权限码、系统主题，这些在整个应用生命周期内都有效，才应该放在全局上下文。这个边界如果划不清楚，就会出现两种典型症状：一是全局store越来越臃肿，每次修改都要小心翼翼；二是页面组件之间互相干扰，A页面的操作意外改变了B页面的显示。

2.2 context-mode的三种典型模式

在实际工程中，context-mode通常表现为三种模式，我分别叫它们隔离模式、继承模式和覆盖模式。

隔离模式最简单：每个页面或模块拥有完全独立的上下文，互不干扰。比如一个后台系统里，订单管理模块和商品管理模块各自维护自己的筛选条件、分页参数。实现方式可以是每个模块有自己的store实例，或者用React的Context Provider包裹在模块顶层。

继承模式稍微复杂：子上下文默认继承父上下文的值，但可以局部修改。比如一个多级审批流程，每一级审批页面都继承上一级的表单数据，但可以修改自己这一级的审批意见。这种模式在表单分步填写、向导式流程里特别常见。

覆盖模式最灵活：子上下文可以完全覆盖父上下文的某个字段，而不影响父上下文本身。比如一个全局主题是浅色，但某个页面需要深色背景，就可以在页面上下文中覆盖主题变量，离开页面后自动恢复。

这三种模式没有优劣之分，关键看你的业务场景。我一般建议：能用隔离就不用继承，能用继承就不用覆盖。因为每增加一层继承或覆盖，调试难度就上升一个等级。

2.3 为什么说context-mode是架构的“减压阀”

一个很现实的观察：大部分前端项目的技术债，不是来自算法复杂或者性能瓶颈，而是来自状态管理的混乱。一个状态被五个地方修改，每个地方都觉得自己是对的，最后谁也不知道这个状态到底应该是什么值。

context-mode的作用就是给这种混乱装一个“减压阀”。它强制你在写代码之前先想清楚：这个状态的生命周期是多长？它影响的范围有多大？谁有权修改它？想清楚这三个问题，代码结构自然就清晰了。

我试过一个极端案例：一个原本有三十多个全局状态的页面，经过context-mode重构后，全局状态只剩六个，其余全部下沉到页面上下文。重构后不仅代码更好读，连单元测试都好写了——因为页面上下文的初始状态可以独立构造，不需要模拟整个全局环境。

3. 实操落地：从零搭建一个context-mode架构

3.1 第一步：梳理状态清单与生命周期

动手写代码之前，先做一件事：把所有状态列出来，标注生命周期和影响范围。我通常用一张表格来整理，格式如下：

这张表看起来简单，但实际梳理时你会发现很多“灰色地带”。比如“当前选中的行”，如果选中后要跨页面传递，那它可能是流程上下文；如果只是当前页面高亮，那就是页面上下文。我的经验是：拿不准的时候，先放在页面上下文，等真的需要跨页面共享时再提升。因为提升容易，下沉难——提升只需要改引用路径，下沉可能要改十几个组件的props。

3.2 第二步：设计上下文的创建与销毁时机

全局上下文通常在应用启动时创建，在应用关闭时销毁。这个没什么争议。关键是页面上下文和流程上下文的创建销毁时机。

页面上下文我一般绑定在路由层面。以React为例，可以在路由组件的useEffect里初始化页面上下文，在清理函数里销毁。Vue的话，可以在路由守卫的beforeEach里创建，在afterEach里根据情况清理。核心原则是：页面上下文的生命周期不能超过页面的生命周期。

流程上下文稍微特殊，它可能跨越多个页面。比如一个五步的注册流程，每一步是一个独立页面，但共享同一个流程上下文。这种场景我通常用一个独立的Provider包裹整个流程路由，在流程入口创建，在流程出口销毁。中间任何一步退出，都要确保流程上下文被正确清理，否则下次进入流程时会读到脏数据。

提示：页面上下文的销毁一定要做彻底。我踩过的坑是只清了数据，忘了清定时器和事件监听，结果页面切换后定时器还在跑，造成内存泄漏和意外请求。

3.3 第三步：实现上下文的读写接口

上下文本身只是一个数据容器，真正决定它好不好用的是读写接口的设计。我一般会封装三个核心方法：getContext、setContext、resetContext。

getContext负责读取，可以带默认值。比如getContext('pageSize', 10)，如果上下文中没有pageSize，就返回10。setContext负责写入，可以支持批量写入和局部更新。resetContext负责重置，可以重置全部，也可以重置指定字段。

这里有一个细节值得展开：写入时要不要做不可变更新。在React生态里，通常要求不可变更新，否则组件不会重新渲染。但在Vue的响应式系统里，直接修改也可以。我的建议是：不管你用什么框架，都尽量保持不可变更新的习惯。因为不可变更新让状态变化可追溯，调试时能清楚看到每一步改了什么。

// 一个简单的上下文管理实现示例 function createContext(initialState = {}) { let state = { ...initialState }; const listeners = new Set(); return { get(key, defaultValue) { return state[key] !== undefined ? state[key] : defaultValue; }, set(updates) { state = { ...state, ...updates }; listeners.forEach(fn => fn(state)); }, reset(keys) { if (keys) { const newState = { ...state }; keys.forEach(k => delete newState[k]); state = newState; } else { state = { ...initialState }; } listeners.forEach(fn => fn(state)); }, subscribe(fn) { listeners.add(fn); return () => listeners.delete(fn); } }; }

这段代码虽然简单，但已经包含了上下文管理的核心要素：状态存储、读写接口、订阅通知、重置能力。你可以根据框架特性做适配，比如在React里用useSyncExternalStore来订阅，在Vue里用reactive来包裹。

3.4 第四步：处理上下文之间的通信

上下文之间不是孤立的。页面上下文可能需要读取全局上下文里的用户信息，流程上下文可能需要把最终结果写回全局上下文。这种通信如果处理不好，就会形成新的耦合。

我的做法是：只允许子上下文读取父上下文，不允许父上下文直接修改子上下文。页面上下文可以读全局的用户ID，但全局上下文不能直接改页面的筛选条件。如果确实需要从全局触发页面变化，应该通过事件或回调的方式，而不是直接操作。

这个规则看起来有点严格，但它能避免很多“牵一发而动全身”的问题。我见过一个项目，全局的“刷新”按钮直接调用了各个页面的重置方法，结果新增一个页面就要改一次全局代码。后来改成事件总线，全局只负责发事件，页面自己决定要不要响应，耦合度立刻降下来了。

4. 常见问题与排查技巧实录

4.1 上下文数据“串台”了怎么办

这是最常见的问题：A页面的数据出现在了B页面。原因通常有三个：一是上下文实例被复用，没有随页面销毁；二是全局上下文里存了本该属于页面的数据；三是异步请求的回调没有检查当前上下文是否还是原来的上下文。

排查思路：先确认上下文实例的生命周期。可以在创建和销毁时打日志，看是否成对出现。然后检查全局上下文里有没有“不该在那里”的数据。最后检查所有异步操作，确保回调执行时上下文仍然有效。我一般会在异步回调里加一个isContextValid的判断，如果上下文已经销毁，就直接丢弃结果。

4.2 上下文更新后组件不重新渲染

这个问题在React里特别常见。原因通常是上下文对象本身没有变化，只是内部属性变了，但组件订阅的是整个对象。解决办法是让订阅粒度更细，或者每次更新都返回新对象。

我试过两种方案：一种是使用useContext配合useReducer，每次dispatch都产生新state；另一种是用发布订阅模式，组件只订阅自己关心的字段。两种方案各有优劣，前者更符合React习惯，后者性能更好但代码稍复杂。我的建议是：如果上下文字段不多，用第一种；如果字段很多且更新频繁，用第二种。

4.3 上下文嵌套过深导致性能下降

当页面上下文嵌套在流程上下文里，流程上下文又嵌套在全局上下文里，每次顶层更新都会导致所有下层重新计算。这个问题在大型应用里很致命。

我的优化经验是：把不经常变的上下文和经常变的上下文分开。比如全局上下文里，用户信息和主题配置很少变，可以放在一个Provider里；而通知数量、未读消息数这种频繁变的，放在另一个Provider里。这样频繁更新的Provider不会影响只读用户信息的组件。

另外，善用memo和useMemo。对于上下文提供的值，如果依赖没变，就不要重新创建对象。这个细节能省下大量不必要的渲染。

4.4 常见问题速查表

注意：这张表里的问题我几乎都遇到过，尤其是“异步数据错乱”，在快速切换页面的场景下特别容易复现。后来我养成了一个习惯：任何异步请求的回调里，第一件事就是检查当前上下文是否还是发起请求时的上下文。

5. 进阶技巧：让context-mode真正提升开发效率

5.1 上下文快照与恢复

在一些复杂表单场景里，用户可能填了一半想先看看别的，回来再继续填。这时候上下文快照就很有用。实现方式很简单：在离开页面时把上下文序列化存起来，回来时反序列化恢复。

但要注意：不是所有数据都能序列化。函数、DOM引用、循环引用都不行。我的做法是只快照“纯数据”字段，对于不可序列化的字段，要么排除，要么用自定义的序列化方法。另外，快照的存储位置也有讲究：sessionStorage适合会话级快照，localStorage适合跨会话快照，内存变量适合临时快照。

5.2 上下文与URL的同步

页面上下文里的筛选条件、分页参数，如果能同步到URL，用户体验会好很多——刷新页面不丢状态，分享链接能还原场景。实现思路是：上下文初始化时从URL读取，上下文更新时写回URL。

这里有一个坑：URL更新不能太频繁，否则会污染浏览器历史记录。我一般用replaceState而不是pushState，并且加一个防抖。另外，URL参数的类型都是字符串，读取时要根据字段类型做转换，比如页码要转成数字，布尔值要转成true/false。

5.3 上下文调试工具

开发阶段，一个可视化的上下文调试工具能省很多时间。我通常会在开发环境里挂一个全局方法，比如window.__dumpContext()，调用后打印当前所有上下文的快照。更高级一点，可以做一个悬浮面板，实时显示上下文的变更历史。

这个工具不需要多复杂，关键是能快速回答三个问题：当前上下文里有什么？它是怎么变成这样的？谁改了它？我试过用简单的日志加时间戳，也试过用Redux DevTools的定制版，效果都不错。核心是让上下文的变化“可见”。

5.4 上下文模式的适用边界

context-mode不是银弹。有些场景用它反而会增加复杂度。比如一个简单的静态页面，没有状态共享需求，硬套上下文模式就是过度设计。再比如一个纯展示型组件，它的状态完全由props决定，也不需要上下文。

我的判断标准是：当状态需要跨组件、跨页面、跨生命周期共享时，才考虑上下文模式。如果状态只在单个组件内使用，用组件内部状态就够了。如果状态只在父子组件间传递，用props也够了。上下文模式解决的是“多对多”的状态共享问题，不是所有状态问题。

6. 一个真实项目的重构记录

去年我接手了一个后台管理系统的重构。原系统有四十多个页面，所有状态都在一个全局store里，代码量超过两万行。最典型的问题是：打开三个标签页，修改其中一个的筛选条件，另外两个也会跟着变。用户投诉了很多次，开发每次修都是打补丁，越修越乱。

重构的第一步就是引入context-mode。我们把全局store拆成三层：应用级上下文（用户、权限、字典）、模块级上下文（订单模块、商品模块、用户模块各自的共享状态）、页面级上下文（每个页面独立的筛选、分页、表单草稿）。

拆完之后，全局store从原来的三百多个字段降到四十多个。页面之间的干扰问题彻底消失。更意外的是，新来的开发上手速度明显变快了——因为每个页面的状态都在自己的上下文里，不需要理解整个全局store才能改一个页面。

重构过程中也遇到了一些阻力。有同事觉得“拆这么细太麻烦”，但上线后bug率下降了百分之六十，大家就都认可了。我的体会是：context-mode的前期成本确实比“一把梭”高，但后期的维护成本低得多。尤其是当项目需要长期迭代、多人协作时，这个投入非常值得。

7. 我个人的几条实操建议

第一，从新页面开始用context-mode，不要一上来就重构老代码。新页面没有历史包袱，用新模式写起来很自然。等团队熟悉了，再逐步重构老页面。一次性全量重构风险太大。

第二，上下文命名要带层级前缀。比如global_userInfo、page_orderList_filter、flow_register_step。这样在调试时一眼就能看出这个状态属于哪一层，不会混淆。

第三，给每个上下文写一个简单的文档。不需要多正式，几行注释就行：这个上下文存什么、生命周期多长、谁可以读写。我见过太多项目，上下文建了一堆，但没人说得清每个是干什么的，最后又变成新的混乱。

第四，定期清理不再使用的上下文字段。业务迭代过程中，有些字段会废弃。如果不及时清理，上下文会越来越臃肿。我一般每个迭代周期检查一次，把没人读的字段删掉。

第五，不要为了用而用。context-mode是一种手段，不是目的。如果项目很简单，用最简单的方式就好。我见过一个只有三个页面的小工具，硬是套了五层上下文，结果代码比业务逻辑还复杂。这就本末倒置了。

最后再分享一个小技巧：在上下文初始化时，可以加一个debug参数。开发环境自动打开，生产环境自动关闭。打开时，每次上下文变更都会在控制台打印变更前后的差异。这个功能帮我定位过好几次“莫名其妙”的状态变化，强烈建议你试试。