.NET MAUI中AddTransient<>的工作机制与GC自动回收问题问询

一、builder.Services.AddTransient<>的核心工作机制 #

AddTransient是.NET依赖注入容器的瞬态服务注册方式，核心逻辑非常直接：

• 每次通过ServiceProvider.GetService<T>()（或构造函数注入）获取服务实例时，容器都会创建一个全新的实例，不会对该实例做任何持久化持有。
• 容器完成实例创建与注入后，就不再干预这个对象的生命周期——后续内存管理完全交给.NET垃圾回收器（GC），只要没有其他代码持有该对象的强引用，GC就会在合适时机回收它。
• 和单例服务（AddSingleton）的区别：单例是容器仅创建一次实例并全程保留引用，每次获取都是同一个；而瞬态服务没有容器层面的引用绑定，理论上用完即可被回收。

二、为什么Demo中的瞬态对象没被GC回收？ #

你遇到的DetailPage和DetailPageViewModel驻留内存的情况，和AddTransient本身的机制无关，大概率是以下原因导致：

• 导航栈或页面生命周期的引用持有：MAUI导航栈默认保留页面历史记录，即使从DetailPage返回，页面实例可能仍被导航栈内部结构持有（比如缓存逻辑）。另外，如果页面的OnDisappearing方法未清理绑定上下文或资源，也会导致引用残留。
• 未解除的事件订阅：如果DetailPageViewModel订阅了全局事件、页面控件事件或单例服务事件，且未在页面销毁时取消订阅，这些强引用会把ViewModel和页面“挂”在内存中，GC无法回收。
• 绑定上下文的残留引用：如果页面的BindingContext未在页面消失时置为null，或某些单例对象（比如MainPageViewModel）间接持有DetailViewModel的引用，也会阻止GC回收。
• Debug模式的调试干扰：Debug模式下，Rider的内存调试工具、调试器本身会持有对象引用以支持断点、内存检查等功能，这会延迟甚至阻止GC回收。建议切换到Release模式测试，或手动调用GC.Collect() + GC.WaitForPendingFinalizers()后再检查内存。
• Demo代码的特定实现：该workshop Demo可能存在为演示简化的逻辑，比如未处理页面销毁清理，或某些绑定、命令设置导致了引用泄漏。

内容的提问来源于stack exchange，提问作者Tim