provide/inject 在组合式 API 中直接于 setup() 内使用，支持响应式数据、Symbol 命名、默认值及类型推导，适用于上下文状态传递而非业务字段，需避免响应式丢失、注入时机错乱和命名冲突。

组合式 API 中的 provide/inject 不是“配合”问题，而是直接在 setup() 里用——它天然支持组合式写法，且比 Options API 更清晰、更灵活。关键不是“怎么配”，而是“怎么用得对、用得稳”。

provide：在父组件 setup 里主动抛出依赖

不用再写在 data 或 provide 选项里，直接在 setup() 中调用 provide() 函数即可。它接收两个参数：注入名（推荐用 Symbol 避免冲突）和要提供的值（响应式或普通值都行）。

• 提供响应式数据时，建议用 ref / reactive 包裹后再 provide，否则注入后无法触发更新
• 提供函数时，若需访问当前组件的响应式状态，记得用闭包捕获，或把逻辑封装进 composable
• Symbol 是最佳实践，比如 const ThemeKey = Symbol('theme')，避免字符串硬编码导致拼错或覆盖

inject：在任意子孙 setup 中安全获取依赖

inject() 必须在 setup() 或 setup() 内部调用的函数中使用（不能在普通函数或生命周期钩子外调用）。它返回注入的值，支持默认值和默认工厂函数。

• inject(ThemeKey) —— 没有则返回 undefined
• inject(ThemeKey, 'light') —— 提供默认字符串
• inject(ThemeKey, () => ref('light')) —— 默认值也响应式，适合复杂初始化
• 如果注入名不存在且没设默认值，会警告但不报错；生产环境建议始终设默认值或做存在性判断

跨层级传参 ≠ 无脑穿透：合理分层才真正解耦

provide/inject 容易被当成“全局 props”，但滥用会导致调试困难、依赖隐式化。真正解决跨层级传参，靠的是契约设计 + 责任收敛。

• 只通过 provide/inject 传递上下文型状态：主题、语言、请求配置、表单控制实例等，而非具体业务字段
• 业务数据仍走 props 向下 + emit 向上，保持父子通信显式可追溯
• 可封装成独立的 provideTheme() / useTheme() 组合式函数，在多个组件中复用同一套注入逻辑
• 配合 TypeScript，为 provide 的值定义接口，inject 时自动获得类型推导，大幅降低出错率

常见陷阱与应对

不是所有场景都适合 provide/inject，几个高频翻车点要注意：

• 响应式丢失：provide 普通对象 → inject 后修改不更新 → 改用 reactive({}) 或 ref({})
• 注入时机错乱：子组件 setup 执行早于父组件 provide → 确保 provide 在 setup 开头就调用，不要包裹在异步或条件逻辑里
• 命名污染：多个插件都用字符串 'config' → 一律改用唯一 Symbol，或统一前缀如 Symbol('mylib:config')
• 服务端渲染（SSR）不兼容：inject 在 setup 外调用会失效 → 始终在 setup 内使用，且避免在 onServerPrefetch 中直接 inject