跨层级数据共享的context-mode：原理、框架实现与实战解析

开头先说说我自己遇到的一个场景。去年带一个中大型后台项目，权限信息、用户资料、国际化语言包、主题配置这些全局数据散落在十几个组件里。一开始靠props一层层往下传，组件层级深了以后，中间层的组件明明不关心这些数据，却必须接收再转发。那段时间每次新增一个字段，都要顺着组件树改七八个文件，改完还要逐个检查传递路径有没有漏。后来引入context-mode这套思路之后，状态管理变得非常干净——全局数据直接从顶层注入，任何深层组件都能按需读取，不再需要每层都做传声筒。

这篇文章想聊的就是context-mode（上下文模式），它是前端框架中一种解决跨层级数据共享问题的设计模式。核心思路是围绕“上下文”建立一个供给与消费的机制，让数据从组件外部注入进组件树，而不是沿着组件树的每个层级手动传递。文章会从原理、主流框架实现、实战案例到排查思路做一次完整拆解，适合正在用React、Vue或Angular做中大型应用开发的读者，也适合刚接触状态管理、对组件通信方式比较困惑的初学者。

1. 从prop逐层传参到Context：一个反复出现的痛点

1.1 三层嵌套的麻烦

先来看一个非常典型的场景。假设有一个页面组件Page，它下面挂着一个Sidebar组件，Sidebar里又挂着一个UserAvatar组件。现在UserAvatar需要显示当前登录用户的昵称和头像，而这个用户信息存在Page组件里。

按照React传统的prop传递方式，Page要把user对象传给Sidebar，Sidebar再传给UserAvatar。问题就出在：Sidebar本身完全不需要user数据，它只是恰好夹在中间。如果Sidebar下面还有更多层级的组件，那每一层都要把user这个prop接一遍、转一遍。

这种写法一旦层级深了，会有几个明显的感受：

• 中间层组件props定义越来越臃肿，很多是纯转发、自己根本不用的
• 想追踪某个数据是哪一层传下来的，得从最上层一直往下翻
• 重构时删除或重命名一个prop，所有经过的组件都要跟着改

我用一个小例子展示这种麻烦：

// 传统prop逐层传递 function Page() { const [user, setUser] = useState(null); return <Sidebar user={user} />; } function Sidebar({ user }) { // Sidebar自己不关心user，只是转发 return <UserAvatar user={user} />; } function UserAvatar({ user }) { return <span>{user?.name}</span>; }

这个例子只有三层，已经能感受到中间层的无奈。如果Sidebar下再套Collapse、List、ListItem几层，user这个prop会出现在每一层的参数签名里。这还只是一个数据字段，实际项目里的全局数据往往有十几个。

1.2 Context模式的解决思路

context-mode的理念很简单：把数据从组件树中抽离出来，放到一个“可访问的上下文区域”里。上层组件负责向这个区域注入数据，下层任意组件只需要声明自己“消费”某个上下文即可。

用上一节的例子改写，Page变成Provider的提供方，UserAvatar变成Consumer/订阅方，Sidebar完全无需感知user数据的存在：

// 使用Context模式 const UserContext = createContext(null); function Page() { const [user, setUser] = useState(null); return ( <UserContext.Provider value={{ user, setUser }}> <Sidebar /> </UserContext.Provider> ); } function Sidebar() { // 这里完全不用管user return <UserAvatar />; } function UserAvatar() { // 直接读取context const { user } = useContext(UserContext); return <span>{user?.name}</span>; }

这个改动最直接的收益是：数据结构变得更扁平，组件树中那些不关心数据的中间层不再被“污染”。更重要的变化是心智模型的转变——你不再需要思考数据从哪来、经过哪些层，只需要考虑“哪个组件需要什么数据”，然后让这个组件自己去找对应的Context。

这种模式不仅存在于React，Vue的provide/inject、Angular的DI机制，本质都是同一个思路。下面我会把原理和几个框架的各自实现逐一展开。

2. Context的底层原理：供给/消费模型与更新扩散机制

2.1 订阅-发布模型的核心构成

context-mode能够工作的底层机制，实际上是经典的“订阅-发布”模式。一套完整的Context实现通常包含三个角色：上下文对象（Context对象）、提供方（Provider）、消费方（Consumer）。

