Vue 中 provide 和 inject 适合解决什么问题？

简化版

provide/inject 适合解决跨层级依赖传递问题，例如主题、表单上下文、权限信息和组件库内部上下文。它能避免多层 props 透传，但不适合替代全局状态管理。

详细版

provide 由祖先组件提供值，inject 由后代组件按 key 注入值，中间组件不需要接收和转发 props。

<!-- Parent.vue -->
<script setup>
import { provide, ref } from 'vue'

const theme = ref('dark')
provide('theme', theme)
</script>

<!-- DeepChild.vue -->
<script setup>
import { inject } from 'vue'

const theme = inject('theme')
</script>

它常用于“局部范围内的公共上下文”：表单组件给 FormItem 提供校验能力，Tabs 给 TabPane 提供激活状态，ConfigProvider 给子组件提供主题配置。注意如果提供的是普通值，后代拿到的只是值；如果要保持响应式，应提供 ref、reactive 或包含方法的对象。

完整版教学

一、它解决的是多层 props 传递的噪音

父子组件通信用 props 很清晰，但层级一深就会出现“中间组件只是快递员”的问题。例如 App -> Layout -> Page -> Panel -> Button 五层结构里，只有 Button 需要 theme，中间三层并不关心。如果每层都写 props，维护成本会被链路长度放大。

props 传递:
App -> Layout -> Page -> Panel -> Button
       中间组件都要声明、接收、转发

provide/inject:
App ------------------------------> Button
       中间组件不用知道 theme 存在

假设一个配置对象有 6 个字段，中间经过 4 层组件，props 方案可能带来 24 处声明或转发点。 provide/inject 把这些机械代码收束到提供方和消费方，适合组件树内部的上下文传递。

二、provide 是在祖先处建立上下文

provide(key, value) 的关键是“祖先作用域”。后代会沿组件父链向上查找最近的同名 key，找到就使用。这让它天然适合局部覆盖：外层提供默认主题，某个子树可以覆盖为另一套主题。

<script setup>
import { provide, ref } from 'vue'

const locale = ref('zh-CN')
provide('locale', locale)

function switchLocale(next) {
  locale.value = next
}
</script>

传递内容	是否适合 provide	原因
主题、语言、尺寸	适合	属于组件树上下文
表单注册与校验方法	适合	祖先管理、后代参与
当前登录用户全站状态	谨慎	更像全局状态，Pinia 更清晰
临时按钮文案	不适合	props 更直观

这里的判断标准不是“能不能传”，而是“这个值是否属于一棵组件子树的公共语境”。如果只是父给子传一个明确入参，props 更容易读懂。

三、inject 会读取最近的提供方

inject 的查找规则类似作用域链：先看直接父级有没有提供，再向上找。如果多个祖先提供同一个 key，后代拿到最近的那个。这可以做局部覆盖，也可能造成 key 冲突，所以大型项目更推荐使用 Symbol 作为 key。

// keys.ts
export const themeKey = Symbol('theme')

provide(themeKey, theme)
const theme = inject(themeKey)

App provide theme=dark
└─ AdminLayout provide theme=light
   └─ Button inject theme -> light

这个规则很像 CSS 变量的继承和覆盖。面试回答时把“最近祖先优先”说清楚，能解释为什么组件库可以在局部区域覆盖配置。

四、响应式取决于你提供的值

provide/inject 不会自动把普通对象变成响应式。如果你提供一个普通字符串，后代只是拿到字符串。如果提供 ref 或 reactive，后代拿到的是同一个响应式引用。

const count = ref(0)
provide('count', count)

// 子组件
const count = inject('count')
count.value++

提供方式	后代是否响应更新	说明
`provide('x', 1)`	否	普通值
`provide('x', ref(1))`	是	后代读取 `.value`
`provide('x', reactive(obj))`	是	同一个代理对象
`provide('x', readonly(state))`	是但不可直接改	更利于约束

更稳妥的做法是提供只读状态和修改方法。这样后代能使用上下文，却不会随意改祖先状态。

五、组件库常用它做内部协议

很多 Vue 组件库会用 provide/inject 管理父子组件协作。例如 Form 提供注册字段、校验规则、统一提交能力；FormItem 注入后把自己加入表单。这种场景用 props 很难优雅表达，因为 FormItem 可能隔着插槽、布局组件和动态组件。

Form provide formContext
├─ Row
│  └─ FormItem inject formContext 并注册字段 name
└─ FormItem inject formContext 并注册字段 age

如果一个表单有 20 个字段，父组件可以集中维护校验结果，字段组件只负责声明自己的 name 和规则。这就是“上下文 + 注册机制”的典型组合。

六、它不是状态管理的替代品

provide/inject 最大的问题是依赖关系不如 props 显性。读一个深层组件时，只看到 inject('theme')，不一定立刻知道来源在哪。当状态跨页面、跨模块、需要调试时间线或持久化时，用 Pinia 这类状态管理更合适。

记忆钩子：props 是明线传参，provide/inject 是子树上下文，Pinia 是全局状态中心。

选择时可以按作用域判断：一两个父子层级用 props，跨很多层但仍属于一个组件子树用 provide/inject，跨业务模块共享用 Pinia。这样回答不会把所有通信方式混成一锅粥。

七、常见误区与追问

误区：provide/inject 可以完全替代 props。 props 的显式性更强，普通父子传参仍应优先使用 props。
误区：inject 到的值一定是响应式的。 是否响应式取决于 provide 的值，普通值不会因为 inject 自动响应式。
误区：后代组件随便修改注入状态也没问题。 更推荐 provide readonly(state) 和修改方法，避免状态来源失控。
追问：为什么推荐用 Symbol 做 key？ 字符串 key 容易冲突，Symbol 能降低大型项目和组件库里的命名碰撞风险。
追问：组件库为什么喜欢用 provide/inject？ 因为插槽和深层结构会打断 props 链路，上下文注入更适合父子组件协作协议。
追问：它和 Pinia 怎么选？ 子树局部上下文用 provide/inject，跨页面和跨业务模块共享状态用 Pinia。

八、加强记忆

记这题抓住“三个作用域”：父子清晰传参看 props，子树内部上下文看 provide/inject，全局业务状态看 Pinia。回答时先给场景，再讲最近祖先查找、响应式取决于提供值、推荐 Symbol key，最后补一句不要滥用成隐式全局变量。

简化版

详细版