面经策

SpringBoot（Spring）中为什么不推荐使用 @Autowired ？ ​

  • 标签：Spring Boot、后端、Spring

🏛 业务架构师 ​

不推荐字段注入的 @Autowired（IDE 也会警告），原因都指向工程质量和业务演进：

  1. 掩盖依赖膨胀：字段注入可以无声地加到十几个——类职责失控没有任何摩擦信号。构造器注入天然设卡：参数超过 5 个，写的人自己都会反思"这个类是不是干太多了"，这正是重构的触发点；
  2. 隐藏依赖关系：字段注入的依赖不看不实现不知道；构造器把"这个类依赖什么"声明在签名上，契约显式，review 和心智负担都轻；
  3. 可测试性差：字段注入靠容器反射填值，脱离 Spring 就没法构造对象；构造器注入下单测直接 new Svc(mockA, mockB)——测试不依赖容器，速度和可维护性质变；
  4. 不能 final：字段注入的依赖可变、不可声明不可变，线程安全性弱一档；
  5. 循环依赖被掩盖：字段注入能被三级缓存救活，构造器注入直接报错——后者是帮你在编码期发现设计问题。

正确姿势：

java
@Service
public class OrderService {
    private final PaymentGateway gateway;   // final + 构造器
    public OrderService(PaymentGateway gateway) { this.gateway = gateway; }
}

单构造器 Spring 4.3+ 自动注入，Lombok 的 @RequiredArgsConstructor 进一步省样板。一句话：这不是语法之争，是"依赖要不要显式、职责要不要设卡"的工程纪律。

🏗 系统架构师 ​

四条工程理由（Spring 官方同此立场）：

  1. 隐藏依赖：字段注入把依赖藏在类内部；构造器一眼看清协作对象——依赖超过 5 个就该重构，字段注入让「上帝类」无痛生长；
  2. 破坏不可变性：字段注入的依赖无法声明 final，对象可变性是并发隐患源头；
  3. 可测试性差：脱离容器只能靠反射注入；构造器注入直接 new 加替身完事；
  4. 与循环依赖的关系：字段注入让循环依赖能「跑起来」（三级缓存救场），构造器注入直接启动失败——早失败优于晚故障。

正确姿势：构造器注入（4.3 起单构造器免注解）加 Lombok @RequiredArgsConstructor 或 record，依赖全部 final。@Autowired 只保留给个别 setter 注入的可选依赖。

团队落地：IDE 把字段注入提示调到 error 级、ArchUnit 规则进 CI 拦截——规范不进流水线就是空话。

💻 全栈开发专家 ​

"不推荐"专指字段注入（注解打在成员变量上），Spring 官方推荐构造器注入。理由五条，全是工程实战角度：

  1. 无法 final：字段注入靠反射 set，字段不能声明 final；构造器注入天然不可变，并发安全
  2. 依赖被隐藏：构造器签名一眼看清"这个类需要什么"；字段注入的类可以悄悄膨胀几十个依赖，上帝类无人察觉
  3. 可测试性差：脱离容器没法构建对象，单测只能依赖容器或反射注入 mock；构造器注入直接 new Service(mockA, mockB)
  4. 掩盖设计问题：构造器注入下循环依赖立刻暴露（这是好事），字段注入靠三级缓存"糊弄"过去；Boot 2.6+ 默认禁循环依赖也是这个态度
  5. 与容器强耦合，复用到非 Spring 环境（SDK 库）就废

团队标准写法：

java
@Service
@RequiredArgsConstructor        // Lombok 生成构造器
public class OrderService {
    private final StockClient stockClient;
    private final OrderMapper orderMapper;
}

注意 @Autowired 本身没原罪——标在构造器/Setter 上没问题，被批判的是"打字段上"这种用法，IDEA 的黄色警告也是同样理由。