先说“上下文对象”。它像一个话题频道，本身不存数据，只是连接提供方和消费方的纽带。在React里你用createContext创建一个对象，它内部会维护一个用于标识的id，以及可能存在的默认值。提供方就是Provider，它持有真正的数据，并把数据“发布”给所有订阅了这个上下文的消费者。消费方则是主动获取数据的组件。

当提供方的value发生变化时，框架需要通知所有消费者更新。这个过程可以拆解为三步：触发变更、通知订阅者、重建消费组件。

触发变更通常来自组件内部的setState或外部的事件。通知订阅者是框架内部维护一个订阅者列表，当value对象引用变化时，遍历列表逐个通知。最后消费组件重新读取最新的value并执行渲染。

这里面有一个关键点：不是每个Context实现都会精确地只更新订阅了该Context的组件。有些框架的实现方式会比较“粗放”，可能会让某个范围内的所有组件都重新渲染。这正是性能问题的温床，我在后面第5节会详细讲。

2.2 为什么不建议用Context替代所有状态

理解了Context的更新机制之后，一个重要问题就浮现了：既然Context这么方便，是不是全局状态都可以塞进去？

我的建议是：不要。Context模式擅长的是传递“低频变化但被广泛依赖”的数据，比如当前用户、主题、语言包、功能开关。这类数据的特征是读取方多、更新的频率低、更新的范围大。

真正不适合Context的是那些高频变化且只有局部依赖的数据，比如表单输入值、动画进度、实时列表数据。原因很简单：Context的更新粒度通常无法做到“只更新某个组件”。虽然你可以在组件级别用useContext订阅，但一旦Context的value变化，该Context的所有消费者都会受影响。想象一下，一个实时更新的坐标值被放进Context里，每秒变化几十次，所有订阅它的组件都会跟着频繁重建，性能开销会迅速放大。

我经常用一句话来区分：如果数据是“静态的全局属性”，用Context；如果数据是“高频动态的业务状态”，用专门的Store（Redux/Zustand/Pinia/Vuex等）或者本地状态。这不是技术上的硬性限制，而是实践后得出的清晰结论。

2.3 更新粒度的悲观预期

前面说到Context更新是“通知所有消费者”，这里需要再深入一层。React中useContext的行为是当Context value的引用发生变化时，所有调用了该Context的组件都会重新渲染。即便某个组件只想订阅value中的某个字段，也无法阻止整体刷新。这是Context API目前的一个固有特性。

Vue的provide/inject在更新粒度上默认是响应的，只要注入的ref对象发生改变，相关组件就会更新。Angular的DI则不同，它默认的依赖注入并不会自动触发模板刷新，通常需要配合Observable或信号（signal）来做到精细化更新。

这个差异恰恰解释了为什么各个框架对Context的推荐场景比较一致：适合放“变化不频繁、影响面大”的数据，而不是高频变化的细粒度状态。

3. React、Vue、Angular的Context实现对比：API设计的差异与共性

3.1 React的Context API：从legacy到useContext

React的Context API经历了几次演变。老版本中的childContextTypes和contextTypes属于Legacy Context，优缺点都很极端——写起来很冗长，且层级较深时容易取得非预期值，官方后来也明确表示不推荐使用。新版本提供的createContext、Context.Provider和useContext/Consumer才是一个可用的方案。

在新版本中，React暴露三个核心API：

• createContext(defaultValue)创建一个Context对象
• <Context.Provider value={...}>包裹组件树并提供值
• useContext(Context)在函数组件中读取Context值

其中需要注意的一点是createContext的defaultValue。只有在组件的上层找不到对应的Provider时，defaultValue才会生效。若你在Provider中显式提供了undefined值，那么defaultValue不会覆盖，读取到的将是undefined。这是一个在实际开发中很容易踩到的细节。

下面是React中最标准的Context消费方式对比：

// 类组件中使用Consumer <UserContext.Consumer> {(user) => <span>{user.name}</span>} </UserContext.Consumer> // 函数组件中使用useContext const user = useContext(UserContext);

useContext的写法更简洁，也推荐在新代码中使用。但它有个隐含要求：useContext必须是函数组件内直接调用的Hook，不能放在条件判断或循环里。这也是React所有Hook的通用规则。

3.2 Vue的provide/inject：响应式注入

Vue的实现叫做provide/inject，跟React的Context理念一致，但写法上更贴合Vue自身的响应式体系。

父组件用provide提供数据，后代组件用inject注入数据。关键差异在于“响应式依赖”：Vue默认推荐在provide中传入ref或reactive对象，这样改动数据时，注入方会自动更新。如果传入普通对象，则不具备响应性。

