字段注入与继承：构造器注入字段设为final的其他利弊探讨

在依赖注入场景里，构造器注入是主流推荐方案，不少开发者坚持所有注入字段都用final修饰——除了大家熟知的防止意外赋值的作用，这种做法还有其他值得关注的优缺点：

优点 #

• 明确依赖契约：final字段必须在构造器中完成初始化，类的核心依赖一目了然，让类的API边界更清晰，别人看代码时不用猜测哪些是必要依赖。
• 消除未初始化风险：确保对象实例化后所有依赖都已就绪，不会出现调用方法时依赖为null的空指针异常，多线程环境下安全性更高。
• 简化单元测试：依赖必须通过构造器传入，写测试时只能用构造器注入Mock对象，避免了反射修改私有字段的麻烦，测试代码更规范易维护。
• 天然线程安全：不可变对象无需考虑并发修改问题，减少了并发场景下的bug概率，尤其适合高并发系统。

缺点 #

• 子类冗余代码堆积：如示例所示，父类的final私有字段会强制子类显式定义构造器传递依赖，哪怕子类根本不需要这个依赖。多层继承场景下，重复的构造器代码会让维护成本飙升。
• 扩展灵活性受限：如果后续需要给类添加可选依赖，final字段会限制修改——要么改动构造器（破坏现有API兼容性），要么切换到其他注入方式，违背开闭原则。
• 反射场景兼容问题：虽然主流DI框架（如Spring）支持构造器注入，但某些老旧框架或特殊反射场景下，修改final字段可能引发异常，需要额外配置才能适配。
• 调试复杂度提升：若类有多个final依赖，构造器参数列表会很长，调试时追踪依赖传递路径会更繁琐，多层继承的类尤其明显。

示例代码 #

public class A {
  private final Foo foo;

  public A(Foo foo) {
    this.foo = foo;
  }
}

public class B extends A {
  @Autowired
  public B(Foo foo) {
    super(foo);
  }
}

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