ASP.NET Core依赖注入是否会为非可选服务注入null引用？

针对.NET 5+ 内置的ASP.NET Core依赖注入容器，在你描述的使用场景下（两个类型均注册到IServiceCollection、仅通过容器解析实例、依赖为非可空构造函数参数），容器绝对不会向构造函数传入null引用，你可以安全移除这些null守卫子句，不会引发预期外的运行时问题。

内置DI的解析校验逻辑 #

内置DI容器在创建服务实例前，会先完成所有依赖的解析校验，逻辑是刚性的：

• 如果构造函数要求的非可空参数对应服务未注册，容器会在解析Logic类型时直接抛出InvalidOperationException，明确提示缺失的服务类型，根本不会进入Logic构造函数的执行流程
• 如果服务注册时使用了自定义实现工厂，且工厂返回null，容器同样会在解析阶段直接抛出异常，不会将null传递给上层服务的构造函数
• 所有校验动作都发生在构造函数执行之前，不存在“校验通过但传入null”的边界情况

你现在写的?? throw new ArgumentNullException(...)逻辑在默认容器场景下属于永远不会触发的死代码。如果真的出现依赖缺失，容器抛出的异常比你自定义的ArgumentNullException信息更全，会直接标注依赖链位置，排查问题效率更高。

仅有的两个可能拿到null的特殊场景 #

只有脱离默认使用规范的场景下，才可能在构造函数中拿到null，这两种场景和DI容器本身的行为无关：

• 你没有通过容器获取Logic实例，而是手动使用new Logic(null)的方式直接创建对象
• 你替换了默认DI容器实现，使用第三方DI框架且修改了默认配置，允许未注册服务返回null（绝大多数第三方DI容器的默认配置也不会给非可空构造参数传null）

可空引用类型场景的注意点 #

你已经启用了C#可空引用类型特性，编译器本身就会对手动传null的行为给出警告，只要团队规范要求全程通过容器解析服务、不手动new注册到容器的类型，完全不需要额外的运行时null检查。
如果你的某个依赖确实是可选的，需要将参数类型声明为可空引用类型（比如OtherLogic?），这种场景下容器在服务未注册时会传入null，才需要补充null判断逻辑。

内容的提问来源于stack exchange，提问作者Lukas-T