<!-- 提供方 --> <script setup> import { provide, ref } from 'vue'; const user = ref(null); provide('user', user); </script> <!-- 消费方 --> <script setup> import { inject } from 'vue'; const user = inject('user'); </script>

这里比较常见的一个坑是：inject没有指定默认值时，若上层任何组件都没有provide这个key，就会返回undefined。建议在inject时都提供默认值，避免页面上出现读取错误的报错。另一个细节是inject的key可以是一个Symbol或字符串，如果你在一个项目中管理多个Context，建议单独建一个keys文件统一导出，不要随手写字符串常量。

为了确保数据变化能触达需要更新的组件，Vue官方推荐在provide中使用ref、reactive、computed这类响应式对象。直接传递普通对象的话，数据变化后组件不会自动刷新，因为Vue的响应性追踪无法感知普通对象内部的属性变化。

3.3 Angular的DI：对Context的另一种诠释

Angular并没有一个直接叫Context API的东西，但它的依赖注入（DI）框架承担的职责和Context模式是同一个维度——在上层注册一个服务实例，在下层直接注入使用。你可以在某个NgModule或组件中提供服务，然后在任意子组件中通过构造函数注入该服务。

// 服务端定义 @Injectable() export class UserStore { private user = signal<User | null>(null); readonly currentUser = this.user.asReadonly(); setUser(u: User) { this.user.set(u); } } // Parent组件中提供 @Component({ selector: 'app-page', providers: [UserStore], template: `<user-avatar />` }) export class PageComponent { } // 孙组件中注入 @Component({ selector: 'app-user-avatar', template: `<span>{{ store.currentUser()?.name }}</span>` }) export class UserAvatarComponent { constructor(readonly store: UserStore) { } }

Angular的DI有两个和前面框架特别不一样的地方。一是作用域严格：provide的层级决定了注入的可见范围，同一个服务可以在不同的组件树上各自提供独立实例，从而形成真正的多实例上下文。二是更新机制默认不触发视图刷新：服务对象的变化不会自动导致页面重新渲染，必须依赖Signal、Observable或ChangeDetectorRef手动触发。这也让Angular的Context模式在更新精细度上控制力更强，但心智负担稍重。

3.4 三种实现的对比小结

三个框架的Context实现各有侧重，我整理过一张表方便快速对照：

共性方面，三个框架都要求有一个“提供方”和一个“消费方”，并且都通过一种树形作用域来决定哪些组件能看到同一个上下文。差异则体现在更新机制上：React靠引用变化，Vue靠响应式对象，Angular靠信号或流订阅。

4. 实战落地：一个全局用户会话信息的Context设计过程

聊完原理和框架差异，我拿一个真实的项目场景来做完整的设计落地。需求是这样的：一个中后台系统，用户登录后需要在整个应用的不同角落读取当前用户信息，包括头像、昵称、角色、权限点列表，以及首页的登录态标识。数据会随登录、注销、资料更新而变化。这个需求非常适合使用context-mode。

4.1 需求分析和基本决策

先做几个决策：

• 数据形态：用户信息属于低频更新、广泛读取，适合Context
• 放入Context的内容：基础信息、角色权限、登录态
• 不放的内容：消息列表、待办事项、实时通知这类频繁变化的数据
• 项目框架：以React为例，但设计思路可平移到Vue

接着需要结合现有路由体系。一般来说，Provider应该放在路由组件的上方，让整个页面都能消费到用户信息。登录页面以外还需要一个全局的AuthBoundary，负责控制未登录用户的跳转逻辑。这样既保证Context覆盖范围广，又让认证逻辑集中在一个稳定的边界内。

4.2 完整实现：Provider + Hook + 类型定义

下面是一份精简但完整的实现。我将Context定义、Provider逻辑、消费Hook拆分成三个文件，便于维护。

首先是Context的创建与类型定义：

// auth-context.tsx import { createContext, useContext, useMemo, useState, type ReactNode } from 'react'; interface UserProfile { id: string; name: string; avatar: string; roles: string[]; permissions: string[]; } interface AuthContextValue { user: UserProfile | null; isLoggedIn: boolean; login: (user: UserProfile) => void; logout: () => void; updateUser: (patch: Partial<UserProfile>) => void; } const AuthContext = createContext<AuthContextValue | null>(null); export function AuthProvider({ children }: { children: ReactNode }) { const [user, setUser] = useState<UserProfile | null>(null); const value = useMemo<AuthContextValue>(() => ({ user, isLoggedIn: user !== null, login: (nextUser) => setUser(nextUser), logout: () => setUser(null), updateUser: (patch) => setUser((prev) => prev ? { ...prev, ...patch } : prev), }), [user]); return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>; } export function useAuth(): AuthContextValue { const ctx = useContext(AuthContext); if (!ctx) { throw new Error('useAuth必须在AuthProvider内部使用'); } return ctx; }

