不建议在业务组件中滥用 inject，因其破坏数据流向显式性、绕过类型校验、阻碍单元测试、模糊责任边界；应优先使用 props/emits 或状态管理器。
不建议在业务组件中滥用 inject，核心原因在于它会悄悄破坏组件的可读性、可测性和可追踪性——表面是“省事”，实际埋下长期维护隐患。
破坏明确的数据流向
Vue 推崇“自上而下、显式传递”的数据流。props 和 emits 让父子通信一目了然：谁提供、谁消费、在哪调用，IDE 跳转和调试都直接可查。而 inject 一旦被多层嵌套使用，数据来源就变成“向上盲找”：某个子组件用了 inject('api')，你得逐层翻父级、祖级甚至更上层的 provide 声明，中间还可能被中间组件无意覆盖或拦截。业务迭代中，没人能快速回答：“这个 api 到底是谁提供的？有没有被改过？”
绕过类型与校验约束
在 TypeScript 项目中，props 可通过接口严格定义类型、必填/可选、默认值；inject 却常以字符串 key（如 inject('user')）形式使用，既无类型推导，也无编译时检查。稍不留神拼错 key，运行时才报 undefined；漏写默认值或兜底逻辑，组件直接白屏。即便用 Symbol 或泛型增强（inject<user>(USER_SYMBOL)</user>），也需要额外维护符号定义和注入契约，成本远高于直接 props 透传一个类型清晰的对象。
阻碍单元测试与独立复用
一个依赖 inject 的组件，无法脱离 provide 环境单独实例化。写单元测试时，你必须手动构造完整祖先链、模拟 provide 数据，或者用 mount 配置 shallow + stubs，复杂度陡增。相比之下，props 驱动的组件只需传入 mock 数据就能跑通逻辑。同样，把这类组件抽成公共库或迁移到新项目时，使用者必须同步理解并配置配套的 provide 结构，违背“开箱即用”原则。
模糊责任边界，放大耦合风险
当多个业务组件都 inject 同一个 key（比如 'theme' 或 'config'），它们看似解耦，实则隐式强依赖同一份上下文。某天产品要求 A 页面用深色主题、B 页面保持浅色——你不得不拆分 provide 层级、加条件判断，甚至引入作用域限定逻辑。而若最初用 props 逐层传 theme，修改只发生在 A 页面父组件，影响范围清晰可控。inject 把“松耦合”变成了“隐式紧耦合”，只是耦合点从代码里挪到了运行时依赖树中。
它不是不能用，而是要像用全局变量一样谨慎：只在真正需要穿透多层、且该能力由稳定抽象（如 UI 组件库的 ThemeProvider、FormContext）统一管控时才启用。业务组件之间，优先选 props、事件、状态管理器——清晰胜于方便，显式优于隐式。
