Vue依赖注入的核心价值是绕过中间组件直连祖先与深层后代，规避属性透传；需用Symbol防命名冲突、限制provide作用域、注入ref保持响应性，并配合Pinia做分层状态管理。
Vue 依赖注入（provide/inject）的核心价值，就是绕过中间组件、直连祖先与深层后代，天然规避属性透传（prop drilling）带来的冗余和耦合。但若使用不当，仍可能引发命名冲突、响应性断裂或隐式依赖，反而削弱解耦效果。关键在于规范注入名、控制作用域、保留响应性链路。
用 Symbol 作注入名，杜绝字符串命名冲突
字符串键（如 'user' 或 'theme'）易在大型项目中重复，尤其多个功能模块各自 provide 同名数据时，后注册的会覆盖前一个，导致不可预期行为。
- 每个注入点定义唯一 Symbol：
const UserContext = Symbol('UserContext') - 祖先组件提供：
provide(UserContext, userRef) - 后代组件注入：
const user = inject(UserContext) - Symbol 是唯一值，跨文件也不会冲突，且支持 TypeScript 类型推导（配合泛型更佳）
只在必要范围调用 provide，限制作用域边界
全局 provide（app.provide）看似方便，实则模糊了数据归属，让任意组件都能 inject，破坏模块边界。真正解耦的前提是“谁提供，谁负责，谁消费”。
- 避免在 main.js 中无差别 provide 业务状态
- 在具体功能容器组件（如
<OrderForm>）的 setup 中调用 provide，仅向其子树暴露所需上下文 - 若需复用，可封装为组合式函数（如
useOrderContext()），内部完成 provide，并导出配套 inject 工具
注入 ref 而非 .value，维持响应性链接
常见错误是 inject('count').value —— 这样拿到的是快照值，上游变更不会同步。inject 返回的是原始 ref，必须保持引用才能响应更新。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
const count = inject(CountKey)（count是 ref，可直接count.value读写） - 若需解构，用
toRefs或reactive包装后再注入，避免破坏响应性 - 对只读需求，用
readonly(count)注入，防止下游意外修改
配合 Pinia 做分层状态管理，不滥用 provide
provide/inject 不是状态管理替代品，而是“局部上下文传递工具”。业务核心状态（如用户登录态、购物车）应交由 Pinia 管理；而 UI 行为上下文（如表单校验开关、折叠面板展开状态）才适合 provide。
- 父组件创建 store 实例：
const formStore = useFormStore() - 通过 provide 注入：
provide('formStore', formStore) - 子组件 inject 后直接调用 store 方法，既享受 devtools 调试，又限定作用域
- 这样既没污染全局，又比纯 provide 更易测试和持久化
