1. 从context-mode说起一个被低估的工程概念第一次看到context-mode这个词很多人会下意识地把它归到某个具体框架的API文档里觉得无非是某个函数的一个参数选项。但如果你在工程一线待过几年尤其是在做系统设计、状态管理、AI应用编排或者复杂前端交互的时候你会发现上下文模式其实是一个贯穿始终的底层设计哲学。它不是一个库也不是一个工具而是一种组织代码、管理状态、隔离逻辑的思维方式。我最早系统性地接触这个概念是在处理一个多轮对话系统的状态管理问题。当时系统里同时存在用户会话状态、页面路由状态、异步请求状态和权限校验状态四套状态互相耦合改一处崩三处。后来我们把所有状态按照上下文重新划分每一类上下文有独立的生命周期、独立的读写规则、独立的失效策略整个系统才变得可维护。那次经历让我意识到context-mode的核心价值不在于某个具体实现而在于它提供了一种分而治之的边界划分方法。这篇文章适合谁看如果你正在做以下任何一件事那这篇内容对你会有直接帮助正在设计一个需要管理多种状态的前端应用正在搭建多轮对话或Agent系统正在处理多环境配置切换或者你只是单纯觉得代码里到处传参、到处判断环境、到处写if-else很痛苦。我会从设计思路、核心机制、实操落地、问题排查四个维度把context-mode这个东西讲透并且给出可以直接抄作业的方案。需要提前说明的是context-mode并不是某个特定产品的专有名词不同技术栈下它的具体形态不同。我下面讲的内容是基于我在多个项目中反复验证过的通用实践结合常见的工程场景做的合理演绎。你完全可以根据自己的技术栈做适配。2. 内容整体设计与思路拆解2.1 为什么需要上下文模式而不是全局状态很多项目一开始都是全局状态一把梭。一个全局store什么数据都往里塞组件需要什么就取什么。小项目这样干没问题一旦项目规模上去问题就来了。全局状态最大的毛病是没有边界——任何模块都可以读写任何数据你根本不知道一个状态被谁改了、什么时候改的、改了之后会影响谁。上下文模式的核心思路是把状态按照使用场景而不是数据类型来划分。比如用户信息在登录场景下是一个上下文在个人主页展示场景下是另一个上下文在权限校验场景下又是另一个上下文。这三个上下文可能共享同一份底层数据但它们的读写规则、生命周期、失效条件完全不同。我举个具体的例子。假设你在做一个电商App用户从浏览商品到下单支付中间会经历商品详情页、购物车、订单确认、支付四个页面。如果用全局状态你需要维护一个巨大的orderState里面包含商品列表、优惠券、地址、支付方式、发票信息等等。任何一个页面修改了这个对象其他页面都得重新计算。而用上下文模式你可以拆成四个独立的上下文商品上下文只读来自服务端、购物车上下文可读写本地持久化、订单上下文可读写会话级、支付上下文只写一次性。每个上下文有自己的边界互不干扰。这种拆分带来的好处是显而易见的。首先是可测试性每个上下文可以独立测试不需要mock整个全局状态。其次是可维护性修改购物车逻辑不会影响支付逻辑。最后是性能每个上下文可以独立做缓存和失效策略不需要全量更新。2.2 上下文模式与其他状态管理方案的对比市面上常见的状态管理方案大致有这么几类全局单例store如Redux、Vuex、组件内状态如React的useState、服务端状态缓存如React Query、SWR、以及上下文模式。它们之间不是替代关系而是互补关系。方案适用场景边界清晰度生命周期管理跨组件共享全局单例store应用级共享状态低手动管理强组件内状态局部UI状态高自动跟随组件弱服务端状态缓存异步数据获取中自动缓存失效中上下文模式场景化状态隔离高按上下文定义按需共享上下文模式的独特之处在于它既不像全局store那样无边无际也不像组件状态那样难以共享。它通过上下文提供者和上下文消费者的配对实现了按需共享和边界隔离。你可以把它理解成一种有作用域的状态管理。在实际项目中我通常会把上下文模式和服务端状态缓存结合使用。服务端状态缓存负责数据的获取和同步上下文模式负责数据的场景化组织和读写控制。这样既避免了重复请求又保证了状态边界清晰。2.3 上下文模式的核心设计原则设计上下文模式时我遵循三条原则这三条原则是我踩了无数坑之后总结出来的。第一条原则一个上下文只服务一个场景。不要试图做一个万能上下文那只会变成另一个全局状态。每个上下文应该对应一个明确的用户场景或业务流程。比如登录上下文只负责登录相关的状态主题上下文只负责主题切换相关的状态。第二条原则上下文的读写接口要显式定义。不要直接把原始状态暴露出去而是提供明确的读方法和写方法。这样做的好处是你可以在写方法里加入校验、日志、副作用触发等逻辑而且当状态结构变化时只需要改上下文内部实现外部调用方不受影响。第三条原则上下文的生命周期要明确。有些上下文是应用级的从启动到关闭一直存在有些是会话级的用户登出就销毁有些是页面级的离开页面就清理。明确生命周期可以避免内存泄漏和状态污染。注意上下文模式不是银弹。如果你的应用只有两三个页面状态之间几乎没有耦合那用全局状态或者组件状态就够了。引入上下文模式反而会增加复杂度。判断标准很简单当你发现状态之间的耦合关系已经无法用简单的父子传递或全局store来管理时就是引入上下文模式的时机。3. 核心细节解析与实操要点3.1 上下文的定义与创建定义一个上下文本质上是在定义一个状态容器的规格。这个规格包含三部分状态结构、读写接口、生命周期钩子。以JavaScript/TypeScript生态为例一个典型的上下文定义长这样interface CartContext { // 状态结构 state: { items: CartItem[]; totalPrice: number; couponCode: string | null; }; // 读接口 getItems: () CartItem[]; getTotalPrice: () number; // 写接口 addItem: (item: CartItem) void; removeItem: (itemId: string) void; applyCoupon: (code: string) Promiseboolean; // 生命周期 reset: () void; }这个定义里state是私有的外部只能通过getItems和getTotalPrice来读取。addItem和removeItem是同步写操作applyCoupon是异步写操作因为它需要校验优惠券有效性。reset用于在用户登出或切换账号时清空上下文。创建上下文时我建议使用工厂函数而不是直接导出单例。工厂函数的好处是你可以在测试时创建多个独立实例互不干扰。而且工厂函数可以接收初始化参数比如从服务端预取的数据。function createCartContext(initialItems: CartItem[] []): CartContext { let state { items: initialItems, totalPrice: calculateTotal(initialItems), couponCode: null, }; return { getItems: () [...state.items], getTotalPrice: () state.totalPrice, addItem: (item) { state.items.push(item); state.totalPrice calculateTotal(state.items); }, removeItem: (itemId) { state.items state.items.filter(i i.id ! itemId); state.totalPrice calculateTotal(state.items); }, applyCoupon: async (code) { const valid await validateCoupon(code); if (valid) { state.couponCode code; state.totalPrice calculateTotal(state.items, code); } return valid; }, reset: () { state { items: [], totalPrice: 0, couponCode: null }; }, }; }注意getItems返回的是数组的浅拷贝这是为了防止外部直接修改内部状态。这个细节很多人会忽略但它是保证上下文边界不被破坏的关键。3.2 上下文的注入与消费定义好上下文之后下一步是把它注入到需要它的组件或模块中。注入方式取决于你的技术栈。在React里通常用Context Provider在Vue里用provide/inject在纯JavaScript模块里可以用依赖注入容器。不管用什么方式核心原则是一样的消费者不应该关心上下文是怎么创建的只应该关心怎么使用它。这意味着上下文的创建逻辑应该集中在应用入口或模块初始化阶段而不是散落在各个消费点。我见过一种反模式就是在组件内部直接创建上下文实例。这样做的问题是每次组件重新渲染都会创建一个新实例状态完全丢失。正确的做法是在应用顶层创建上下文实例然后通过Provider向下传递。// 应用入口 const cartContext createCartContext(); function App() { return ( CartProvider value{cartContext} Router Routes Route path/cart element{CartPage /} / Route path/checkout element{CheckoutPage /} / /Routes /Router /CartProvider ); } // 消费点 function CartPage() { const cart useCartContext(); const items cart.getItems(); // ... }这种模式下CartPage和CheckoutPage共享同一个cartContext实例状态自然同步。而且因为上下文实例是在App外部创建的它不会因为App重新渲染而重建。3.3 上下文的组合与嵌套实际项目中一个页面往往需要同时使用多个上下文。比如订单确认页需要购物车上下文、地址上下文、支付上下文。这时候就涉及上下文的组合问题。最简单的组合方式是嵌套Provider。但嵌套层数多了之后代码会变得很难看而且性能也会受影响因为每一层Provider都会触发一次React的context查找。我的做法是创建一个上下文聚合器把多个上下文合并成一个复合上下文。这样只需要一层Provider消费点也可以一次性拿到所有需要的上下文。interface AppContexts { cart: CartContext; address: AddressContext; payment: PaymentContext; } function createAppContexts(): AppContexts { return { cart: createCartContext(), address: createAddressContext(), payment: createPaymentContext(), }; } const AppContext React.createContextAppContexts | null(null); function useAppContexts(): AppContexts { const ctx React.useContext(AppContext); if (!ctx) throw new Error(AppContexts not provided); return ctx; }这种聚合方式的好处是消费点只需要调用一次useAppContexts就能拿到所有上下文。而且当某个上下文内部状态变化时只有真正使用了该上下文的组件会重新渲染其他组件不受影响。提示聚合上下文时要注意不要把不相关的上下文强行合并。比如购物车上下文和主题上下文就没有必要放在一起。聚合的原则是同一业务场景下经常一起使用的上下文。3.4 上下文的持久化与恢复很多上下文需要持久化比如购物车、用户偏好、草稿内容。持久化的时机和策略直接影响用户体验。我的经验是持久化策略应该由上下文自己决定而不是由消费点决定。上下文内部可以在写操作之后自动触发持久化也可以在生命周期钩子里做批量持久化。消费点不需要关心数据存到了哪里、什么时候存的。function createCartContext(initialItems: CartItem[] []): CartContext { // 从localStorage恢复 const saved localStorage.getItem(cart); let state saved ? JSON.parse(saved) : { items: initialItems, totalPrice: 0, couponCode: null }; function persist() { localStorage.setItem(cart, JSON.stringify(state)); } return { // ... addItem: (item) { state.items.push(item); state.totalPrice calculateTotal(state.items); persist(); // 写操作后自动持久化 }, // ... }; }这里有个细节需要注意持久化的数据要做版本管理。因为随着业务迭代状态结构可能会变化旧版本的数据直接反序列化可能会出错。我的做法是在持久化数据里加一个version字段恢复时检查版本号不匹配就丢弃或迁移。const PERSIST_VERSION 2; function persist() { localStorage.setItem(cart, JSON.stringify({ version: PERSIST_VERSION, data: state, })); } function restore() { const raw localStorage.getItem(cart); if (!raw) return null; const parsed JSON.parse(raw); if (parsed.version ! PERSIST_VERSION) { localStorage.removeItem(cart); return null; } return parsed.data; }这个版本管理机制看起来简单但在实际项目中能避免很多用户升级后数据错乱的问题。我踩过一次坑就是因为没有做版本管理结果状态结构变更后老用户恢复出来的数据缺少字段导致页面白屏。4. 实操过程与核心环节实现4.1 从零搭建一个上下文模式的状态层下面我以一个多步骤表单为例完整走一遍上下文模式的搭建过程。这个表单有三个步骤基本信息、地址信息、确认提交。每个步骤有自己的状态步骤之间需要共享部分数据。第一步定义每个步骤的上下文规格。// 基本信息上下文 interface BasicInfoContext { state: { name: string; email: string; phone: string }; setName: (v: string) void; setEmail: (v: string) void; setPhone: (v: string) void; validate: () { valid: boolean; errors: string[] }; } // 地址上下文 interface AddressContext { state: { province: string; city: string; detail: string }; setProvince: (v: string) void; setCity: (v: string) void; setDetail: (v: string) void; validate: () { valid: boolean; errors: string[] }; } // 表单聚合上下文 interface FormContext { basicInfo: BasicInfoContext; address: AddressContext; currentStep: number; goNext: () boolean; goPrev: () void; submit: () Promiseboolean; }第二步实现各个上下文的工厂函数。这里以基本信息上下文为例。function createBasicInfoContext(): BasicInfoContext { let state { name: , email: , phone: }; return { get state() { return { ...state }; }, setName: (v) { state.name v; }, setEmail: (v) { state.email v; }, setPhone: (v) { state.phone v; }, validate: () { const errors: string[] []; if (!state.name.trim()) errors.push(姓名不能为空); if (!/^[^][^]\.[^]$/.test(state.email)) errors.push(邮箱格式不正确); if (!/^\d{11}$/.test(state.phone)) errors.push(手机号格式不正确); return { valid: errors.length 0, errors }; }, }; }第三步实现表单聚合上下文负责步骤切换和最终提交。function createFormContext(): FormContext { const basicInfo createBasicInfoContext(); const address createAddressContext(); let currentStep 0; return { basicInfo, address, get currentStep() { return currentStep; }, goNext: () { if (currentStep 0) { const result basicInfo.validate(); if (!result.valid) return false; } if (currentStep 1) { const result address.validate(); if (!result.valid) return false; } currentStep Math.min(currentStep 1, 2); return true; }, goPrev: () { currentStep Math.max(currentStep - 1, 0); }, submit: async () { const basicResult basicInfo.validate(); const addressResult address.validate(); if (!basicResult.valid || !addressResult.valid) return false; const payload { ...basicInfo.state, ...address.state, }; const response await fetch(/api/submit, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(payload), }); return response.ok; }, }; }第四步在应用入口创建表单上下文并通过Provider注入。const FormContextReact React.createContextFormContext | null(null); function App() { const formContext React.useMemo(() createFormContext(), []); return ( FormContextReact.Provider value{formContext} FormWizard / /FormContextReact.Provider ); } function useFormContext(): FormContext { const ctx React.useContext(FormContextReact); if (!ctx) throw new Error(FormContext not provided); return ctx; }第五步在各个步骤组件中消费上下文。function BasicInfoStep() { const form useFormContext(); const { name, email, phone } form.basicInfo.state; return ( div input value{name} onChange{e form.basicInfo.setName(e.target.value)} / input value{email} onChange{e form.basicInfo.setEmail(e.target.value)} / input value{phone} onChange{e form.basicInfo.setPhone(e.target.value)} / button onClick{() form.goNext()}下一步/button /div ); }这套方案跑下来整个表单的状态管理非常清晰。每个步骤只关心自己的上下文步骤切换和提交逻辑集中在聚合上下文里。新增步骤只需要新增一个上下文并在聚合上下文里注册不需要改动已有代码。4.2 上下文模式在异步场景下的处理异步操作是上下文模式最容易出问题的地方。因为异步操作的结果可能在上下文已经销毁之后才返回这时候如果直接更新状态就会造成内存泄漏或者状态污染。我的处理方式是在上下文内部维护一个活跃标记异步操作开始前检查标记操作完成后再次检查如果上下文已经销毁就丢弃结果。function createAsyncContext() { let active true; let state { data: null, loading: false, error: null }; async function fetchData() { if (!active) return; state.loading true; try { const result await api.getData(); if (!active) return; // 上下文已销毁丢弃结果 state.data result; state.error null; } catch (e) { if (!active) return; state.error e.message; } finally { if (active) state.loading false; } } return { get state() { return { ...state }; }, fetchData, destroy: () { active false; }, }; }这个模式看起来简单但它解决了一个非常实际的问题。我在一个实时搜索功能里就遇到过用户快速输入时触发了多个搜索请求后发的请求先返回导致搜索结果错乱。加上活跃标记之后只有最后一次请求的结果会被采纳前面的请求结果全部丢弃。注意活跃标记只能解决上下文销毁后丢弃结果的问题不能解决请求竞态的问题。请求竞态需要用请求ID或AbortController来处理。两者结合使用才能保证异步场景下的状态一致性。4.3 上下文模式的性能优化上下文模式用不好性能会比全局状态还差。因为每个上下文都是一个独立的订阅源如果消费点订阅了太多上下文任何一个上下文变化都会触发重新渲染。优化的核心思路是按需订阅。消费点只订阅自己真正需要的上下文而不是一次性订阅所有上下文。在React里可以通过拆分Context来实现。比如把FormContext拆成BasicInfoContext、AddressContext、StepContext三个独立的Context消费点按需使用。const BasicInfoContextReact React.createContextBasicInfoContext | null(null); const AddressContextReact React.createContextAddressContext | null(null); const StepContextReact React.createContextStepContext | null(null); function BasicInfoStep() { const basicInfo React.useContext(BasicInfoContextReact); // 只订阅basicInfoaddress和step变化不会触发重新渲染 }另一个优化点是上下文的粒度。不要把太多状态塞进一个上下文也不要把状态拆得太碎。我的经验是一个上下文的状态字段控制在5到10个之间比较合适。太少会导致上下文数量爆炸太多会导致订阅粒度太粗。还有一个容易被忽略的优化点是上下文的创建时机。如果上下文是在组件内部创建的每次组件重新渲染都会创建新实例导致所有消费点重新渲染。正确的做法是在组件外部或者用useMemo/useRef来保证上下文实例的稳定性。// 错误做法 function App() { const formContext createFormContext(); // 每次渲染都创建新实例 return Provider value{formContext}.../Provider; } // 正确做法 function App() { const formContext React.useMemo(() createFormContext(), []); return Provider value{formContext}.../Provider; }5. 常见问题与排查技巧实录5.1 上下文状态不更新或更新延迟这是最常见的问题。表现是调用上下文的写方法之后消费点没有重新渲染或者渲染出来的还是旧数据。排查思路分三步。第一步确认写方法是否真的修改了状态。可以在写方法里加console.log看看调用时状态有没有变化。第二步确认消费点是否订阅了正确的上下文。如果消费点用的是useContext检查Provider的value是否变化了。第三步确认上下文的创建时机是否正确。如果上下文是在组件内部创建的每次渲染都会创建新实例消费点订阅的是旧实例自然看不到更新。我遇到过一次很隐蔽的情况写方法修改的是状态的副本而不是原始状态。比如state { ...state, name: new }这种写法如果state是用let声明的重新赋值后闭包里的state引用变了但外部通过getter拿到的还是旧引用。解决方法是把状态放在一个对象里修改对象的属性而不是重新赋值。// 有问题的写法 let state { name: }; function setName(v) { state { ...state, name: v }; // 重新赋值闭包引用变了 } // 正确的写法 const state { name: }; function setName(v) { state.name v; // 修改属性引用不变 }5.2 上下文之间的循环依赖当两个上下文互相引用时就会出现循环依赖。比如订单上下文需要读取用户上下文的信息用户上下文又需要读取订单上下文的信息。这种循环依赖会导致初始化失败或者运行时错误。解决循环依赖的方法有两种。第一种是引入第三个上下文作为中介两个上下文都依赖中介上下文而不是互相依赖。第二种是延迟依赖上下文初始化时不直接引用对方而是在方法调用时通过参数传入。// 循环依赖 const userContext createUserContext(orderContext); const orderContext createOrderContext(userContext); // 延迟依赖 const userContext createUserContext(); const orderContext createOrderContext(); // 在方法调用时传入 orderContext.getUserOrders(userContext.getUserId());我倾向于第二种方案因为它更灵活而且不会引入额外的上下文。但要注意延迟依赖意味着上下文之间的耦合关系是隐式的需要在文档里写清楚。5.3 上下文持久化数据损坏持久化数据损坏通常发生在状态结构变更之后。旧版本的数据缺少新字段或者字段类型不匹配导致反序列化后上下文行为异常。排查方法是先检查持久化数据的版本号然后对比当前状态结构的字段。如果版本号不匹配直接丢弃旧数据。如果版本号匹配但字段缺失可以在恢复时做字段补全。function restore() { const raw localStorage.getItem(cart); if (!raw) return null; try { const parsed JSON.parse(raw); if (parsed.version ! PERSIST_VERSION) return null; // 字段补全 return { items: parsed.data.items || [], totalPrice: parsed.data.totalPrice || 0, couponCode: parsed.data.couponCode || null, }; } catch (e) { // 数据损坏直接丢弃 localStorage.removeItem(cart); return null; } }提示持久化数据一定要做try-catch。我见过因为localStorage里存了非法JSON导致整个应用白屏的情况。加一层try-catch最坏情况就是丢失持久化数据不会影响应用启动。5.4 常见问题速查表问题现象可能原因排查方法解决方案状态不更新上下文实例不稳定检查创建时机用useMemo或外部创建状态更新延迟订阅了错误的上下文检查useContext参数确认Provider和Consumer配对循环依赖上下文互相引用检查初始化顺序引入中介上下文或延迟依赖持久化数据损坏版本不匹配或JSON非法检查localStorage内容加版本号和try-catch内存泄漏异步操作未取消检查异步回调加活跃标记或AbortController性能下降订阅粒度过粗检查重新渲染次数拆分Context或按需订阅6. 上下文模式在实际项目中的扩展应用6.1 多环境配置的上下文管理上下文模式不仅适用于UI状态也适用于配置管理。一个应用通常有开发、测试、生产三套环境配置每套配置的API地址、功能开关、日志级别都不同。用上下文模式来管理配置可以让配置的切换变得非常清晰。interface ConfigContext { apiBaseUrl: string; enableDebug: boolean; logLevel: debug | info | error; featureFlags: Recordstring, boolean; } function createConfigContext(env: dev | test | prod): ConfigContext { const configs { dev: { apiBaseUrl: http://localhost:3000, enableDebug: true, logLevel: debug, featureFlags: { newUI: true } }, test: { apiBaseUrl: https://test-api.example.com, enableDebug: true, logLevel: info, featureFlags: { newUI: true } }, prod: { apiBaseUrl: https://api.example.com, enableDebug: false, logLevel: error, featureFlags: { newUI: false } }, }; return configs[env]; }这种模式下切换环境只需要在应用入口传入不同的env参数所有消费点自动获取对应环境的配置。而且因为配置是只读的不需要担心被意外修改。6.2 上下文模式在AI对话系统中的应用AI对话系统是上下文模式的一个典型应用场景。一个对话系统通常需要管理对话历史上下文、用户画像上下文、工具调用上下文、系统提示词上下文。每个上下文有自己的更新规则和生命周期。对话历史上下文是追加写的每次用户或AI发言都会追加一条记录。用户画像上下文是只读的从用户数据库加载。工具调用上下文是临时的每次工具调用完成后就清理。系统提示词上下文是静态的应用启动时加载一次。用上下文模式管理这些状态可以让对话系统的逻辑非常清晰。每次生成回复时从各个上下文收集需要的信息组装成提示词调用模型然后把结果写回对话历史上下文。整个过程不需要全局状态也不需要到处传参。6.3 上下文模式的测试策略上下文模式的一个巨大优势是可测试性。因为每个上下文是独立的可以单独测试不需要启动整个应用。测试上下文时我通常关注三个方面状态变更是否正确、边界条件是否处理、异步操作是否可靠。describe(CartContext, () { it(添加商品后总价正确, () { const cart createCartContext(); cart.addItem({ id: 1, name: 商品A, price: 100, quantity: 1 }); expect(cart.getTotalPrice()).toBe(100); }); it(移除商品后总价正确, () { const cart createCartContext(); cart.addItem({ id: 1, name: 商品A, price: 100, quantity: 1 }); cart.addItem({ id: 2, name: 商品B, price: 200, quantity: 1 }); cart.removeItem(1); expect(cart.getTotalPrice()).toBe(200); }); it(优惠券无效时不改变总价, async () { const cart createCartContext(); cart.addItem({ id: 1, name: 商品A, price: 100, quantity: 1 }); const result await cart.applyCoupon(INVALID); expect(result).toBe(false); expect(cart.getTotalPrice()).toBe(100); }); });这种测试写起来很直接跑起来也很快因为不依赖任何UI框架。我通常会把上下文的测试覆盖率要求设到90%以上因为上下文是业务逻辑的核心这里出问题影响面最大。6.4 上下文模式的迁移策略如果你已经有一个用全局状态管理的项目想迁移到上下文模式我建议采用渐进式迁移而不是一次性重写。第一步识别出项目中耦合最严重的状态模块通常是那些被最多组件读写、修改最频繁的状态。第二步把这个模块拆成一个独立的上下文保留原有的全局状态作为兼容层新代码用上下文老代码继续用全局状态。第三步逐步把老代码迁移到上下文每迁移一个消费点就测试一次。第四步当所有消费点都迁移完成后删除全局状态。这个过程中兼容层是关键。兼容层的作用是让上下文和全局状态可以互相读写保证迁移期间数据一致。具体实现可以是在上下文的写方法里同步更新全局状态在全局状态的订阅里同步更新上下文。function createCartContextWithCompat(globalStore) { const cart createCartContext(globalStore.getState().cartItems); // 上下文写操作同步到全局状态 const originalAddItem cart.addItem; cart.addItem (item) { originalAddItem(item); globalStore.dispatch({ type: cart/add, payload: item }); }; // 全局状态变化同步到上下文 globalStore.subscribe(() { const globalItems globalStore.getState().cartItems; if (JSON.stringify(globalItems) ! JSON.stringify(cart.getItems())) { cart.reset(); globalItems.forEach(item cart.addItem(item)); } }); return cart; }这种兼容层会增加一些复杂度但它让迁移过程变得可控。你可以一个模块一个模块地迁移每次迁移后都能正常运行和测试不会出现迁移到一半系统跑不起来的情况。注意兼容层是临时方案迁移完成后一定要删除。长期保留兼容层会导致双向同步的逻辑越来越复杂最终变成新的技术债务。7. 我个人的一些实操体会上下文模式这个东西刚接触的时候会觉得多此一举。明明一个全局store就能搞定的事情为什么要拆成这么多上下文还要写这么多样板代码。但当你维护过一个超过十万行代码、状态耦合严重、改一处崩三处的项目之后你就会明白边界清晰有多重要。我现在的习惯是新项目启动时先不急着写状态管理代码而是先画一张状态关系图。把所有的状态列出来标注它们之间的依赖关系然后按照使用场景分组。每一组就是一个上下文。这个过程通常只需要半个小时但它能避免后面几个月的重构痛苦。还有一个体会是上下文模式的价值不在于代码本身而在于它强迫你思考状态的边界。当你定义上下文的时候你不得不回答这些问题这个状态属于谁谁可以读谁可以写什么时候失效这些问题在全局状态模式下是很容易被忽略的但在上下文模式下是必须回答的。最后分享一个小技巧。如果你不确定一个状态应该放在哪个上下文里就问自己一个问题这个状态变化时哪些UI需要更新如果答案是一组固定的、经常一起变化的UI那它们就应该属于同一个上下文。如果答案是一组不相关的UI那这个状态可能被放错了地方应该拆到更细的上下文里。这个判断标准我在多个项目中验证过准确率很高。它背后的逻辑是上下文的边界应该和UI的更新边界对齐。这样既能保证状态变化的传播范围最小又能保证相关UI的同步更新。