Spring构造方法自动装配中为何需进行空值检查？

这是个特别好的问题！很多刚接触Spring的小伙伴都会疑惑：既然Spring在找不到对应Bean的时候，会直接抛出NoSuchBeanDefinitionException，那为啥还要在构造方法里多写一行Assert.notNull()呢？咱们来拆解几个核心原因：

1. 明确类的契约，做防御性编程 #

你的MyComponent类的构造方法是它的公共接口之一，加上Assert.notNull(myService, "myService must not be null")，相当于用代码明确宣告：这个依赖是绝对必须的，不允许传入null。

想象一下，如果未来有人把这个类从Spring容器中拿出来，手动实例化（比如在测试或者非Spring环境下），这时候Spring的自动装配机制管不到，但断言依然会生效。要是有人不小心写了new MyComponent(null)，断言会立刻抛出IllegalArgumentException，而不是等到后续调用myService的方法时才出现莫名其妙的NullPointerException，排查起来要高效得多。

2. 更早暴露问题，定位更精准 #

Spring的NoSuchBeanDefinitionException确实会在容器初始化阶段抛出，但有一些特殊情况，依赖可能会被注入null，但Spring不会报错：

• 比如你不小心给依赖加了@Nullable注解，或者用了@Autowired(required = false)但其实这个依赖是必填的；
• 又或者自定义了BeanPostProcessor或者FactoryBean，逻辑疏忽导致返回了null。

这时候，Assert.notNull()会在构造方法执行的瞬间就抛出异常，直接把问题扼杀在摇篮里。要是没有这个检查，可能要等到业务逻辑运行到某个节点才会触发NPE，到时候你得翻一堆日志才能定位到是依赖注入的问题。

3. 覆盖极端但实际存在的场景 #

你提到的“极端场景”其实并没有那么极端，在实际开发中偶尔会遇到：

• 测试场景下，手动Mock Bean时不小心传了null；
• 多模块项目中，某个模块的Bean配置被误删，但依赖它的模块没及时发现；
• 使用条件化Bean（比如@Conditional）时，条件判断失误导致Bean没有被创建，但注入逻辑没做相应处理。

这些情况里，Spring不会抛出NoSuchBeanDefinitionException，但依赖会变成null，这时候断言就能起到关键的防护作用。

设计良好的代码中，这些检查重要吗？ #

绝对重要！就算你的代码设计得再严谨，也难免有疏忽，或者未来的代码变更打破原有约定。这种断言是一种低成本的安全网——只需要一行代码，就能避免很多潜在的隐性bug。而且它比注释更可靠：注释可能会随着代码变更过时，但代码里的断言永远是生效的契约，能清晰告诉后续维护者这个依赖的必填性。

顺便提一句：如果你的Spring版本是4.3+，当类只有一个构造方法时，可以省略@Autowired注解，但Assert.notNull()的价值依然存在哦。

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