新加了一个服务接口，项目能编译，一启动就崩，控制台甩出来一段：
System.InvalidOperationException: Unable to resolve service for type 'Shop.Services.IPaymentService' while attempting to activate 'Shop.Controllers.OrderController'.
这句报错的信息量其实比看上去大，关键是两个类型名哪个是哪个。while attempting to activate后面那个OrderController是正在被创建的对象，Unable to resolve service for type后面那个IPaymentService才是找不到的东西。很多人第一反应去翻OrderController，方向就反了——OrderController没有任何问题，它只是站在那里等一个没人注册的接口。
先分清是启动时报还是请求时报
两种时机的排查难度差很多。请求才报，说明容器建起来了，问题藏在某条具体的解析路径上；启动就报，说明开了ValidateOnBuild，容器在Build的时候把整张依赖图走了一遍。
ValidateOnBuild这个选项从ASP.NET Core 3.0起就有，只是一直默认关闭，得手动开：
builder.Host.UseDefaultServiceProvider(options =>
{
options.ValidateOnBuild = true;
options.ValidateScopes = true;
});
变化出在.NET 9预览版7：从那之后HostBuilder在开发环境下会默认把这两个开关打开。所以同一份代码在.NET 8.0、9.0、10.0，三个版本上的表现不一样——老项目升级之后突然启动就报一堆DI错，不是代码坏了，是验证提前了。这条破坏性变更在微软Learn上有专门的页面。
顺手说一下版本时间线，判断问题的时候用得上：.NET 8在2023年11月14日发布，.NET 9在2024年11月12日，.NET 10在2025年11月11日，其中偶数版本是LTS，10.0的支持结束时间是2028年11月14日。
注册遗漏的几种常见形态
1、写成了只注册实现类。这类最容易漏，因为编译能过：
builder.Services.AddScoped<PaymentService>(); // 注册的是实现类 builder.Services.AddScoped<IPaymentService, PaymentService>(); // 这才是构造函数要的
2、泛型接口用了非泛型的注册写法。仓储这类一对多的场景很常见：
builder.Services.AddScoped(typeof(IRepository<>), typeof(Repository<>));
3、用了键控服务但取的时候没带键。键控服务是.NET 8加的，同一接口多个实现时很好用，但注册和取用必须配对：
builder.Services.AddKeyedScoped<IPaymentService, AliPayService>("alipay");
public OrderController([FromKeyedServices("alipay")] IPaymentService pay) { }
注册时带键、构造函数里却不带[FromKeyedServices]，报的同样是Unable to resolve，光看报错很难一眼看出是键的问题。
4、批量扫描注册时条件把类筛掉了。用Scrutor或者自己反射扫程序集，Where里写了类名以Service结尾，结果那个叫PaymentHelper的实现类压根没进去。这类问题在Program.cs里看不出来，得把集合条数打出来核对：
Console.WriteLine(builder.Services.Count);
5、Controller本身没进容器。默认情况下Controller不走DI，构造函数参数由MVC自己处理；要让Controller也参与进来，得加一句AddControllersAsServices()。加了之后，之前没报出来的缺注册会立刻暴露。
6、扩展方法忘了调。AddHttpContextAccessor()、AddMemoryCache()、AddHttpClient()这些不写，注入IHttpContextAccessor、IMemoryCache、IHttpClientFactory时就报Unable to resolve。遇到过一个项目把AddHttpClient写在了只在开发环境执行的分支里，上线才炸。
还有一个隐蔽的：同一个接口注册两次，取的时候是最后一个生效。Add和TryAdd行为不一样，TryAdd遇到已注册的直接跳过，Add则是追加。代码里两个地方各注册一遍，取的不是想要那个，表现就不是报错而是行为异常了。
生命周期错配是另一句报错
如果看到的是这句，方向完全不同：
System.InvalidOperationException: Cannot consume scoped service 'Shop.Data.AppDbContext' from singleton 'Shop.Services.CacheWarmer'.
单例里吃进了Scoped的东西。DbContext默认就是Scoped，把它塞进Singleton的后台任务，跑过一轮之后上下文就废了，要么数据串，要么直接抛。
三种改法：把调用方的生命周期降下来；或者注入IServiceScopeFactory，用到的时候自己开一个scope；或者用IDbContextFactory按需创建上下文。后台服务里用第三种最干净。
ValidateScopes这个开关专门查这个，开发环境默认开着，所以这类问题一般在本地就能撞上，不至于带到线上。
循环依赖
两个服务互相要对方，容器会直接甩一句：
System.InvalidOperationException: A circular dependency was detected for the service of type 'Shop.Services.OrderService'.
内置的容器不支持构造函数的循环注入，也没有懒加载的开关。可行的拆法有三个：把两边共同依赖的那部分抽成第三个服务；用Lazy<T>把其中一边的解析推迟到真正调用的那一刻；或者把其中一边改成方法参数传进来，而不是构造函数注入。
实测下来第二种改动最小，但Lazy<T>把设计上的问题盖住了，用多了回头更难理清依赖关系。
ValidateOnBuild查不到的四类写法
开了验证也不代表万事大吉，下面这几种它看不见：
服务定位器写法，也就是在代码里手动provider.GetRequiredService<T>()取，容器无从知道该校验什么。
方法参数上的[FromServices]与[FromKeyedServices]，验证只走构造函数。
开放泛型注册，AddScoped(typeof(IRepository<>), typeof(Repository<>))这种，闭合类型要到运行时才确定。
工厂委托注册，AddSingleton(provider => new Xxx(...))，委托体里的依赖不在依赖图里。
见过开着ValidateOnBuild还在上线后炸的情况，查下来就是工厂委托里取了一个没注册的服务。
在测试里提前跑一遍
不想等启动，就在单元测试里把容器建起来验证一次：
var services = new ServiceCollection();
// 把 Program.cs 里的注册逻辑跑一遍
services.BuildServiceProvider(new ServiceProviderOptions
{
ValidateOnBuild = true,
ValidateScopes = true
});
这条断言挂上之后，再有人加服务忘了注册，CI阶段就红了，不用等人点开页面。当初接手一个十几万行的老项目，就是靠这条把散落在五处的注册代码理清的。
还有个临时查账的办法，把容器里注册了什么、各自什么生命周期全打出来：
foreach (var d in builder.Services)
Console.WriteLine($"{d.ServiceType.Name} -> {d.ImplementationType?.Name} [{d.Lifetime}]");
数据截至2026年10月。