依赖注入本身不会直接导致内存泄漏，但服务生命周期管理不当、对象引用设计不合理会埋下隐患：瞬时服务若持有长生命周期对象可能间接泄漏；作用域服务需确保作用域结束时释放资源；单例服务因长期存在，若未清理订阅、缓存等易成泄漏根；事件订阅必须配套注销，推荐IDisposable中取消；静态字段和全局缓存需用WeakReference或MemoryCache避免强引用；容器仅自动处置其创建的对象，手动new或静态成员需自行管理。
依赖注入本身不会直接导致内存泄漏，但若服务生命周期管理不当、对象引用关系设计不合理，就很容易埋下隐患。关键不在于“用不用DI”，而在于“怎么配、怎么用、怎么收”。
明确服务生命周期，匹配实际使用场景
不同生存期的服务在容器中持有方式不同，错误选择会直接引发对象滞留：
- 瞬时（Transient）：每次解析都新建实例，适合无状态、轻量对象；但若它内部持有了长生命周期对象（比如静态缓存或事件源），仍可能间接泄漏
- 作用域（Scoped）：在单个请求或作用域内共享一个实例，WinForm中常对应一次窗体生命周期；务必确保该作用域结束时，其内对象已释放资源（如注销事件、清空缓存）
- 单例（Singleton）：整个应用生命周期存在，最容易成为泄漏“根”——它持有的任何订阅者、回调、缓存项，只要没手动清理，就会一直驻留
订阅事件必须配套注销，尤其在Scoped/Singleton服务中
这是DI项目中最隐蔽也最普遍的泄漏点。当一个短生命周期类（如页面ViewModel）订阅了单例服务（如全局消息总线）的事件，却未在销毁时取消订阅，该ViewModel将被单例强引用，无法回收。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 推荐做法：让订阅方实现
IDisposable，在Dispose()中执行publisher.Event -= handler - 若使用
using或using var声明作用域服务，确保其Dispose()逻辑完整覆盖事件注销 - 避免在构造函数里直接订阅；改用延迟初始化+显式注册/注销流程，便于控制时机
警惕静态字段和全局缓存的隐式强引用
依赖注入容器不管理静态成员。一旦你在某个服务里用了static Dictionary<Guid, object>缓存数据，又没设置过期或清理机制，这些对象就彻底脱离GC管控。
- 静态缓存应配合弱引用（
WeakReference）或带TTL的内存缓存（如MemoryCache） - 避免在单例服务中长期持有UI控件、窗体实例、上下文（
ApplicationContext等）——它们本该随界面销毁 - 检查所有
static集合类，确认是否有自动增长却不收缩的逻辑
善用容器的自动处置机制，但别完全依赖
.NET DI容器会在作用域结束或应用关闭时，对实现了IDisposable的服务调用Dispose()。但这只对“容器创建并持有”的实例生效。
- 确保你的服务类正确实现
IDisposable，且Dispose()中释放所有非托管资源、取消事件、清空内部缓存 - 不要在
Dispose()里做耗时或阻塞操作（如网络等待），否则会拖慢作用域释放 - 注意：容器不会帮你处理你手动
new出来的对象，也不会清理你放进静态字段里的东西
