Context不是万能解耦方案，因其订阅式广播机制导致Provider value引用变化时所有消费者强制重渲染；适合低频全局状态（如主题、登录态），不适合高频局部状态（如按钮点击次数）。
为什么 context 传值在 React 中不是“万能解耦方案”
因为 context 本质是订阅式广播，只要 Provider 的 value 引用变化，所有消费它的组件都会强制 re-render——哪怕只改了一个无关字段。它适合低频、跨多层、真正全局的状态（如主题、语言、用户登录态），但绝不该用来传按钮点击次数或表单输入值。
常见错误现象：useContext(MyContext) 导致列表项全部重渲染；value 直接传 { count, onChange } 对象，每次父组件 render 都新建对象，触发下游无差别更新。
- 正确做法：拆分 context，高频更新状态单独封装（比如用
useReducer+useMemo控制value引用） - 更轻量替代：对单个子组件，优先用 props 传函数（
onIncrement）而非整个 action 对象 - 警惕嵌套：两层以内组件传值，
context的开销和可读性反而不如直接 props
全局变量（window.xxx / 模块级 let）为什么在 React 里等于埋雷
它绕过 React 的响应式机制，状态变更不会触发组件更新。你改了 window.currentUser，依赖它的组件完全无感，除非手动 forceUpdate 或混用 useState 做桥接——那就失去了全局变量的“简洁”意义。
使用场景极其有限：仅适用于纯计算、无 UI 关联的缓存（如第三方 SDK 实例、防抖定时器 ID），且必须配合严格命名空间（如 window.__MY_APP__API_CLIENT）避免污染。
- 性能陷阱：模块级
let state = {}在 HMR（热更新）时不会重置，导致状态残留 - 服务端渲染（SSR）失效：Node 环境没有
window，直接报错 - 测试困难：无法 mock 全局变量做单元测试隔离
参数传递（props）看似啰嗦，其实是 React 最可控的通信方式
props 是显式、单向、可追踪的数据流。React DevTools 能清晰看到每个组件接收了什么，ESLint 插件（如 react/prop-types）能提前发现类型错误，TypeScript 更是能精准约束结构。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
关键不是“传得多不多”，而是“是否必要”。深层嵌套组件确实会遇到“prop drilling”，但解决方案应是合理拆分组件或用 useMemo + children 透传，而不是一上来就甩给 context。
- 避免重复解构：父组件别写
<child></child>，而应明确列出所需字段（title,onClick） - 函数传参注意闭包：事件处理器中访问的 state 必须用
useCallback缓存，否则子组件 memo 失效 - 性能优化点：对大型列表，用
React.memo包裹子组件 +useMemo包裹 props 对象，比 context 更细粒度
真实项目里怎么选：看变更频率和影响范围
一句话判断标准：这个值变一次，需要多少组件立刻响应？
如果答案是“整个页面顶部导航、侧边栏、用户头像都得刷新”，那 context 合理；如果是“只有当前弹窗里的确认按钮要变文字”，那必须走 props；如果“这个值只被工具函数用，压根不涉及 UI”，才考虑全局变量。
最容易被忽略的是生命周期耦合：比如把 API 请求实例挂 window，但没处理 token 过期后的自动刷新逻辑，结果请求失败静默吞掉——这种隐式依赖，比多传两个 props 危险得多。