这里的两个细节值得一提。第一个是useMemo包裹value。没有它的话，每次AuthProvider重新渲染都会生成一个新的value对象，导致所有消费useAuth的组件全部重新渲染。加上useMemo之后，只有user变化时value引用才会变化。第二个细节是useAuth中如果拿不到Context就直接抛错。很多新手在使用Context时不会检查这一点，一旦把组件放到Provider外面，就会出现难以理解的undefined错误。直接抛错可以把问题暴露得更早、更明确。

然后是在根组件中加载AuthProvider：

// main.tsx 或 App.tsx import { AuthProvider } from './auth-context'; export default function App() { return ( <AuthProvider> <BrowserRouter> <Routes> <Route path="/login" element={<LoginPage />} /> <Route element={<AppLayout />}> <Route path="/dashboard" element={<DashboardPage />} /> </Route> </Routes> </BrowserRouter> </AuthProvider> ); }

这里有一个作用域的细节：BrowserRouter放在AuthProvider内部不影响Context工作，因为AuthProvider只注入数据。但如果你需要一个全局的导航守卫（比如未登录跳转/login），那守卫组件必须能读取useAuth，因此Router最好放到守卫的外层，或者守卫放在Router内部且位于AuthProvider之下。实际项目中我一般让AuthProvider在最外层，Router次之，守卫再下一层。

4.3 消费侧的封装：组件内怎么用得顺手

完成Provider之后，消费侧的做法也直接影响使用体验。

在普通的页面组件里，直接调用useAuth读取即可：

function UserMenu() { const { user, logout } = useAuth(); if (!user) return null; return ( <Dropdown avatar={user.avatar} name={user.name} onLogout={logout} /> ); }

在需要权限判断的地方，可以封装一个更细粒度的组件或Hook：

function usePermission(required: string) { const { user } = useAuth(); return useMemo( () => user?.permissions.includes(required) ?? false, [user, required] ); }

然后页面里写权限判断就很直白：

const canDelete = usePermission('order.delete');

这个封装模式是我在项目里一直用的。它让业务组件不直接面对user和permissions的结构，而是通过语义化接口获取能力。如果后续权限判断逻辑变复杂（比如增加角色层级、条件表达式），改动只会集中在这个Hook中，对业务组件透明。

4.4 场景延伸：主题切换与国际化

用户会话只是Context最常见的用途。我再用主题切换和国际化补全一个场景，说明同一个思路的多种落地。

主题切换的Context需要保存的主题类型、切换主题的方法。因为主题常常驱动CSS变量变化，所以Provider还要负责把主题名称应用到根节点上：

interface ThemeContextValue { theme: 'light' | 'dark'; toggleTheme: () => void; } const ThemeContext = createContext<ThemeContextValue | null>(null); function ThemeProvider({ children }: { children: ReactNode }) { const [theme, setTheme] = useState(() => { const stored = localStorage.getItem('theme'); return stored === 'dark' ? 'dark' : 'light'; }); useEffect(() => { document.documentElement.dataset.theme = theme; localStorage.setItem('theme', theme); }, [theme]); const value = useMemo( () => ({ theme, toggleTheme: () => setTheme(t => t === 'dark' ? 'light' : 'dark') }), [theme] ); return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>; }

这里的关键思路是：把“状态更新”和“副作用应用”放进Provider内部，消费组件只需要关心“当前主题是什么”和“怎么切换”。这比每个组件都自己去操作localStorage和DOM属性要干净得多。

国际化和它几乎同理：LanguageProvider保存当前语言，暴露一个setLocale方法，并内部管理一个字典查询方法。组件通过Hook获取翻译函数t，页面里写t('menu.home')就可以了。整个翻译字典放在哪个层级取决于你的项目结构，但Provider模式是固定的。

5. Context模式最常见的4个坑与完整排查链路

5.1 坑一：Provider的value引用不稳定导致全量重渲染

