你有没有遇到过这样的场景：一个组件需要的数据，其实存在于另一个遥远的祖先组件中？比如，页面顶部的用户头像需要显示用户名，而用户名状态却保存在最外层的 App 组件里。中间隔着 Layout、Header、Navbar 三层组件——这时候，你该怎么办？
难道要让每一层组件都手动把数据“传下去”？如果未来再加两层，是不是又要改五处代码？这听起来既繁琐又脆弱。
React 的组件通信机制，正是为了解决这类问题而设计的。但它的解法并非一蹴而就，而是从最基础的父子通信开始，逐步演化出更高效的模式。今天，我们就一起思考：React 是如何一步步帮我们摆脱“数据搬运工”的命运的？
一、父传子：如果我的数据在别人那里，怎么拿到？
假设你写了一个 <Button> 组件，但它显示的文字不是固定的，而是由外部决定的。那么问题来了：子组件如何获取父组件的数据？
React 给出的答案非常朴素：通过 props 传递。
function Parent() {
return <Child message="Hello from parent" />;
}
function Child({ message }) {
return <div>{message}</div>;
}
这里，Parent 把 message 作为属性（prop）传给 Child，Child 通过函数参数接收。这种机制简单、直观，且符合函数式编程的思想：输入决定输出。
但请注意：props 是只读的。子组件不能修改它。这保证了数据流的可预测性——所有状态变更都必须由拥有者（通常是父组件）发起。
然而，现实中的交互往往是双向的。比如，子组件里的按钮被点击后，可能需要通知父组件更新某个状态。这时，光靠“父传子”就不够了。
二、子传父：如果我想改变父组件的状态，该怎么办？
继续上面的例子：现在 <Child> 里有一个按钮，点击后希望父组件的计数器加一。但子组件没有权限直接修改父组件的状态——那怎么办？
React 的思路是：既然子不能改父，那就让父“授权”给子一个修改自己的方法。
具体做法是：父组件把自己更新状态的函数（如 setCount）作为 prop 传给子组件。子组件在需要时调用这个函数，从而间接触发父组件的状态更新。
function Parent() {
const [count, setCount] = useState(0);
return (
<>
<p>Count: {count}</p>
<Child onIncrement={() => setCount(count + 1)} />
</>
);
}
function Child({ onIncrement }) {
return <button onClick={onIncrement}>+1</button>;
}
关键点在于：子组件并没有“修改”父的状态，而是“请求”父去修改。父组件收到请求后，自己执行 setCount，然后重新渲染，把新值通过 props 再次传给子组件。
这种“回调函数作为 prop”的模式，构成了 React 中 子→父通信的标准范式。它看似绕了一圈，却换来了清晰的数据流向和调试便利性。
但问题又来了：如果有两个子组件，它们需要共享同一个状态怎么办？比如，一个输入框和一个预览区域，都依赖同一段文本。
三、兄弟组件通信：它们之间真的能直接对话吗？
很多人会误以为兄弟组件可以直接通信。但 React 的答案是否定的：没有直接通道。
那怎么实现同步？答案是：把共享状态提升到它们的共同父组件中。
function Parent() {
const [text, setText] = useState('');
return (
<>
<Input onChange={setText} />
<Preview content={text} />
</>
);
}
Input调用onChange(newText)→ 父组件更新text→ 父组件重新渲染 →Preview收到新的content。- 表面上看，是
Input影响了Preview；实际上，是 父组件作为中介完成了状态中转。
你会发现，兄弟通信的本质，其实是“子→父→子”的组合。它复用了前两种通信模式，并没有引入新机制。
到这里，我们已经构建起一套完整的通信体系：
- 父→子：props 传递数据；
- 子→父：props 传递函数；
- 兄弟通信：状态提升 + 上述两种模式组合。
这套体系逻辑自洽、易于理解。但当组件树变得很深时，问题就暴露了。
四、跨层级通信的困境：为什么“一路传”让人头疼？
想象这样一个场景：你的应用有主题切换功能。主题状态保存在 <App> 组件中，而一个深埋在 <Page> → <Section> → <Card> → <Button> 里的按钮需要根据主题改变颜色。
按照现有模式，你得这样写：
<App theme={theme}>
<Page theme={theme}>
<Section theme={theme}>
<Card theme={theme}>
<Button theme={theme} />
</Card>
</Section>
</Page>
</App>
中间的 Page、Section、Card 根本不关心 theme，却被迫传递它。这种现象被称为 prop drilling（属性穿透） 。
它带来的问题很明显：
- 代码冗余；
- 组件耦合度高（中间组件必须知道要透传哪些 props）；
- 难以维护（新增一层就得改所有中间组件）。
这时候，你可能会想：现实中，如果我要拿一个东西，难道非得让人一级一级递给我吗？有没有更快的方式？
当然有！比如——自己去快递站取。
五、Context 通信：设立一个“快递站”，谁需要谁去拿
回到刚才的主题例子。如果我们能在 <App> 里设立一个“主题快递站”，那么无论 <Button> 嵌套多深，只要它在快递站的服务范围内，就可以直接去取主题数据，无需中间人传递。
React 的 Context 正是为此而生。
第一步：创建快递站
const ThemeContext = createContext('light');
这行代码相当于注册了一个名为 ThemeContext 的快递品牌，默认主题是 'light'。
第二步：在顶层装货并划定服务范围
function App() {
const [theme, setTheme] = useState('dark');
return (
<ThemeContext.Provider value={{ theme, setTheme }}>
<Page />
</ThemeContext.Provider>
);
}
<ThemeContext.Provider> 就是快递站本身。value 是存入的包裹（包含数据和修改方法），而 <Page> 及其所有后代组件，都在这个快递站的服务范围内。
第三步：任意组件直接取件
function DeepButton() {
const { theme, setTheme } = useContext(ThemeContext);
return (
<button
style={{ background: theme === 'dark' ? '#333' : '#fff' }}
onClick={() => setTheme(theme === 'dark' ? 'light' : 'dark')}
>
切换主题
</button>
);
}
无论 DeepButton 在第几层，只要它在 <Provider> 内部，就能通过 useContext(ThemeContext) 直接获取数据。它不需要知道数据从哪来，也不需要中间组件帮忙传递。
这就是 Context 的核心价值：打破层级限制，实现按需获取。
为什么说这是对前面模式的升华？
- 它依然遵循“状态由外层管理”的原则（快递站还是父组件建的）；
- 它依然保持单向数据流（状态变更仍由 Provider 内的 setter 触发）；
- 但它消除了不必要的中间传递，让通信路径从“线性”变为“星型”。
更重要的是，Context 并没有颠覆之前的通信逻辑，而是对其在跨层级场景下的优化。你可以把它看作“父传子”的跨级版本——只不过“子”现在可以跳过中间层，直接和“祖先”对话。
六、总结：通信的本质是什么？
回顾这四种场景，我们会发现：
- 父→子 是基础，确立了数据下行的通道；
- 子→父 是反馈，通过回调实现状态更新的请求；
- 兄弟通信 是组合，依赖共同父组件作为状态枢纽；
- Context 是优化，将“逐层传递”变为“按需订阅”。
它们的共同本质是：状态由拥有者管理，其他组件通过明确接口访问或请求变更。React 始终坚持单向数据流，拒绝隐式的双向绑定，正是为了保证应用的可预测性和可维护性。
而 Context 的出现，并非否定 props，而是在合适的场景下提供更高效的解决方案。就像快递站不会取代面对面交接，但在长距离配送时，它显然更高效。
