vue 3 的 provide/inject 用于解决 prop 钻取问题，适用于主题、表单、折叠面板等跨多层共享上下文的场景；需命名明确、类型收口、边界可控，避免滥用。

Props 层层透传确实容易让组件变得脆弱又难维护，尤其当某个底层组件突然需要一个顶层状态时，中间所有组件都得被动加一层 prop——这就是典型的“属性钻取”（Prop Drilling）。Vue 3 的 provide / inject 正是为此而生：它跳过中间层级，建立稳定的依赖注入关系，让跨多层的通信既清晰又解耦。

什么时候该用 inject 而不是 props？

判断的关键不是“隔了几层”，而是语义是否属于同一上下文。比如：

• 主题色、语言偏好、用户权限等全局或区域级配置
• 表单容器与其内部所有字段组件之间的提交/校验联动
• 可折叠面板组中，子项需要访问父级的展开状态和控制函数
• 编辑器插件系统里，工具栏按钮需调用编辑器核心方法

这些场景中，数据或能力天然属于“作用域边界内共享”，而非某一级组件的私有属性——这时 inject 就比 props 更合理。

如何安全地使用 provide / inject？

避免把 inject 变成“隐式全局变量”，关键在三点：

• 命名明确：用 Symbol 或带前缀的字符串（如 'form:submit'），防止不同模块 key 冲突
• 类型收口：配合 TypeScript，为 provide 的值定义接口，并在 inject 处显式声明类型
• 边界可控：只在真正需要共享的父组件中 provide，不要在 App 根节点无差别注入所有东西

示例：父组件提供表单控制能力，子组件按需 inject，中间布局组件完全无感知。

inject 不是万能的，这些情况别硬套

• 父子直接通信（比如按钮点击通知父弹窗）——props + emits 更直观
• 仅两层以内传递简单值（如 title、size）——props 依然最轻量
• 需要响应式更新但 provide 的值是原始类型且未用 ref 包裹——会导致 inject 后不响应
• 服务端渲染中注入了浏览器专属 API（如 localStorage）——需做环境判断或延迟注入

用对地方，inject 是利器；滥用，反而增加理解成本。

不复杂但容易忽略：provide/inject 本质是父子作用域间的契约，不是绕过设计的捷径。理清数据归属，再选通信方式，代码自然就松耦合、易测试、好演进。