java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > Spring构造器注入及@Autowired、lombok的@RequiredArgsConstructor异同点

Spring构造器注入及@Autowired、lombok的@RequiredArgsConstructor的异同点说明

作者：花花鱼

本文介绍了Spring框架中构造器注入的实现原理,包括Spring如何找到参数、构造器注入与Autowired的区别,以及为什么Spring官方推荐构造器注入,文章还强调了构造器注入中使用final关键字的好处,并提供了代码示例,帮助读者更好地理解和应用Spring的最佳实践

一、构造器注入：Spring 是如何 “找到参数” 的？

构造器SysUserController：

public SysUserController(SysUserService sysUserService, 
                         ApplicationContext applicationContext, 
                         UserAuthService userAuthService) {
    this.sysUserService = sysUserService;
    this.applicationContext = applicationContext;
    this.userAuthService = userAuthService;
}

Spring 创建 SysUserController Bean 时，找构造器参数的过程分 3 步，核心是「按类型匹配 + 按名称兜底」：

步骤 1：扫描并注册所有 Bean

Spring 启动时，会扫描标注了 @Service/@Component/@Repository 等注解的类，把它们实例化成 Bean，并存入「Spring 容器」（可以理解为一个 “Bean 字典”）：

步骤 2：解析构造器参数，按「类型」匹配 Bean

Spring 发现 SysUserController 有且只有一个有参构造器，会：

遍历构造器的每个参数，先按「参数类型」去容器里找匹配的 Bean：

如果一个类型对应多个 Bean（比如有两个 UserAuthService 实现类），Spring 会再按「参数名称」匹配（比如参数名是 userAuthService，就找名称为 userAuthService 的 Bean）；

把匹配到的 Bean 作为参数，调用构造器，创建 SysUserController 实例。

步骤 3：特殊情况处理（兜底逻辑）

解决方法：用 @Qualifier("bean名称") 标注参数，指定具体要哪个 Bean，比如：

运行

public SysUserController(SysUserService sysUserService, 
                         ApplicationContext applicationContext, 
                         @Qualifier("userAuthServiceImpl") UserAuthService userAuthService) {
    // ...
}

二、构造器注入 vs @Autowired：核心本质差异

先给结论：两者最终都是从 Spring 容器找 Bean，但注入时机、强制约束、安全性完全不同，用表格对比核心差异：

表格

维度构造器注入@Autowired 字段注入
注入时机Bean 实例化时（构造阶段）Bean 实例化后（初始化阶段）
依赖强制性必须找到所有参数 Bean，否则实例化失败可选（默认 required=true，可设 false）
字段不可变性可加 final，实例化后字段不可修改不能加 final，字段可被篡改
空指针风险无（实例化时就注入，字段必不为 null）有（初始化失败时字段为 null）
依赖透明度所有依赖都在构造器参数里，一目了然依赖藏在字段里，需看注解才知道
循环依赖处理无法解决循环依赖（Spring 不支持）可以解决循环依赖（Spring 缓存半成品）
单元测试友好性直接传参创建实例，无需 Spring 容器需 Mock 容器或反射注入，繁琐

关键差异拆解（通俗版）

1. 注入时机：“先有鸡还是先有蛋”

举个例子：如果 SysUserService Bean 不存在：

2. 不可变性：“常量 vs 变量”

3. 循环依赖：“死循环 vs 缓兵之计”

三、为什么 Spring 官方推荐构造器注入？

结合你的代码场景，推荐构造器注入的核心原因：

  1. 提前暴露问题：如果 SysUserService/UserAuthService 没被注册为 Bean，启动时就报错，而不是运行时才发现；
  2. 依赖透明：看构造器就知道 SysUserController 依赖哪些 Bean，不用翻字段注解；
  3. 线程安全：final 字段不可变，Controller 是单例 Bean，多线程调用时不会出问题；
  4. 测试方便：单元测试时，不用启动 Spring 容器，直接 new SysUserController(mockSysUserService, mockContext, mockUserAuthService) 就能创建实例，无需 Mock 注解。

总结：

