如果你写 React 写过一段时间，大概率会遇到这么个折磨人的场景：明明一个用户状态定义在 App 顶层，结果为了把它送到底层的头像组件里，中间四五层组件全都得老老实实接一遍 props。改个字段名，编辑器里红色报错能从最顶层一路炸到最底层。React 生态里能解决跨层级数据传递的方案不少，其中最基础、最顺手、也最容易被低估的就是 Context。这篇文章就用一个完整的实战案例，聊聊我是怎么用 Context 把层层传 props 的样板代码砍掉大半的。适合被 props drilling 折磨过的前端开发，也适合刚学完 React 基础、想搞明白状态管理该怎么选型的人。
1. 层层传 props 这件事，怎么就成了开发负担
1.1 props drilling：从哪一层开始变味
props 本身是 React 最清晰的数据传递方式，父组件传子组件，单向数据流，直观、可控。可问题出在“跨层级”三个字上。一个状态如果只是父传到子、子再传到孙，那没问题；但如果它在第 1 层定义，真正消费它的组件在第 5 层，中间第 2 到第 4 层的组件就非常尴尬——它们不关心这个数据，却必须接收这个 props，再原封不动地往下传。
这种层层透传在 React 圈子里有个专门的名字，叫 props drilling，有人翻译成“属性钻洞”。听起来有点搞笑，但实际写起来是真的难受。最典型的就是用户信息、主题配置、语言包这一类的全局数据。它们的特点是：几乎每个组件都可能用，但又不是每个组件都需要感知它们的存在。你用 props 去传，等于让所有中间组件都变成“数据管道”，组件本身的职责被搅浑了。
我见过不少项目，中间层组件明明是一个纯展示组件，结果 props 类型定义里躺着十几个字段，其中一大半是它压根用不到、只是帮孙子组件转交的。这种代码表面上能跑，实际上维护成本极其离谱。你想重命名一个字段，编辑器高亮能帮你找出所有引用，但你得一个个判断哪些是真正消费数据的组件、哪些只是路过。改完之后还要重新跑测试，生怕哪里漏了。
1.2 传参样板代码带来的真实成本
很多人觉得多写几行 props 而已，能有多大事。但“而已”两个字是经不起算的。假设一个典型业务页里，用户信息要从 App 传到 Dashboard、Dashboard 传到 ProfileLayout、ProfileLayout 传到 ProfileCard、ProfileCard 再传给 Avatar 和 UserInfo。这一条链路下来，每层组件差不多要写：
- props 类型定义（TypeScript 项目还要额外写 interface）
- 函数入参的解构
- JSX 里子组件的参数拼接
如果这条链路有 5 层，你至少要写 5 份重复的类型声明和透传代码。而且这还只是一个数据，实际项目里用户信息、权限标记、主题色、多语言文案往往是捆在一起的。数据一多，代码量直接指数级膨胀。有个项目我接手的时候，光一个 Sidebar 组件的 props 类型就有 80 多行，里面一半以上是给子组件转交的。每次改动都要小心翼翼，生怕碰到某个“只路过”的字段。
更麻烦的是，props 透传让组件的复用性大打折扣。一个组件接收了 5 个“转交类” props，你在别的页面想复用它，就必须把这些 props 一层层补齐，哪怕那些字段对它本身毫无意义。这种隐性耦合非常恶心，它让组件看起来有自己的接口边界，实际上边界全是漏的。
所以当我决定动手重构的时候，第一件事就是把这些“中间转交者”的 props 全部摘掉，改用 Context 直接把数据送到真正需要的组件手里。这也是“少写 80% 代码”说法的来源——不是业务逻辑变少了，而是那些无意义的样板传递代码几乎清零了。
2. Context 的工作原理，比想象中简单
2.1 发布订阅：Context 在 React 里的本质
很多人一看到 Context 就犯怵，觉得是什么高级黑魔法。其实它底层就是一个典型的“发布-订阅”模型。你先用createContext创建一个“频道”，然后用Provider当“广播台”把数据发布出去，最后用useContext让目标组件“订阅”这个频道的数据。中间那些不订阅的组件，根本感知不到数据的存在。
这个思路跟 props 最大的区别在于：props 是“主动投递”，你得一层一层亲手把数据递到目标组件手里；Context 是“按需订阅”，谁要用谁自己来取。只不过 React 帮你把订阅和取数的过程封装好了，你只需要关心三样东西：Context 对象、Provider 的 value、消费端的 useContext。
理解这点非常重要，因为很多使用误区都出在“把 Context 当成状态管理工具”上。Context 本身不管理任何数据，它只是一个传输通道。你给它什么 value，消费端看到的就是什么 value。如果 value 里的数据变了，消费端会跟着变；但 Context 自己不会主动产生数据，也不会帮你做任何计算。
这就好比公司里的内部快递柜。props 是行政挨个工位送文件，Context 是文件放进了柜子，谁需要谁刷工卡取。快递柜本身不生产文件，它只负责中转。想明白这个类比，你就能理解为什么 Context 不能替代 Redux、Zustand：它是“管道”，不是“仓库”。
2.2 createContext 到 Provider 的完整链路
我们直接看代码。创建一个 Context 最基础的写法是这样的：
import { createContext } from 'react'; const UserContext = createContext(null);createContext(null)里的null是默认值。这个默认值只在“没有 Provider 包裹”时才会被useContext拿到。一旦外层有 Provider，消费端拿到的一定是 Provider 里传入的value，默认值会被完全覆盖。
接着要写 Provider。通常我会单独封装一个 Provider 组件，这样业务组件里不需要关心 useState 的细节：
import { useState } from 'react'; export function UserProvider({ children }) { const [user, setUser] = useState(null); return ( <UserContext.Provider value={{ user, setUser }}> {children} </UserContext.Provider> ); }注意，这里的value每次 UserProvider 重新渲染都会生成一个新对象。这一点极其重要，后面讲性能时我会专门展开。现在你先记住这个写法，先跑通链路。
消费端用useContext取数据：
import { useContext } from 'react'; import { UserContext } from './UserContext'; function Avatar() { const { user } = useContext(UserContext); return <img src={user?.avatar} alt={user?.name} />; }从使用者的角度来说，真正干活的只有三行：创建 Context、提供 value、消费 value。中间所有层级的组件都不需要知道你传了什么数据，也不需要在 props 里声明任何跟用户相关的字段。
2.3 Context 不是状态管理，别混为一谈
聊 Context 的时候经常有人把 React Redux、Zustand、Jotai 之类的一起比较，然后问“到底该用哪个”。我的观点很直接：Context 和这些状态管理库根本不在一个维度上。Context 解决的是“数据怎么跨层级传递”，状态管理库解决的是“数据怎么组织、怎么变更、怎么被追踪”。
用 Context 的时候，数据变更逻辑还是写在 useState、useReducer 里。它只是把这些状态从前到后传递的方式换了一种。而 Redux 这类工具，核心价值在于集中化的 store、可预测的 reducer、时间旅行调试等能力。你把两者混为一谈，就容易陷入“用了 Context 就不需要状态管理库”或者“状态管理库能替代 Context”的误区。
实际项目中，我更倾向于把 Context 和状态管理库搭配使用。比如全局的登录态、权限标记、主题配置，用 Context 就够；但那些带复杂异步流、联动更新、需要跨模块共享的业务状态，我会上 Zustand 或者 Redux Toolkit。Context 负责“传”，状态库负责“管”，各干各的，边界非常清晰。
从 React 19 开始，官方还出了一个叫use(Context)的新写法，可以直接在组件里读取 Context，不用useContext包裹。这个 API 在配合服务端组件时能省掉不少麻烦，后面第 5 章我会再说。
3. 实战案例：把登录态从五层传递改成一处提供
3.1 改造前：一个典型的传参地狱
说再多理论，不如直接上一段真实场景。假设我们有一个后台管理系统，顶部导航栏要显示用户头像和用户名，个人中心页面里也要展示用户完整资料。用户状态定义在根组件里，数据结构大概长这样：
{ id: 1001, name: '陈一', avatar: 'https://example.com/avatar.png', role: 'admin', email: 'chenyi@example.com' }改造前的组件嵌套关系大概是这样：
- App：定义 user 和 setUser
- Dashboard：需要接收 user，并把它转给 Header 和 MainContent
- Header：需要接收 user，并把它转给 UserMenu
- UserMenu：真正消费 user（显示头像和昵称）
只看这 4 层，你可能觉得也没啥。但真实项目不会这么干净，MainContent 下面往往还有好几层路由组件、布局组件，很可能出现 6 到 7 层的透传。每层代码大致是这个意思：
// App.jsx function App() { const [user, setUser] = useState(null); return ( <Dashboard user={user} onLogin={setUser} onLogout={() => setUser(null)} /> ); } // Dashboard.jsx function Dashboard({ user, onLogin, onLogout }) { return ( <Layout> <Header user={user} onLogin={onLogin} onLogout={onLogout} /> <MainContent user={user} onLogout={onLogout} /> </Layout> ); } // Header.jsx function Header({ user, onLogin, onLogout }) { return <UserMenu user={user} onLogin={onLogin} onLogout={onLogout} />; }看到了吗？Dashboard 和 Header 本身根本不需要处理登录逻辑，它们只是“路过”。但为了让数据下去，它们必须参与 props 的接收和转发。项目一大人一多，这种中转代码就会越长越多，最后变成谁都不敢动的雷区。
3.2 改造后：用 UserContext 重写
现在我用 Context 重构上面的链路。先新建一个src/context/UserContext.jsx：
// src/context/UserContext.jsx import { createContext, useContext, useMemo, useState } from 'react'; const UserContext = createContext(null); export function UserProvider({ children }) { const [user, setUser] = useState(null); const value = useMemo(() => ({ user, setUser, login: (userData) => setUser(userData), logout: () => setUser(null) }), [user]); return ( <UserContext.Provider value={value}> {children} </UserContext.Provider> ); } export function useUser() { const ctx = useContext(UserContext); if (!ctx) { throw new Error('useUser 必须在 UserProvider 内部使用'); } return ctx; }然后改根组件，只负责挂 Provider：
// App.jsx import { UserProvider } from './context/UserContext'; import Dashboard from './Dashboard'; function App() { return ( <UserProvider> <Dashboard /> </UserProvider> ); }中间层的 Dashboard 和 Header 全部瘦身：
// Dashboard.jsx function Dashboard() { return ( <Layout> <Header /> <MainContent /> </Layout> ); } // Header.jsx function Header() { return <UserMenu />; }真正消费数据的 UserMenu 组件，直接自行订阅：
// UserMenu.jsx import { useUser } from '../context/UserContext'; function UserMenu() { const { user, logout } = useUser(); if (!user) { return <button onClick={() => login()}>登录</button>; } return ( <div className="user-menu"> <img src={user.avatar} alt={user.name} /> <span>{user.name}</span> <button onClick={logout}>退出</button> </div> ); }对比一下改造前后的改动量：中间两层组件少了几次 props 声明、解构、透传；UserMenu 组件不再关心数据从哪来，它只管自己要 user。数据链路由“5 层显式接力”变成了“1 个 Provider 广播 + 1 个地方订阅”，中间 4 层的样板代码全部归零。在真实项目里，一个中型后台系统有几十个这样的全局状态，整体省下的代码量非常可观。
3.3 混合模式：只对“频繁变化”的数据保持 props
用 Context 不代表所有数据都得往里塞。我在实际重构中踩过坑之后，慢慢总结出一个原则：按“变化频率”和“消费范围”给数据分类。
- 低频变化、跨层级消费的：登录态、权限、主题、语言、全局配置，适合 Context。
- 高频变化、只在一小块区域消费的：表单输入、列表筛选、动画进度，优先保持 props 或者用组件内部状态，不强行上 Context。
- 高频变化、跨层级消费的：比如播放器进度、协同光标，需要用更精细的状态管理方案或者拆分 context，如果单纯套一个大 Context，性能会很难看。
继续拿用户信息举例。用户资料的name、avatar属于低频变化数据，用户登录后基本固定，放进 Context 很安全。但如果你在同一个 Context 里塞了user、theme、locale、permissions，只要其中一个变量变了，所有消费整个 value 的组件都会跟着重渲染。所以更稳妥的做法是把不同维度的状态拆成独立的 Context，各管各的。一个 Context 管登录态，一个 Context 管主题，互不干扰。
这种混合模式下，props 并没有被抛弃。它依然是组件局部状态和父子组件紧耦合场景下的第一选择。Context 解决的是“跨层级共享”，props 解决的是“父子通信”，两者是互补关系，不是替代关系。
4. 性能陷阱与工程化实践
4.1 Context 更新为何会拖累整棵子树
这是面试里几乎必考、实战里最容易踩坑的点：Context 更新时，所有消费了这个 Context 的组件都会重新渲染。注意，不是只有数据变化相关的那个组件，而是所有订阅了这个 Context 的组件。
原因在于，Context 内部没有做“字段级依赖追踪”。React 只知道某个组件调用了useContext(UserContext)，但它不知道你具体用了 value 里的哪个字段。所以一旦 value 变了，所有订阅者都默认需要重新渲染。
更隐蔽的问题是 value 本身。看下面这段：
function UserProvider({ children }) { const [user, setUser] = useState(null); return ( <UserContext.Provider value={{ user, setUser }}> {children} </UserContext.Provider> ); }每次 UserProvider 因为任何原因重新渲染，都会生成一个新的对象字面量{ user, setUser }。哪怕 user 的值没变，这个 value 也是新的引用。React 做浅比较时发现“值变了”，于是强制所有消费端重渲染。这会让你的优化努力白费。
解决办法有两个方向：一是给 value 加useMemo，让它在依赖不变时保持引用稳定；二是拆 Context，把“数据”和“操作方法”分开，或者按业务领域拆成多个 Provider。两者结合效果最好。我的习惯是只要 value 里有对象或者数组，一律用useMemo包一层，别偷懒。
4.2 拆分 Context + useMemo，把渲染范围收窄
先说拆分场景。假设我们有一个AppProvider，里面同时管理用户信息和通知列表。通知列表可能每 5 秒轮询一次，用户信息基本不变。如果放在同一个 Context 里，通知一更新，用户信息相关的所有组件也会被迫刷新。这就不合理了。
拆开之后：
<UserProvider> <NotificationProvider> <App /> </NotificationProvider> </UserProvider>UserProvider 只管用户信息，NotificationProvider 只管通知。通知更新时只影响订阅 NotificationContext 的组件，用户相关的组件可以安然无恙。这是最直接的性能优化手段，而且不需要引入任何额外依赖。
再配合 value 的 useMemo：
const value = useMemo(() => ({ user, setUser }), [user]);这样只有当 user 真正变化时，value 引用才会变化。如果只是 UserProvider 父级导致的无关重渲染，value 依然保持旧引用，React 会跳过 Consumer 的重渲染。
如果你用的是 React 18 之后的新版自动批处理，再加上 Start Transition 之类的并发特性，Context 的性能表现其实比很多人想象中好。但前提是你不能在 value 里随手创建新对象。这个习惯从第一天就要养成。
4.3 服务端渲染和测试中的注意点
Context 在服务端渲染（SSR）环境下有一些特殊表现。Next.js 这类框架在服务端生成 HTML 时，Provider 的值可能只包含初始状态。如果你的 Provider 依赖浏览器 API（比如 localStorage 里的 token），服务端渲染出来的内容和客户端首次渲染的内容不一致，就会触发 hydration 警告。
我的做法是把“从 localStorage 读初始值”放到 useEffect 或者自定义的挂载阶段，避免在 useState 初始化函数里直接访问 window。更稳妥的方案是先用默认值渲染，客户端挂载后再从 localStorage 读数据更新 Context。虽然首屏可能闪烁一帧默认值，但至少不会产生 hydration 错误。
测试方面也有坑。写单元测试时，组件只要用了useContext，就必须保证它外面有对应的 Provider。最常见的报错是useContext拿到默认值null，然后代码里直接访问user.name就炸了。所以我在封装useUser时加了那行判断，一旦检测不到 Provider 就抛异常。测试失败时能第一时间定位到“没包 Provider”还是“业务逻辑错误”，排查速度快很多。
4.4 与 TypeScript 结合遇到的小坑
TypeScript 项目里，Context 的泛型设计是个容易被忽略的细节。如果createContext<UserContextValue | null>(null)，那么所有消费者都要做空值判断，代码很啰嗦。如果你直接createContext<UserContextValue>(undefined as any)，就把类型安全丢了。
我更推荐用“自定义 hook + 运行时断言”的方案：Context 默认值传 null，但useUser()内部判空后抛出异常，然后返回类型直接收窄成UserContextValue。这样业务组件里用起来很干净，不需要到处写空值判断，类型也能自动推导。
interface UserContextValue { user: User | null; login: (user: User) => void; logout: () => void; } export function useUser(): UserContextValue { const ctx = useContext(UserContext); if (!ctx) { throw new Error('useUser 必须在 UserProvider 内部使用'); } return ctx; }这个模式在代码库里非常实用。唯一要注意的是，如果你在 Context 的值里塞了 undefined 作为“合法状态”，就要谨慎判空。但一般业务场景里，用户信息为 null 就是未登录，用!ctx判断足够。
5. 常见问题与排查实录
5.1 我遇到的最像 bug 的坑：默认值失效
有一次我在代码里写了createContext(defaultUser)，本以为组件拿不到 Provider 时能自动用默认用户，结果页面却一直显示未登录。排查了半天才发现，根组件里早就被更高层级的 Provider 包住了，而且那个 Provider 的 value 是null。React 在决定消费端取值时，只看“最近的 Provider”，不会管你 createContext 时的默认值。
默认值只在“没有任何 Provider 包裹”时才生效。而一个大型应用里，根组件几乎总是被各种 Provider 包裹的。所以默认值更适合拿来当“调试提示”和“类型占位”，而不是真的当业务数据兜底方案。想给数据设初始值，应该在 Provider 内部的 useState 里设，而不是在 createContext 的默认参数里设。
5.2 排查顺口溜：先看层级，再看引用
Context 不更新，是很多初学者头疼的问题。我自己总结了一套排查顺序，基本能解决 90% 的怪现象：
- 消费组件的根节点，是否位于 Provider 内部？React 里组件树层级不满足“Provider 在上”，订阅者永远拿不到数据。
- Provider 的 value 引用变了吗？如果 value 是用普通对象字面量写的，父组件重渲染就会导致整个 Consumer 全量刷新。
- 是不是用错了 Context 实例？项目变大后，容易从两个不同的文件里 import 同名 Context，一旦实例不对，就接不上信号。
- 数据是否在 Provider 内部被更新？如果你在外面直接改 store 或全局变量，不触发 React 的 setState，Context 当然不会刷新。
这套排查逻辑不但能解决 Context 的问题，对很多 React 状态问题都通用。尤其是第 2 点，哪怕是 React 老手，也经常在 value 引用稳定性上翻车。
5.3 比 Context 更合适的替代方案，什么时候换
Context 虽然不是状态管理库，但它能覆盖的场景很多。面试里我经常看到有人问“Context 能替代 Redux 吗”，我的答案一直是：用 Context 能解决的问题，就别上 Redux；但 Context 解决不了的问题，也别硬撑。
什么情况下我会主动放弃 Context？一是数据模型复杂、变更逻辑多，需要 action/reducer 来约束；二是同一份状态要被多个模块共享，且模块之间没有明确的组件树包含关系；三是需要持久化、时间旅行调试、中间件等能力。这三种情况，我直接用 Zustand 或者 Redux Toolkit 更省心。
Zustand 有个好用的点是，它同时支持 Context 风格和外部 store 风格，而且默认做了 selector 优化，可以按需订阅某一个字段。如果你被 Context 的“牵一发动全身”搞烦了，可以试试这类库。不过这是另一个话题了，今天不展开。
5.4 React 19 新写法带来的体验变化
React 19 稳定之后，我试用了一下新的use(Context)写法：
import { use } from 'react'; function UserMenu() { const { user } = use(UserContext); return <span>{user?.name}</span>; }跟useContext最大的区别是，use可以在条件分支里调用，也可以搭配服务端组件使用。不过从效果上说，它在客户端组件里基本就是useContext的语法糖，底层订阅机制没有本质变化。所以之前关于 value 稳定性和拆 Context 的经验，在 React 19 里同样适用。
唯一的建议是：新项目可以直接用use(Context)熟悉新 API，老项目不用急着迁移，useContext也不会被删。工程迁移讲究稳定优先，没必要为了新特性赶工。
结尾：我现在的选择标准
用了这么久的 Context，我现在的选择标准其实很简单：凡是非要从顶层跨好几层去传、而且中间组件根本用不到的数据，我都默认用 Context 接；凡是只在局部几个组件间流动的数据，继续保持 props。这个标准执行了大半年，代码维护成本肉眼可见地降下来了。回头再看那些需要层层透传的代码，最想说的不是“怎么这么繁琐”，而是“当初怎么就忍了那么久”。如果你也被 props drilling 折磨，建议先拿一个用户登录态练练手，把 Provider 包上去，把中间层的 props 删干净，自己感受一下差距。
