context-mode这个词最近在我这边出现频率很高。团队里聊状态管理方案时有人把它理解成 React 的 Context API 用法模式也有人拿它指代 AI 编程工具里的上下文选择模式。我的看法是无论从哪个角度切入核心都落在同一个词上——上下文。变量为什么要一路传到组件树深处逻辑为什么在看似无关的组件里反复失效本质上都是上下文没管好。这篇文章我打算把 context-mode 当成一条完整的主线从 React 项目里的状态管理实战讲起最后延伸到编辑器与 AI 辅助编程里的上下文感知实践尽量把这条上下文驱动的路径讲透。文章的读者画像很明确如果你受够了 prop drilling正在 Redux 和 Context 之间摇摆或者你刚开始接触前端架构想知道为什么别急着上重型状态库——这篇都适合你。我会把原理、选型、完整代码、踩坑记录全部摊开尽量给你一份可以直接照抄的作业。1. 先搞清楚 context-mode 到底解决什么问题1.1 prop drilling 之痛一个真实改需求场景我接手过一个后台管理系统页面层级大概是这样的Layout里有SidebarSidebar里有MenuListMenuList里是若干MenuItem点开MenuItem又会弹DetailPanel。某天产品提了个需求用户登录后所有菜单要根据角色权限动态显隐。按当时代码里最顺手的写法你得把 user 对象从顶层一路往下传。Layout要传Sidebar要传MenuList要传MenuItem还要传。更难受的是路由跳转后DetailPanel也要用角色信息决定按钮是否可见传参的路径又多了一条。这就引出了 prop drilling 的两个核心痛点第一中间层组件被强行改造成中转站它们自己根本不需要 user却因为子组件需要而被迫接收并转发第二重构成本极高一旦在中间层加了一个shouldDisplay的判断所有涉及的组件签名都要跟着改。实际开发里这种需求改三次代码体积能膨胀一圈。1.2 context-mode 的本质把共享状态提到上层Context 模式的思路其实特别朴素与其把水桶从水站一层层拎到每户门口不如直接建一条供水管道任何一层的住户打开水龙头就能接到水。在 React 的世界里createContext就是那条管道Provider是水站useContext是各家各户的水龙头。用回刚才的场景改造后的做法是在应用根部挂一个AuthProvider把user放进去。MenuList要判断权限直接useAuth()读一下DetailPanel要控制按钮也useAuth()。中间层的Sidebar彻底解脱连 props 都不用声明。但这里有个关键认知Context 模式不是状态管理库而是 React 自身提供的状态共享机制。它解决的只是状态如何跨层级传递的问题至于状态怎么产生、怎么变更、怎么持久化React 不管你要自己设计。换句话说它是状态管理的地基不是房子本身。很多开发者把 Context 和 Redux 对立起来比较其实是搞错了维度——Redux 是状态盒子分发规则Context 是传输管道两者可以互相替代也可以协作共存。2. context-mode 的设计与选型不是所有状态都该进 Context2.1 三个判断标准何时用 Context何时绕开接手过几个老项目后我总结出三个判断标准问完这三个问题基本就能决定一个状态该不该进 Context。第一个问题这个状态是否被多个层级的多个组件共享如果它只在一个组件内部使用useState就够了如果它只被一个组件和它最近的父组件使用局部状态或者少量 props 更轻。只有当状态被隔代共享或者兄弟组件共享时Context 才真正划算。第二个问题状态更新的频率高不高Context 有一个天生的特性某个组件通过useContext订阅了 Context 值那么当 Provider 的value变化时该组件一定会重新渲染无法单独跳过。如果某个极端场景比如收银台页面的光标位置或滑块拖拽值每秒更新几十次且大量组件订阅了同一个 Context性能就会出问题。这种高频状态更适合留在组件内部或者用useSyncExternalStore、外部状态库做细粒度订阅。第三个问题状态的生命周期和组件树是否一致Context 的特点是Provider 在组件树上则状态在组件树下天然可见。但如果你的状态要跨页面、跨路由甚至跨窗口保持比如登录态那还要配合持久化方案不能只靠 Context 本身。2.2 状态类型速查表适合进 Context 的状态不适合进 Context 的状态登录用户信息与权限骨架高频变化的表单输入值UI 主题暗色/亮色动画运行中的瞬时数值当前语言与多语言配置弹窗拖拽的实时坐标购物车条数与商品集合每帧变化的渲染数据布局面板的展开收起状态只被组件自身使用的内部数据这张表不是绝对真理但它可以帮你快速判断。我个人的经验是把不焦虑、低频、跨层共享的状态放进 Context把焦虑、高频、局部存在的状态留在原地。这个判断框架比任何库选型都重要。2.3 组织模式对比单 Context、多 Context 与 useReducer 组合很多新手在设计 Context 模式时习惯把整个应用的状态塞进一个巨型 Context。比如const AppContext createContext({ user: null, theme: light, cart: [], notifications: [], language: zh, // ... 更多 });这种做法非常不推荐原因很直接只要cart更新所有通过useApp()读取状态的组件都会整体重新渲染哪怕它们只用到了theme。这会带来严重的性能浪费也是Context 性能不好这个说法的根源。我建议的组织方式有三个层次从轻到重依次是单 Context适合状态较少、小型组件树比如一个弹窗系统的内部状态。多 Context 拆分按业务领域拆成AuthContext、ThemeContext、CartContext做到谁订阅谁负责谁变更谁影响。Context useReducer 组合把变更逻辑从组件中抽离出来通过dispatch触发 action让状态流可追踪。三者不是互斥的。小型项目从单 Context 起步没问题但随着状态增多尽早拆分才是最省心的路径。下面一节我会重点演示最实用的多 Context useReducer组合。3. 一步步搭建 context-mode 状态层3.1 设计状态模型与 Action我拿一个典型的电商业务状态举例子。假设我们要管理购物车和用户登录信息状态结构先规划好// state.js export const initialAuthState { user: null, status: anonymous, // anonymous | authenticated | loading token: null, }; export const initialCartState { items: [], totalAmount: 0, updatedAt: null, };Action 的设计参考了 reducer 的写法好处是变更逻辑集中管理组件里只负责发指令// authReducer.js export function authReducer(state, action) { switch (action.type) { case LOGIN: return { user: action.payload.user, token: action.payload.token, status: authenticated, }; case LOGOUT: return { user: null, token: null, status: anonymous }; case SET_LOADING: return { ...state, status: loading }; default: throw new Error(Unknown action type: ${action.type}); } }这里有一个重要的设计原则Action 设计要跟着业务走而不是跟着组件走。很多新手会设计成SET_USER、UPDATE_USER_NAME、CLEAR_USER一堆细碎的动作类型其实可以合并成LOGIN、LOGOUT、UPDATE_PROFILE这几个业务语义更强的动作。业务语义的 action 让 reducer 更容易理解未来加逻辑比如登录时写入埋点也只需要改 reducer 一个地方。3.2 创建 Context 与 Provider接下来创建 Context。默认值传null并不可耻反而是一种保护// authContext.js import { createContext, useContext, useMemo, useReducer } from react; import { authReducer, initialAuthState } from ./authReducer; const AuthContext createContext(null); export function AuthProvider({ children }) { const [state, dispatch] useReducer(authReducer, initialAuthState); const value useMemo(() ({ state, dispatch }), [state]); return ( AuthContext.Provider value{value} {children} /AuthContext.Provider ); }注意到useMemo了吗这一步是 Context 性能的第一道防线。如果没有useMemo每次AuthProvider自身因为任何原因重新渲染value都是一个新对象所有订阅AuthContext的子组件都会无条件重新渲染。加上useMemo后只有state真正变化时value才会变化。同样的思路做一个CartContext// cartContext.js import { createContext, useContext, useMemo, useReducer } from react; import { cartReducer, initialCartState } from ./cartReducer; const CartContext createContext(null); export function CartProvider({ children }) { const [state, dispatch] useReducer(cartReducer, initialCartState); const addItem (item) dispatch({ type: ADD_ITEM, payload: item }); const removeItem (id) dispatch({ type: REMOVE_ITEM, payload: id }); const clearCart () dispatch({ type: CLEAR_CART }); const value useMemo(() ({ state, addItem, removeItem, clearCart }), [state]); // 更严谨的写法是再加 useCallback 包裹 addItem 等函数 // 这里 useMemo 已经保证 value 在 state 不变时不变已足够 return ( CartContext.Provider value{value} {children} /CartContext.Provider ); }然后把几个 Provider 在应用根部合并// AppProviders.js export function AppProviders({ children }) { return ( AuthProvider CartProvider ThemeProvider{children}/ThemeProvider /CartProvider /AuthProvider ); }这种合并方式比把多个 Provider 写在同一个组件里清爽得多。但还是要提醒Provider 嵌套层级越深组件树初始化时涉及的操作越多所以不要把不相关的大块 Provider 全部聚合到最顶层。我的原则是应用全局的放根部页面局部的放到对应页面的入口组件里。3.3 用自定义 Hook 收紧访问边界这是很多入门教程会忽略但生产级别项目里非常重要的一步。直接导出 Context然后让业务组件useContext(AuthContext)虽然能用但容易出两个问题第一组件里忘了判断 Context 是否为 null导致运行时崩溃难以定位第二Context 的 key 字符串散落在组件中后续改名时全工程要跟着改。推荐的写法是导出一个自定义 Hookexport function useAuth() { const context useContext(AuthContext); if (!context) { throw new Error(useAuth 必须在 AuthProvider 内部使用); } return context; } export function useCart() { const context useContext(CartContext); if (!context) { throw new Error(useCart 必须在 CartProvider 内部使用); } return context; }你还可以进一步拆出选择器 Hookexport function useAuthUser() { const { state } useAuth(); return state.user; } export function useCartItems() { const { state } useCart(); return state.items; }选择器 Hook 的好处是业务组件可以按需取用自己关心的片段后续你在内部优化订阅粒度时业务组件完全不用改。这层封装其实是给未来的自己留了一条优化通道。3.4 性能防线五条硬规矩Context 性能问题永远是讨论焦点。我根据实际项目总结出五条规矩建议直接写进团队规范value永远用useMemo/useCallback包裹不许裸奔。我在代码评审里见过太多次value 是个对象导致全树重渲染的情况。宁可拆 Context不要做巨型 Context。状态超过三四个领域直接分家。比如AuthContext、ThemeContext、CartContext各管一摊。高频更新的状态不进 Context。如果你确实有高频状态且必须跨组件考虑useSyncExternalStore或交给 Zustand 这类外部状态库做精细订阅。订阅方尽量用选择器 Hook。哪怕刚开始只是返回state.user而非整个 state也为你后续的订阅拆分留好了口子。结合React.memo阻挡中间层的无意义渲染。即使子组件用了useAuth它的父组件如果被React.memo包住且父组件自身的 props 没变那么父组件不会重新渲染这也能隔离相当一部分连锁更新。4. 实战实录context-mode 在项目里的落地4.1 一次重构从状态散落到上下文收敛我参与过一个后台权限梳理的项目最初代码长成这样Layout里通过useState管理用户信息路由跳转时把 user 存到 sessionStorage然后在每个需要用权限的页面里再手动读一次。代码能跑但问题很碎页面刷新后状态恢复要靠人为调用存储读取菜单显示逻辑和页面按钮权限逻辑各自独立判断经常出现菜单显示能进但页面按钮点了报错的权限不一致。我们团队用 context-mode 做了收敛应用根部挂AuthProvider初始化时从 sessionStorage 恢复 userdispatch的LOGIN和LOGOUT动作里同时处理存储写入和清理。重构之后权限判断统一走useAuth菜单和按钮使用的是同一份状态源那种一个地方显示、一个地方不显示的诡异 bug 直接消失了。这里我特别推荐把持久化和Context 状态绑定在同一个 reducer 流程里而不是在组件里到处写sessionStorage.getItem。比如这样export function authReducer(state, action) { switch (action.type) { case LOGIN: { const next { user: action.payload.user, token: action.payload.token, status: authenticated, }; sessionStorage.setItem(auth, JSON.stringify(next)); return next; } case LOGOUT: { sessionStorage.removeItem(auth); return { user: null, token: null, status: anonymous }; } default: return state; } }这样持久化逻辑和状态变更逻辑放在了同一处后续排查为什么刷新后登录态丢了的时候你只需要打开 reducer 就能看到全部不用在组件树里大海捞针。4.2 与服务端状态协同别把服务器数据塞进 Context新手容易犯的另一个错误是把所有请求返回的数据都放进 Context让 Context 变成缓存层。我曾经看到过一个项目OrderContext里存放了十几个订单相关的请求结果每次接口返回后 dispatch 更新结果组件订阅面巨大接口只要刷新一个字段整个订单区全部重新渲染。更合理的做法是服务端状态交给专门的请求缓存库比如 React Query、SWR客户端本地状态交给 Context。原因很简单服务端缓存关注的不是状态如何分发而是请求状态是 loading 还是 success、什么时候失效重发它自带生命周期与 Context 的职责完全不同。如果项目里不方便引入新的库我的建议是Context 里只放业务派生状态例如判断当前用户是否有编辑权限、购物车总金额而不是把从接口拿到的原始列表对象整体塞进去。等你有条件引入缓存库时迁移成本会小很多。4.3 我踩过的四个坑建议逐条避雷坑一Context 默认值用了{}而不是null。新手写createContext({})看起来安全但当你调用useContext做解构时如果 Provider 忘记挂载你会得到undefined而报错。给null并在自定义 Hook 里抛出明确错误反而是更早暴露问题的方式。坑二Provider 挂在路由内部导致状态丢失。我曾见过把AuthProvider放在某个页面组件内部结果路由切换后 Provider 卸载登录态直接丢失。全局的 Provider 应该放在 Router 之外或者在AppProviders的最外层。判断标准很简单你期望这个状态在页面切换后依然保留Provider 就绝不能呆在页面层级。坑三useMemo依赖数组写错。如果你在value里同时返回state和dispatchuseMemo的依赖只写了[state]而忽略了dispatch其实没问题——因为dispatch是useReducer返回的稳定引用。但如果你在value里放了自定义函数比如上面 Cart 例子的addItem依赖数组就必须包含它否则闭包里捕获的永远是旧值。坑四多个 Context 嵌套导致组件树臃肿。这个问题在高阶组件里尤其明显。当 Provider 嵌套超过五层时代码读起来非常痛苦。我的解决方案是写一个AppProviders合并组件配合子组件 props 不传递的状态共享整体树深可以被有效控制。5. 常见问题与排查技巧实录很多读者在实操中遇到的问题其实高度相似我把一些高频问题按症状—原因—解法整理成速查表方便你直接对号入座。症状原因解法所有子组件都在疯狂重渲染value对象没做useMemo用useMemo包裹 value确保引用稳定切到另一个路由后状态丢了Provider 放在了路由组件内部把 Provider 提升到路由之上或应用根部自定义 Hook 报错必须在 Provider 内部使用某个组件在 Provider 外层使用 Hook检查组件树挂载顺序或在 Hook 内补一个临时兜底值状态能读但不能改组件里拿到的是 Context 的默认值而非 Provider 的 value检查是否忘记挂载对应 Provider明明 dispatch 了界面不更新reducer 返回了和当前 state 相同的引用确保 reducer 返回新对象不要原地修改 state排查这类问题时我习惯先在浏览器 React DevTools 里看右侧的 Provider 树。如果某个组件显示的 Context 值和你预期不一致大概率是 Provider 层级不对。这个手段比单步调试快得多。再进一步如果你发现重渲染来自useContext本身但已经用了useMemo关键要看这个 Context 是宽而浅还是窄而深。宽而浅的 Context比如存了一堆分散字段容易引起全局刷新窄而深的 Context比如只存登录态影响面反而可控。如果遇到宽而浅的 Context最佳方案是拆成多份而不是继续优化单份的useMemo。6. 延伸context-mode 在编辑器与 AI 辅助编程里的实践6.1 编辑器里的上下文感知操作context-mode这个词在编辑器领域还有另一层含义指的是让你在操作时能感知当前所在环境的上下文。例如在代码编辑中你要选中一段带引号字符串的内容、选中一个 HTML 标签内的整个块普通手动选择很容易选错边界。而上下文感知的编辑工具会先识别当前语法单元是字符串、函数体还是 JSX 片段再执行操作。这种思路和 React Context 有异曲同工之处不只关心我要对哪个字符做操作而是关心我当前处于什么环境、这个环境下哪些操作合法。我在日常编码里处理大括号内嵌套逻辑移动时依赖编辑器自带的括号匹配与选中能力这种基于上下文的选择与操作确实能大幅减少误操作。6.2 AI 辅助开发里的上下文管理最近一两年 AI 编程助手越来越普及你会发现它和你聊天的内容其实就是一种上下文管理。让 AI 知道你现在打开了哪个文件、引用了哪段代码、项目整体结构什么样决定了它生成代码的准确度。很多工具里通过唤起文件引用、通过代码选择区作为生成基准这些都是在构造上下文。我的经验是把 AI 当新加入项目的同事上下文给的越明确产出质量越高。这里说的上下文包括几类问题描述的背景做什么功能、为何要这么做、当前代码的关键约束不能用哪些依赖、接口定义长什么样、期望的输出范围只改这个文件还是涉及多个文件。你在 prompt 里的上下文质量直接决定了建议的可用性。6.3 从组件状态到上下文思维把 React 的 context-mode、编辑器的上下文感知操作、AI 编程的上下文管理放在一起看会得到一个通用启示复杂系统的可用性往往取决于信息分发是否高效。组件需要状态时不要跨层硬塞而是从它所在的环境里取编辑器要操作字符时先判断所在语法环境AI 要生成代码时先喂给它足够的项目背景。它们在避免传递噪声、按需获取信息这个维度上是完全一致的。这也是我为什么坚持在项目里用 context-mode 而不是简单粗暴地集中管理所有状态它天然促使你把谁来消费信息和信息如何变化分开思考。当你习惯了这种思维模式去设计组件 API、接口协议甚至团队协作流程时都会顺手很多。我个人在多次重构后最大的体会是context-mode 真正的价值并不是节省几行 props 传递代码而是让状态的所有权边界变得清晰可辨。哪些状态属于用户会话哪些属于主题偏好哪些属于临时 UI 状态它们各自被谁消费、被谁变更一张 Context 清单就能看明白。如果你正在一个功能模块飞速膨胀的 React 项目里挣扎不如先停下来用这篇文章里说的三个判断标准重新梳理一遍状态清单把该拆的 Context 拆掉该合并的 reducer 合并好。这一步做完你会发现组件树清爽得像刚理完线的工位。最后再分享一个小技巧每次新建 context 文件时我习惯顺手把文件职责 消费方提示 变更动作列表写进文件头的注释里。一开始只是图方便后来发现这相当于给状态层写了一份微型 README新同事接手时根本不用追着问你这个 context 到底是干嘛的。如果你也想把 context-mode 落地到团队里这可能是成本最低、收益肉眼可见的第一件事。