构造器注入找参数的逻辑：Spring 先扫描注册所有 Bean → 按参数「类型」匹配 Bean → 类型不唯一时按「名称」匹配 → 匹配失败则启动报错；

和 @Autowired 的本质差异：核心是「注入时机」和「依赖强制性」—— 构造器注入是 “实例化时必须有依赖”，@Autowired 是 “实例化后可选注入”；

实战建议：

你的这段构造器注入代码是完全符合 Spring 最佳实践的，这也是为什么我们之前要把 SysUserService 加到构造器里，而不是保留 @Autowired 的原因。

Spring 注入规范的核心细节，我会结合你的代码场景，用 “原理 + 实战” 的方式讲清楚，让你不仅知其然，还知其所以然。

四、final在构造器注入中「不是必须加，但强烈推荐加」

1.final的核心作用（不是为了 Spring，是为了你的代码）

final 修饰字段的含义是：字段一旦赋值，就不能被修改。在构造器注入中加 final 的核心价值和 Spring 注入逻辑无关，而是为了代码的「安全性 + 可读性」：

2. 不加final会怎么样？

如果去掉 final：

private SysUserService sysUserService; // 去掉final
private ApplicationContext applicationContext;
private UserAuthService userAuthService;

public SysUserController(SysUserService sysUserService, ApplicationContext applicationContext, UserAuthService userAuthService) {
    this.sysUserService = sysUserService;
    this.applicationContext = applicationContext;
    this.userAuthService = userAuthService;
}

3. 总结：final的使用原则

表格

场景是否加 final原因
构造器注入的「必需依赖」必须加线程安全 + 依赖不可变 + 编译校验
构造器注入的「可选依赖」不加（实际很少见，可选依赖建议用 @Autowired (required=false)）

你的代码中 SysUserService/ApplicationContext/UserAuthService 都是 Controller 的必需依赖，加 final 是完全符合最佳实践的。

五、为什么你的代码不用@RequiredArgsConstructor？

1. 先搞懂@RequiredArgsConstructor是什么

@RequiredArgsConstructor 是 Lombok 提供的注解，作用是：自动为类中所有 final 字段生成对应的构造器。

@RequiredArgsConstructor // 加这个注解
@RestController
@RequestMapping("/user")
public class SysUserController {
    private final SysUserService sysUserService;
    private final ApplicationContext applicationContext;
    private final UserAuthService userAuthService;

    // 不用手动写构造器，Lombok 会自动生成下面的代码：
    // public SysUserController(SysUserService sysUserService, ApplicationContext applicationContext, UserAuthService userAuthService) {
    //     this.sysUserService = sysUserService;
    //     this.applicationContext = applicationContext;
    //     this.userAuthService = userAuthService;
    // }
}

2. 你的代码不用@RequiredArgsConstructor的核心原因

不是 “不能用”，而是 “手动写构造器更清晰”，具体分两种情况：

3. 手动构造器 vs@RequiredArgsConstructor的对比

维度手动写构造器@RequiredArgsConstructor
代码可读性高（直接看构造器）中（需知道注解作用）
代码量稍多（3 行赋值）极少（1 行注解）
编译期依赖无（纯 Java 语法）需 Lombok 插件 / 依赖
调试友好性高（断点可直接打到构造器）中（需 Lombok 反编译看生成的代码）

4. 补充：如果要用@RequiredArgsConstructor，代码怎么写？

你的代码可以改成这样（完全等价，且更简洁）：

@Slf4j
@RequiredArgsConstructor // 替代手动构造器
@RestController
@RequestMapping("/user")
public class SysUserController {
    private final SysUserService sysUserService;
    private final ApplicationContext applicationContext;
    private final UserAuthService userAuthService;

    // 无需手动写构造器，Lombok 自动生成
    // ... login 方法等逻辑不变
}

总结

关于 final：

关于 @RequiredArgsConstructor：

你的这段代码写法（final 字段 + 手动构造器注入）是 Spring 官方最推荐的 “标准写法”，既保证了代码的安全性，又兼顾了可读性，完全无需调整。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文