provide / inject 可以代替状态管理吗？
先理解原理和示例，再练习完整口述与追问。
回答要点
适合组件树范围内共享依赖。提供 ref / reactive 才能保留相应响应能力，建议把修改入口集中在提供方，必要时暴露 readonly 状态和显式操作。跨页面复杂状态还要考虑调试和生命周期。
原理拆解
provide/inject 解决沿组件树传递依赖的需求，最近的提供者可覆盖上层同 key 值。它适合表单上下文、主题、局部服务等有明确作用域的能力；是否响应式取决于提供的值本身，例如 ref、reactive 或普通快照。状态管理库还提供一致的动作、调试、插件和服务端隔离约定，不能把两者简单视为同一个产品。
示例与推演
一个 Form 提供字段注册函数、校验状态和 submit，内部多层 FormItem 通过 Symbol key 注入使用，可避免层层传 props。为了保护单向修改，可提供 readonly 状态与显式动作函数。另一个 Form 实例可有自己的提供者，字段不应跑到全局共享容器里相互污染。
易错点
注入一个普通数字不会自动随着原变量重赋值更新。服务端作用域不能用模块顶层用户对象；隐藏依赖过多时，也要在组件契约或类型中明确说明。
参考回答可直接练习口述
provide/inject 适合一个组件树内共享表单上下文、主题或服务依赖。要动态更新就提供 ref/reactive，并尽量由提供方持有修改方法，使用方通过只读状态和显式操作协作。它不自动解决跨页面持久化、细粒度调试和状态生命周期，因此复杂共享业务仍可使用 Pinia 等方案。
面试官可能继续问追问与完整解答展开收起
追问
多个同类型表单提供相同 key 时取到哪一个？为什么 Symbol key 有助于大型项目协作？
追问回答
同 key 会优先注入最近祖先提供的值，因此嵌套表单可隔离自己的上下文。Symbol 可以避免不同模块因字符串重名冲突，配合类型化 InjectionKey 还能改善 TS 约束；但仍需处理没有提供者时的默认值或明确错误。