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)替代普通变量，通过.next()推送新数据 - 避免直接 inject 返回的 Promise —— 它不会触发视图更新，也不支持 .value/.subscribe
统一管理加载与错误状态
仅关注 data 不够，用户需要知道“正在加载”、“加载失败”、“无数据”等场景。建议将 loading、error、data 封装为一个响应式对象一并 provide。
- Vue：提供
{ data: ref(null), loading: ref(false), error: ref(null) }对象 - Angular：提供包含
data$: Observable<T>、loading$: Observable<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 的不是“数据”，而是“响应式数据源”。只要源头可响应、可订阅、可更新，下游自然联动。不复杂但容易忽略。
