inject传递的必须是响应式数据源而非原始异步结果，需用ref/behaviorsubject封装data、loading、error状态，统一管理请求生命周期、避免重复调用，并在组件销毁时清理订阅。

在使用 Inject（如 Vue 的 provide/inject 或 Angular 的依赖注入）时，异步接口数据本身不直接“响应式”，关键在于如何把异步结果包装成响应式状态，并确保消费者能自动更新。

用响应式容器包裹异步结果

Inject 传递的值必须是响应式引用（如 Vue 的 ref、reactive，或 Angular 的 BehaviorSubject），不能直接传 Promise 或原始对象。

• Vue 示例：在 provide 端用 ref(null) 初始化，请求完成后赋值
• Angular 示例：用 BehaviorSubject<data null>(null)</data> 替代普通变量，通过 .next() 推送新数据
• 避免直接 inject 返回的 Promise —— 它不会触发视图更新，也不支持 .value/.subscribe

统一管理加载与错误状态

仅关注 data 不够，用户需要知道“正在加载”、“加载失败”、“无数据”等场景。建议将 loading、error、data 封装为一个响应式对象一并 provide。

• Vue：提供 { data: ref(null), loading: ref(false), error: ref(null) } 对象
• Angular：提供包含 data$: Observable<t></t>、loading$: Observable<boolean></boolean> 的 service
• 消费者可基于这些状态条件渲染 skeleton、error tip 或真实内容

避免重复请求与状态污染

多个组件 inject 同一服务时，若各自触发接口，易造成冗余请求或状态错乱。应在 provide 端做单例 + 缓存控制。

• 首次调用时发起请求，后续直接返回已解析的响应式数据
• 可加简单缓存逻辑：检查 data.value !== null && !loading.value 再决定是否 fetch
• 如需强制刷新，暴露一个 refresh() 方法，内部重置 loading 并重新 fetch

响应式订阅要记得清理（尤其 Angular）

Inject 出来的 Observable 或 watch/Effect 若未手动销毁，可能引发内存泄漏或旧回调执行。

• Vue：在 setup 中使用 onBeforeUnmount 清理副作用（如取消 pending 请求）
• Angular：在 ngOnDestroy 中 unsubscribe() 或用 takeUntilDestroyed()（v16+）
• 不要在 inject 函数里直接 subscribe，应由消费者按生命周期管理

核心就一条：inject 的不是“数据”，而是“响应式数据源”。只要源头可响应、可订阅、可更新，下游自然联动。不复杂但容易忽略。