这确实是个值得团队深入讨论的规范细节，我结合实际开发经验分享下我的看法：

建议添加守卫的核心场景 #

• 覆盖DI框架的校验盲区：不是所有注入场景都会被DI框架兜底。比如部分框架支持OptionalAttribute这类标记，未注册依赖时会直接注入null；或者手动注册时不小心把依赖映射成了null、用工厂方法返回了null——这些情况DI框架不会主动抛出异常，而参数守卫能在对象初始化的第一时间拦截问题，避免后续业务逻辑出现莫名其妙的空引用。
• 明确类的依赖契约：构造函数的参数本质是在声明「这个类必须依赖该对象才能正常工作」。添加守卫相当于把这个隐含契约变成显式约束，不管调用者是DI框架还是单元测试里手动实例化的代码，都能清晰感知：这个参数绝对不能为null。而且你的守卫方法抛出的ArgumentNullException会通过nameof直接指明参数名，比DI框架泛泛的「无法解析类型X」错误更精准，定位问题更快。
• 单元测试更高效：写单元测试时，我们经常会手动实例化类来验证逻辑，如果不小心传了null，参数守卫能立刻在构造阶段报错，而不是等运行到业务逻辑深处才触发空引用，大大缩短调试时间。

可以考虑省略的特殊情况 #

如果你的依赖确实是可选依赖（比如类在没有该依赖时也能降级运行），那当然不需要加守卫——但这时候建议把参数标记为可空类型（MyDependency?），同时在代码里明确处理null的情况，和DI框架的可选配置保持一致。

总结 #

DI框架的异常抛出能力是有边界的，它无法覆盖所有可能出现null注入的场景。在大多数需要强依赖的业务场景下，给构造函数的DI参数加守卫是更稳妥的选择：既强化了代码的契约性，又能拦截框架照顾不到的null情况，还能让测试和调试更顺畅。

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