这个坑我碰到过太多次了。最初的代码往往是这样的：

<AuthContext.Provider value={{ user, isLoggedIn: !!user, login, logout }}> {children} </AuthContext.Provider>

只要AuthProvider有一点点更新，比如某个内部状态变化触发了渲染，value对象就会被重新创建。即便user没有变化，所有消费useAuth的组件也会跟着重新渲染。在组件树比较庞大时，这种无谓渲染会直接造成界面卡顿。

解决方法是把value用useMemo包起来。如果value中只有user是动态的，那依赖项就只留user。如果连login、logout这样的方法都是稳定的，可以用useCallback或直接定义在组件外部。

定位这个问题的排查思路我可以复现一下。当你发现点击某个按钮后，页面有一大片组件无谓刷新，打开React DevTools的Profile录制，观察有哪些组件被重新渲染，再看它们的hooks列表，通常会发现Context值是Porvider的新对象。把value用useMemo包裹后再录制一次，重渲染范围会大幅收缩。

5.2 坑二：Context默认值导致的初始化异常

React中createContext可以传默认值。不少人对默认值的使用有个误区——以为只要有默认值，useContext就一定不会返回null。实际情况是：组件如果没有被任何Provider包裹，那么useContext会返回默认值；如果被Provider包裹，但Provider的value显式传了undefined，那么返回的是undefined。

另一个更隐蔽的情况是动态创建Context对象。看这段代码：

