写 React 写了六七年，我几乎每个项目都会跟context-mode打交道。它可能是你接触到的第一个"官方提供的全局状态管理方案"，也可能是你刚开始觉得挺好用、后来被各种 re-render 问题折磨到怀疑人生的那个东西。这篇不是教材，是我自己项目里踩过的坑、用出来的经验，还有一套从入门到优化到选型的完整路线。不管你是刚学会useState的新手，还是已经在用 Redux、Zustand 的老手，只要你需要跨组件共享状态，context-mode 就值得你把它彻底吃透。
1. context-mode 到底解决什么问题
1.1 从 prop drilling 说起：状态传递的原始痛点
先说一个特别常见的场景。App 组件从后端拿到了用户信息user，页面顶部的 Header 要显示用户头像，而 Header 里面还套了一层 UserMenu，UserMenu 里再用 Avatar 展示头像。如果你的直觉是把user从 App 一层层传到 Header、再传到 UserMenu、最后传到 Avatar，那恭喜你，你已经体会过 prop drilling 的滋味了。
这玩意儿有多难受？我举个真实例子：之前做个中后台系统，用户信息至少要经过四层组件才能到达头像组件，中间还有两个容器组件完全不需要用到user，纯粹是"帮忙传话"。后来权限模块、主题模块、语言模块全都要向下传，一个组件 props 动辄十几二十个，看得头皮发麻。每次新加一个状态，就要沿着组件树一路往下加参数，你要是中途漏了一层，改错一个名字，TypeScript 还会在十几个文件里一起报错。这不只是麻烦，是严重影响开发效率。
prop drilling 的核心矛盾是：状态归属的层级和消费它的层级，往往相隔很远。React 官方的数据流是单向的，props 只能从父到子，这个设计本身是保证可预测性的好东西，但它没有解决"跨越中间层通信"的问题。于是官方给出了 context-mode 这个方案——让状态从组件树的上层直接"穿透"到任意深度的下层，中间层不需要感知这个状态的存在。
1.2 Context Mode 的核心机制：Provider 和 Consumer
context-mode 的实现机制其实不复杂。你可以把它理解成组件树里的一条"隐形电梯"：某个组件在上层"投放"一份数据，数据存到了电梯里，凡是注册了"我要坐电梯"的下层组件，都能直接从电梯里拿到这份数据，不需要经过中间层手动转交。
React 用createContext创建这个"电梯通道"，它返回一个对象，里面有两个关键件：Provider和Consumer。Provider是投放数据的一端，必须包裹在组件树的上层；Consumer是取数据的一端，可以在任意深度消费数据。函数组件里我们一般用useContext这个 hook 来消费，比写Consumer简洁直观得多。
有意思的是，Context的穿透力不是全局的，它只作用于Provider包裹的那棵子树。同一个 Context 可以在不同层级挂不同的Provider，越靠近消费者的Provider优先级越高。这个设计特别重要，因为很多人刚上手时容易把 Context 当"全局变量"用，忽略它的作用域其实是限定的。
1.3 为什么不用全局事件总线替代 context-mode
你可能想问：很多项目以前用全局事件总线（比如 EventEmitter）或者直接把对象挂到window上，也能实现跨组件通信，为什么非得用 context-mode？
区别在于可追踪性和响应式更新。全局变量是脱离 React 渲染体系的：你在window.user = xxx改了数据，组件不会自动重新渲染，你还得手动去触发事件、去订阅、去清理，搞着搞着就是一堆内存泄漏和状态同步问题。而 context-mode 是 React 内部机制，Provider的 value 一旦变化，所有消费它的组件会自动进入更新队列，触发 re-render。你不用自己管通知、不用管订阅生命周期，它天然就跟 React 渲染周期对齐。
所以结论很简单：如果只是想"跨组件拿一个值"，全局变量也能做，但你要同步 UI、要响应更新、要保证状态流转可追踪，那 context-mode 是官方给出的最低成本方案。这也是我推荐大多数项目直接用它管"低频、跨层级"状态的根本原因。
2. 核心细节解析与实操要点
2.1 createContext 的正确姿势：默认值怎么给才不踩坑
写createContext时第一个坑就是怎么给默认值。很多教材会告诉你"为默认值提供一个对象，这样没有 Provider 时也能用"，但我实测下来，这个建议需要打折扣。
如果你给的是一个"假的、空的"默认值，比如createContext({ user: null, login: () => {} })，你确实避免了useContext返回undefined的问题，但这个默认值会掩盖一种的真实错误：你忘记用 Provider 包裹组件树，或者 Provider 挂错了层级。当useContext拿到的是默认值而不是你传给 Provider 的值时，程序通常不会崩，但表现会非常诡异——比如页面一直显示未登录、主题永远是浅色、按钮点击没反应。这种 bug 特别难查，因为它没报错，只是数据不对。
我现在的习惯是：默认值传null，然后在自定义 hook 里做空值兜底。比如定义AuthContext = createContext<AuthContextType | null>(null)，消费端统一走useAuth()这个 hook，里面先useContext(AuthContext)，如果结果是null就抛错。这样一旦有人忘了包 Provider，页面直接红屏报错，你一眼就能定位问题，而不是花两小时查"为什么用户信息读不到"。
2.2 Provider 的 value 别写对象字面量
这是 context-mode 性能问题的最经典来源，我刚从坑里爬出来时恨不得把这句话打印贴在显示器上：<Provider value={{ ... }}>这种写法，每次父组件 re-render 都会创建一个全新的对象引用，哪怕里面的值一模一样，所有消费者也会跟着重渲染。
原因很简单，React 判断 Context 是否变化用的是Object.is比较 value 的引用地址，而不是深比较内容。{ theme: 'light' }这个对象字面量，每次渲染都是新地址，那 React 就会认为"值变了"，于是让所有useContext消费者重新 render。如果消费者是大列表、复杂表单，你会在输入框敲一个字就感觉整个页面在抖。
正确的姿势是：把 value 用useMemo缓存起来，依赖项写清楚。比如：
const value = useMemo( () => ({ user, login, logout }), [user] ); return <UserContext.Provider value={value}>{children}</UserContext.Provider>;这样只有当user真的变化时 value 才会生成新引用，才不会"连带伤害"所有消费者。
2.3 拆 Context，而不是攒一个大而全的 Store
还有一个原则我踩过两次坑才真正执行：context 要拆，而且拆得越细越稳。我见过有人把一个应用的几十个状态塞进一个巨型 Context，命名为GlobalStoreContext，感觉跟把整个房间的杂物都塞进一个行李箱一样，表面上很整齐，实际上每次任何一个小状态变化，整棵子树全部重渲染，性能直接失控。
我的推荐拆法：按领域拆，按读写频次拆。比如用户信息一个 Context，主题一个 Context，消息通知一个 Context，互不掺和。更进一步，如果这个领域里"状态数据"和"更新函数"的消费频率不同，我还会把数据和 setter 拆成两个 Context，一个管读、一个管写。这样做的好处是组件按需消费，避免"我只想拿用户头像，结果整个用户模块的更新函数变化把我拖着一起重渲染"。
另外要区分一下：context 适合的是低频、跨层级、相对稳定的状态。高频变化的（比如输入框实时内容、列表筛选结果）如果放在 context 里，性能压力会非常大，这类数据更适合用useState控制在局部，或者用Zustand配合订阅机制解决。把 context 当作"所有全局状态的家"，是架构上最大的误会。
3. 实操过程与核心环节实现
3.1 从零实现一个 AuthContext：登录态贯穿全应用
我挑了最典型、最实用的一个场景——登录态管理，来完整演示 context-mode 的落地流程。你写任何一个需要登录的系统，这套东西基本就是骨架。
先定义类型和 Context，我用 TypeScript 的习惯：
type User = { id: string; name: string; avatar: string; }; type AuthContextType = { user: User | null; loading: boolean; login: (token: string) => Promise<void>; logout: () => void; }; const AuthContext = createContext<AuthContextType | null>(null);然后写 Provider 组件，它负责管理用户状态、从本地缓存恢复登录态、暴露 login/logout 方法：
function AuthProvider({ children }: { children: React.ReactNode }) { const [user, setUser] = useState<User | null>(null); const [loading, setLoading] = useState(true); useEffect(() => { const token = localStorage.getItem('token'); if (!token) { setLoading(false); return; } // 用 token 调接口换取用户信息 fetchUserByToken(token) .then((res) => setUser(res.user)) .catch(() => localStorage.removeItem('token')) .finally(() => setLoading(false)); }, []); const login = useCallback(async (token: string) => { localStorage.setItem('token', token); const res = await fetchUserByToken(token); setUser(res.user); }, []); const logout = useCallback(() => { localStorage.removeItem('token'); setUser(null); }, []); const value = useMemo( () => ({ user, loading, login, logout }), [user, loading, login, logout] ); return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>; }注意看这里几个关键点：login和logout都用useCallback包住，保证函数引用在依赖不变时稳定；value用useMemo聚合，只有user、loading、login、logout任一变化时才生成新对象。这就是上面说的防 re-render 的核心套路，必须形成肌肉记忆。
然后消费端封装一个 hook，避免每次useContext(AuthContext)还要处理 null：
function useAuth() { const ctx = useContext(AuthContext); if (!ctx) throw new Error('useAuth 必须在 AuthProvider 内部使用'); return ctx; }useAuth用起来就非常舒服了：按钮里const { login, loading } = useAuth()，头像组件里const { user } = useAuth()，谁需要用谁就用，中间组件完全不需要关心。这套 auth 体系在我的项目里从上线到现在都非常稳。
3.2 主题切换实战：动态 Context 与 CSS 变量联动
第二个场景，我用它来说明"context 里装的值也可以是动态策略"。主题切换这个需求，核心是让所有组件感知当前主题、并能响应切换动作。
我通常的做法是：主题 Context 管theme值和toggleTheme函数，Provider 内部再通过 useEffect 把主题对应的 CSS 变量挂到document.documentElement上。这样组件不需要各自去读 context，也能自动跟随主题变化——因为它们的样式里用的是 CSS 变量。
type Theme = 'light' | 'dark'; const ThemeContext = createContext<{ theme: Theme; toggleTheme: () => void; } | null>(null); function ThemeProvider({ children }: { children: React.ReactNode }) { const [theme, setTheme] = useState<Theme>(() => { return localStorage.getItem('theme') === 'dark' ? 'dark' : 'light'; }); const toggleTheme = useCallback(() => { setTheme((prev) => (prev === 'light' ? 'dark' : 'light')); }, []); useEffect(() => { document.documentElement.dataset.theme = theme; localStorage.setItem('theme', theme); }, [theme]); const value = useMemo(() => ({ theme, toggleTheme }), [theme, toggleTheme]); return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>; }在这里，document.documentElement.dataset.theme是给全局根节点打标记，配合 CSS 里[data-theme='dark']选择器去覆盖变量，整个切换过程组件不会因为 context 变化全部重渲染，只改了根节点的属性、触发 CSS 重新计算。这是一个"context 管数据 + CSS 变量管样式"的组合方案，性能非常好。
3.3 用 useReducer + Context 替代大部分 Redux 场景
说到这，很多项目在状态复杂之后会考虑上 Redux，但实际上 context-mode +useReducer的组合就可以覆盖相当大一部分需求。我来演示一个购物车的例子，这个能直观看到 context 如何与 reducer 协作。
先写 reducer：
type CartItem = { id: number; name: string; price: number; qty: number }; type CartState = { items: CartItem[] }; type CartAction = | { type: 'ADD_ITEM'; item: CartItem } | { type: 'REMOVE_ITEM'; id: number } | { type: 'CLEAR' }; function cartReducer(state: CartState, action: CartAction): CartState { switch (action.type) { case 'ADD_ITEM': const existing = state.items.find((i) => i.id === action.item.id); if (existing) { return { items: state.items.map((i) => i.id === action.item.id ? { ...i, qty: i.qty + 1 } : i ), }; } return { items: [...state.items, { ...action.item, qty: 1 }] }; case 'REMOVE_ITEM': return { items: state.items.filter((i) => i.id !== action.id) }; case 'CLEAR': return { items: [] }; default: return state; } }然后 Provider 里useReducer(cartReducer, { items: [] })，把state和dispatch封装进 context：
const CartContext = createContext<{ state: CartState; dispatch: React.Dispatch<CartAction>; } | null>(null); function CartProvider({ children }: { children: React.ReactNode }) { const [state, dispatch] = useReducer(cartReducer, { items: [] }); const value = useMemo(() => ({ state, dispatch }), [state]); return <CartContext.Provider value={value}>{children}</CartContext.Provider>; }消费端，购物车列表组件只拿state.items，加购按钮组件只拿dispatch。所有状态更新逻辑集中在 reducer 的纯函数里，可测试性好，又能通过 context 跨组件共享。对于中小型应用，这一套比我用过的大多数组件库内置状态管理方案都要清晰，而且没有额外依赖。
4. 常见问题与排查技巧实录
4.1 "整个页面卡死了"：Context 更新导致大面积重渲染
前端性能排查里，context 导致的重复渲染是我见过的高频问题。现象是：某个小组件里改了一个状态，整屏组件跟着闪，尤其在有表单、有弹窗的页面上特别明显。
定位思路是这样：先确定触发点，打开 React DevTools 的 Profiler 记录交互，看是哪些组件在 re-render。如果发现一个大圈子里的组件全部高亮，基本就是 Context 的 value 变了。对照代码检查是否用了useMemo包 value；检查useContext调用的组件是否真的需要关心整个 value 对象；检查Provider是否包在了过大的组件树上。
我一般会按三个层次修：第一层，确保 value 用useMemo，消费端的钩子函数用useCallback；第二层，拆分 Context，让一个组件只订阅它关心的那一小块数据；第三层，如果状态确实是高频变化的，那就别硬扛 context 了，考虑用zustand这类带细粒度订阅的库，或者把状态往下移到真正使用它的地方。
4.2 "useContext 拿到 undefined、组件直接抛错"
这个错误长得很吓人，但原因通常就两类。第一类：忘了包 Provider。或者 Provider 包裹的层级不对，组件不在 Provider 的子树范围内。第二类：同一个 Context 对象被定义了两次，比如模块被重复打包、或者你在组件文件里又创建了一个新 Context，导致 Provider 和 useContext 用的不是同一个对象。
排查时，先把createContext放到单独的文件里统一 export，防止不同文件引用了不同实例。然后在抛错前打印一下ctx === null，确认 Provider 是否真的包裹住了当前组件。再加一个规则：自定义 hook 里做兜底抛错，就是这个模式能让你在开发期尽早发现问题。
4.3 "值没更新"：Provider 嵌套顺序错乱
Context 的 Provider 是可以嵌套的，子级 Provider 的值会覆盖父级。这在做"局部覆盖"时很好用，但如果嵌套顺序没理清，就会出现"为什么我明明传了中文语言包，页面还是英文"这种疑惑。
记住一个核心原则：距消费者更近的 Provider 优先。如果你想让某个区域局部覆盖主题，就把这个区域的 Provider 放在想要的子树根部。调试这种问题时，在 React DevTools 的组件树里直接看 Provider 的层级关系，一目了然，比瞎猜快得多。
4.4 测试 context 时容易踩的暗坑
测试带 Context 的组件，最干净的姿势是用renderHook配一个自定义 wrapper。套路是这样的：
function wrapper({ children }: { children: React.ReactNode }) { return <AuthProvider>{children}</AuthProvider>; } const { result } = renderHook(() => useAuth(), { wrapper });这里最大的坑是：如果把 Provider 直接写在测试用例的 render 里，而 context 里面有异步逻辑（比如登录态恢复），你需要额外处理异步等待。我习惯在测试里 mock 掉 Provider 内部调用的接口，然后用waitFor等待状态稳定后，再断言result.current.user的值。
另外提醒一下，如果你测试的组件里useAuth()在 Production 模式下会正常兜底，但测试环境没包 Provider，会直接抛错。别慌，这不是组件 bug，是测试环境缺了 wrapper——补上就行。这也是我把useAuth兜底抛错做成默认习惯的原因，它让问题暴露得又早又清楚。
4.5 我的调试顺序清单
整理一份我自己的排查清单，遇到 context 相关怪问题就按顺序走：
- 先开 React DevTools，看组件树里的 Provider 层级正确吗？value 是什么？
- 再点 Profiler，录制一次状态变化，看哪些组件 re-render、为什么 re-render。
- 检查 value 是否被
useMemo缓存、依赖数组是否正确。 - 检查消费端是否用了
useContext直接拿整个对象，是否可以考虑拆成更细的 context 或者只取需要的字段。 - 最后检查是否真的需要全局 context，还是可以考虑把状态下放到局部。
按这个顺序，我解决过至少十几个看起来毫无头绪的 re-render 问题。养成习惯之后，这类问题从发现到定位基本能在十分钟内搞定。
5. 选型：Context 还是 Redux 还是 Zustand
5.1 Context/useReducer 组合的真正边界在哪里
我见过很多团队在"要不要上 Redux"这件事上反复拉扯。我的经验是：如果只是全局登录态、主题、偏好设置、简单购物车，Context + useReducer 就足够了。它零依赖，心智负担低，和 React 官方 API 完全同频，维护成本在所有方案里最低。
但它确实有边界。第一，性能边界：当数据量大、更新频率高、订阅组件非常多时，Context 的"广播式更新"机制会让所有订阅者一起重渲染，这个开销会随着组件数量线性增长。第二，调试边界：Context 没有自己的 DevTools 时间旅行、没有中间件机制，状态多了以后，追查一个 action 的来源全靠人肉叠加console.log。第三，模块化边界：Context 的 Provider 层级嵌套会越来越深，包一个就要套一层，包多了组件树看着跟千层饼一样。
5.2 Zustand、Redux 各自的定位差异
Redux 的核心优势是状态流转是完全可追踪的。action、reducer、selector、中间件、DevTools 时间旅行，这一整套工具链对于大型复杂应用非常值钱。但它的问题也明显：模板代码量大，学习曲线陡，一个简单的加购操作，你可能要写 action type、action creator、reducer case、selector，四个文件来回跳。如果你的团队还没有形成统一的 Redux 规范，它很容易变成一个大锅炉。
Zustand 则是我最近两年用得最多的替代方案。它的模型更轻：一个 store 就是一个create调用，状态和更新函数可以写在一个文件里，订阅是基于 selector 的细粒度订阅——你只订阅state.user，那state.cart变了你不会跟着重渲染。它在"context 的简单性"和"Redux 的可控性"之间找到了一个非常好的平衡点。如果新项目需要大量共享高频状态，我现在的默认推荐是 Zustand。
5.3 一张表理清主流方案的适用场景
| 方案 | 更新粒度 | 学习成本 | 模板代码量 | 调试能力 | 推荐场景 |
|---|---|---|---|---|---|
| Context + useState/useReducer | 广播（订阅者全量更新） | 低 | 低 | 弱 | 低频全局状态：登录态、主题、语言 |
| Redux Toolkit | 可控的细粒度订阅（selector） | 高 | 高 | 强 | 大型应用、团队协作、复杂数据流 |
| Zustand | 细粒度订阅（selector） | 低 | 低 | 中 | 高频共享状态、不用 Provider 包裹 |
| Jotai / Recoil | 原子级细粒度 | 中 | 中 | 中 | 复杂派生状态、需要比较灵活的原子化设计 |
我的经验是：别迷信任何方案是"银弹"。你要是问我新项目上来直接用哪个，我会先问三个问题：状态是高频还是低频？状态共享的跨度有多大？团队里有没有人已经有某个方案的熟练度？答案清晰以后，方案自然就出来了。
5.4 什么时候该从 Context 迁移到其他方案
一个项目里通常会混合使用多种状态管理工具，而不是非黑即白地把整个应用都迁到某个方案上。我有一个简单的迁移信号：当 Context 的 re-render 问题开始频繁出现，而你发现解法已经从"拆分 context"变成"小心翼翼地给几十个组件加 memo"的时候，就该抽身了。
具体判断标准，我列三条：
- 同一块状态被超过 20 个组件以不同的频率订阅，而且其中有高频更新的部分。
- 状态更新链路过长：一个输入框的变化要触发多层 context 联动，并且这些联动之间有依赖关系。
- 你开始需要在组件之外操作和读取状态，例如在工具函数、路由配置、或者非 React 模块里。
踩过几次坑之后，我的体会是：context-mode 本质上是一个"让局部状态可以跨层级共享"的工具，它的名字里"context"代表了作用域，"mode"代表着模式——你用一种模式去适合所有场景，一定会碰壁。正确的心态是把 Context 当成最顺手的那把螺丝刀，但不是工具箱里唯一的工具。每个状态管理方案都有自己的适用场景，工具是死的，判断力是活的。
最后再分享一个小技巧：如果你项目里已经开始用 context-mode 了，不妨隔三个月回头审视一遍所有的 Provider，看看有哪些状态其实根本不需要跨那么多层，把它下放到真正使用的组件里。这种"减法"比无限往 Provider 里堆东西重要得多——我见过太多项目，最后不是被技术难死的，而是被一层套一层的 Context Provider 给"套"死的。
