UWP与WPF依赖注入中AddScoped的效果及适用场景是什么？

你观察到的「AddScoped和AddSingleton表现一致」只是特定场景下的表象，不是生命周期规则在桌面端发生了变化，这个认知并不完全准确。

三个DI生命周期的核心逻辑和运行宿主无关，规则从始至终是统一的：

• AddSingleton：仅在根容器层级保存唯一实例，应用进程运行全程复用，仅在根容器销毁时释放
• AddScoped：同一个IServiceScope（服务作用域）内解析时返回相同实例，作用域被释放时对应实例同步销毁
• AddTransient：每次解析都返回全新实例，实例的释放责任由持有方承担

ASP.NET Core场景下你能直接感受到AddScoped的「请求内单例」效果，本质是框架在后台自动为每个HTTP请求创建了独立的服务作用域，请求结束后自动销毁作用域、清理作用域内的Scoped资源，不需要开发者手动处理。
而WPF、UWP这类桌面应用框架默认没有内置这类自动创建作用域的逻辑，所有默认的服务解析操作都直接走根容器——根容器本身就是一个全局的顶级作用域，这时候解析Scoped服务会被挂载到根作用域下，自然全程复用，看起来和Singleton没有区别。开发环境下开启DI范围校验时，直接从根容器解析Scoped服务还会抛出警告，就是因为这种写法会让Scoped服务变相成为全局单例，很容易引发状态污染、内存泄漏问题。

桌面端没有框架自动划定的请求级作用域，AddScoped的使用完全围绕手动划定的独立工作单元展开，常见适用场景如下：

• 单窗口/单页面生命周期绑定：当你打开独立的弹窗、页面（比如订单编辑页、设置弹窗）时，可以在窗口初始化时手动创建一个服务作用域，把这个窗口依赖的表单状态服务、数据校验服务、业务处理服务注册为Scoped，窗口关闭时直接销毁作用域。整个窗口生命周期内这些服务保持同一个实例，窗口销毁后服务自动释放，既不用手动做状态重置，也不会出现多窗口操作时的状态串扰。典型用法参考：

// 打开订单编辑窗口前创建专属作用域
using var editScope = _rootServiceProvider.CreateScope();
var orderWindow = editScope.ServiceProvider.GetRequiredService<OrderEditWindow>();
orderWindow.ShowDialog();
// 窗口关闭后出using代码块，作用域自动销毁，所有关联Scoped服务同步释放

• 独立任务/批量操作单元：执行单次批量导入、报表生成、数据同步这类独立任务时，可以给整个任务创建专属作用域，把任务依赖的文件解析服务、数据处理组件、EF Core的DbContext注册为Scoped，任务执行完成后直接销毁作用域。这类场景用Scoped可以避免有状态的服务被全局复用，防止出现缓存脏数据、内存持续占用不释放的问题。
• 用户会话级生命周期管理：如果应用有登录登出逻辑，可以在用户登录成功后创建一个会话级作用域，把用户权限服务、用户专属数据缓存、个人配置服务注册为Scoped，用户登出时直接销毁这个作用域，所有和当前用户绑定的服务、缓存数据会被一次性清理，完全避免登出后残留数据被下一个登录用户访问的安全问题。

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