function CurrentUserProvider({ children }) { const UserContext = createContext(null); // ... }

每一个CurrentUserProvider实例都会创建一个全新的Context对象。如果两个子组件分别读取到不同实例的Context，它们之间完全隔离。这种错误在把createContext放到组件内部时经常出现，且很难一眼看出来。正确做法是把createContext放到模块顶层，保证整个应用共享同一个Context对象。

5.3 坑三：Vue中inject到非响应式对象

Vue版本的坑主要集中在“忘了用ref/reactive包裹提供的值”，或者在外层在provide时直接用普通对象拼装值。

拿一个反面例子来看：

<script setup> const user = ref(null); // 错误：直接provide普通对象 provide('user', { user }); </script>

这种写法在消费侧拿到的是普通对象，修改user.value不会触发消费组件更新。正确的做法是：

<script setup> const user = ref(null); // 正确：provide整个ref对象 provide('user', user); </script>

两种写法一眼看不出太大差别，但响应式效果完全不同。这也是Vue的Context一个很容易踩的细节：你必须在provide的源头就决定“响应的数据源”到底是什么。

5.4 坑四：过度拆分Context与过度合并Context

最后一个坑是企业级应用里面最常见的决策难题：Context到底应该按什么粒度拆分。

我曾经接手过一个项目，整个应用只有一个GlobalContext，里面塞了几十个字段，几乎所有组件都从这里面取值。好处是写起来省事，代价是一丁点改动就导致全应用重渲染。后来我把global拆成几个独立Context：UserContext、ThemeContext、LocaleContext、FeatureFlagContext，每个Context的更新范围收窄到真正关心它的组件，性能立刻好转。

但同时我也见过另一个极端：一个页面里拆了十几个粒度很细的Context，每个Context只服务一个组件。这本质上只是把props转发问题换成了Context转发问题，并没有真正减少复杂度。

经验法则如下：按“数据变化的频率”和“消费方的范围”来拆。变化频率相近、消费方重叠度高的数据可以合并在一个Context中；变化频率差异大的数据尽量拆开。不需要纠结一个Context里放几个字段，而是看字段变更时“谁受牵连”。

5.5 完整排查链路的复现：一次性能问题的定位过程

我复现一个典型的排查过程，方便读者模仿。

现象：页面切换时，有一个状态列表组件明显卡顿，点击筛选按钮后整个页面有较长白屏时间。打开React DevTools的Profile后发现，AppLayout组件及其下所有子树都被标记为“Render due to context change”，但组件本身并没有state或props的变化。

于是怀疑Context的value引用不稳定。检查代码，发现UserMenu组件使用了useAuth来读取头像，而UserMenu在AppLayout下方。筛选按钮触发了某个State更新，这本来只应该重渲染筛选区域，却让UserMenu以及所有订阅AuthContext的组件都重绘了。

定位思路：

1. 记录下触发更新的父组件路径，找出哪个Provider在事件发生后重渲染
2. 检查Provider的value是否被useMemo包裹，如果没有，先给它加上
3. 加上后再次录制Profile，如果重渲染范围仍然很大，检查消费组件是否订阅了过宽的Context
4. 如果某个组件只关心user.avatar，却连带关注了permissions等大数组，考虑把Context按字段级别拆分

这个流程完整走下来，最终定位到最后一种情况。我把用户信息Context拆成了UserBaseContext和UserPermissionsContext两个，前者保存基础资料，后者保存权限数组。头像只订阅UserBaseContext，筛选按钮的变化只影响筛选区域，问题彻底解决。

6. 结合项目规模选择合适的context-mode规模

想要用好Context，除了掌握原理和踩坑经验，还要懂得“什么时候该用、什么时候不该用、用多大”。这其实是一个工程决策问题。

6.1 小型项目：别急着做完整的状态管理

如果你的项目只有两三个页面，全局状态只有用户信息和主题，Context模式完全够用，不需要引入Redux、Zustand、Pinia这些外部状态库。直接用原生Context，配合一两个自定义Hook即可。这种情况下，复杂度最低，心智负担小，维护也方便。

这个阶段不太建议做把Context拆得太细的事，因为项目规模小，重新渲染的代价不大，多拆反而多出很多样板代码。

6.2 中大型项目：Context + 局部Store 的分工

中大型项目里，Context负责全局低频共享数据，Store负责跨页面高频业务数据。两者互补，并不互斥。

例如权限信息、用户信息、主题、语言用Context；订单列表、通知列表、表单草稿这类高频数据用Store。这样等于把两种技术用在自己最适合的场景上。我的实际经验是，到了这个规模，应该对Context有一个统一的规划文档，明确哪些数据走Context，哪些走Store，防止后续开发人员各写各的。

6.3 服务端状态和客户端状态的边界

还有一个经常被忽略的维度：哪些数据适合放到Context里，取决于它是服务端状态还是客户端状态。

服务端状态（从API获取、需要缓存、可能被其他页面修改）不一定适合用Context来做。服务端状态最好交给专业的服务端状态工具，比如TanStack Query、SWR、Vue的Pinia + composable。Context比较适合的是“认证信息、偏好设置、国际化、主题这类客户端全局状态”。

把这两类状态都塞进Context，会导致Context频繁更新。因为在服务端状态里，接口请求、轮询、缓存失效都会触发状态变化，这些都会扩散到所有消费者。划清边界是一个架构层面的前置决策，直接在初期就规避掉后续的扩展性问题。

6.4 渐进式迁移路径

如果项目现在已经用了大量的props逐层传递，想要逐步迁移到Context，不需要一次性改完。我会采用这样的渐进式路径：

1. 先找出最常被逐层转发的数据，建立对应的Context
2. 从最底层开始，把读取props的组件改成读取Context
3. 逐层删掉中间层组件里不再需要的props转发
4. 全部迁移完后再检查一次是否有中间层产生了无效的Context订阅

这样每个步骤都是小步的、可验证的，不会像一次重构那样容易出大问题。每次改动后跑一遍编译和核心用例，风险可控。

7. 最后要记住的几个实操习惯

把context-mode用到项目里并不难，难的是用得干净。总结一点我在实际项目中慢慢养成的小习惯。

一是坚持写自定义Hook。不要在全代码里散落useContext(XxxContext)，而是每个Context配一个专用Hook，这个Hook内部负责判空、组合取值、提供友好错误提示。团队成员用起来简单，调试时又能直接看到报错说明。

二是把Context对象单独放到文件里。一个Context对象本身不包含任何业务逻辑，但它是一个跨模块的契约。单独放在一个文件里导出，可以避免循环依赖问题，也方便统一查看。

三是为了性能把value用useMemo固化住。这个一定要形成肌肉记忆。React的Context只要Provider重新渲染，value就会重建，除非你明确用useMemo控制。忘了useMemo就等于给自己埋雷。

四是不要只盯着React系列，多看看别的框架怎么做。真正理解context-mode的人会发现，模式背后是一个通用思想：跨越组件树层级进行数据注入。React的Context、Vue的provide/inject、Angular的DI都是同一种思想的实现。理解了这种通用性，到哪一个框架都能迅速看懂别人在写什么，也能做出契合设计意图的方案。

我曾在一个项目里用这套思路同时给React前端和Vue前端做技术方案，两边的整体结构相似度极高，只是API名称不同。这也是为什么我一直觉得，先把“模式”本身吃透，比死记某个API的用法要重要得多。