依赖注入中局部覆盖通过作用域隔离、InjectionToken多级Provider、运行时动态重写及Wrapper+Delegate模式实现，确保全局配置与局部定制互不干扰。
在依赖注入（DI）系统中，全局配置通常用于定义默认行为或通用服务实例，而局部覆盖则允许特定模块、组件或作用域内使用定制化的配置，而不影响其他部分。这种能力对构建可复用、可测试、高内聚低耦合的应用至关重要。
通过作用域（Scope）隔离局部配置
多数现代 DI 容器（如 Angular、NestJS、Autofac、Spring）支持作用域机制。全局注册的服务可设为
Singleton
，而局部覆盖则通过创建子容器或作用域容器完成：
在需要定制行为的模块/请求/组件初始化时，新建一个子 Injector 或 Scope
在该作用域内重新
provide
同一 token（如 Class、InjectionToken、Symbol），传入新实例或工厂函数
子作用域内注入该 token 时，优先使用本地提供的实现；父作用域不受影响
例如 NestJS 中可在 Controller 构造器中注入
获取当前模块的子 Injector，再动态 resolve 覆盖后的服务。
利用 InjectionToken + 多级 Provider 策略
使用带唯一标识的
InjectionToken
（而非直接用 Class）是实现灵活覆盖的关键：
全局提供默认实现：
局部覆盖（如测试环境、某业务模块）：
或
支持
multi: true
场景：多个同 token 的 provider 可合并为数组（如拦截器链），局部可 prepend 或替换部分项
运行时动态重写（Runtime Override）
某些场景需在启动后根据条件切换配置（如 A/B 测试、租户隔离）：
将配置封装为可变对象（如
），内部维护一个
Map
或响应式状态（RxJS Subject / Signal）
注入点不直取值，而是订阅或调用 getter 方法，自动响应变更
局部组件可通过方法（如
）临时修改，配合生命周期钩子还原
注意：此方式需谨慎控制副作用范围，避免跨作用域污染。
组合式注入：Wrapper + Delegate 模式
当无法直接替换 provider（如第三方库强依赖某类实例），可用包装器模式实现逻辑覆盖：
全局提供一个代理服务（
），内部持有一个
logger$
Observable 或 getter
局部组件通过 setter 注入自己的 logger 实例，代理服务将其作为当前委托目标
所有日志调用经由代理转发，实际行为由局部设定决定
这种方式不侵入 DI 容器配置，适合渐进式改造或受限环境。
核心在于把“配置”显式建模为可注入、可替换、可组合的抽象，而非硬编码在服务内部。只要 token 唯一、作用域清晰、生命周期可控，局部覆盖就自然可实现。
ModuleRef{ provide: HTTP_CLIENT, useClass: DefaultHttpClient }{ provide: HTTP_CLIENT, useClass: MockHttpClient }{ provide: HTTP_CLIENT, useFactory: () => createCustomClient(...) }ConfigServiceconfig.set(HTTP_TIMEOUT, 5000)DelegatingLogger