✅ 第一种方式（构造器注入）的优势

@RestController @RequiredArgsConstructor public class PlatformUserTokenController { private final PlatformUserTokenService platformUserTokenService; private final PortalUserContext userContext; private final McpPlatformUserTokenRepository mcpPlatformUserTokenRepository; }

1.不可变性（Immutability）

• 使用final修饰的字段，在对象创建后不能被修改，保证了依赖的不可变性。
• 这有助于编写线程安全的代码，避免因意外重新赋值导致的 bug。

2.依赖明确，便于单元测试

• 构造器注入使得依赖关系在类的外部是显式的，测试时可以直接通过构造器传入 Mock 对象，无需依赖 Spring 容器。
• 例如：

  new PlatformUserTokenController(mockService, mockContext, mockRepository);

• 而字段注入需要借助 Spring 的ReflectionTestUtils或@MockBean，测试代码更复杂且不直观。

3.Null 安全

• 构造器注入强制要求所有依赖在对象实例化时提供，如果 Spring 容器中缺少某个 Bean，启动时会立即失败（抛出BeanCreationException），而不是在运行时才出现NullPointerException。
• 字段注入则可能因为未注入而留下null，导致运行时意外错误。

4.避免循环依赖

• 构造器注入能够提前检测循环依赖（Spring 会抛出BeanCurrentlyInCreationException），而字段注入则可能隐藏循环依赖，直到运行时才暴露，且解决起来更困难。

5.更好的代码可读性和设计

• 构造器注入清晰地表明了该类“必须拥有”的依赖，符合面向对象的设计原则（依赖通过构造函数显式声明）。
• 同时，构造器注入也方便 IDE 自动生成、重构，以及静态代码分析工具检测未使用的依赖。

6.Lombok 简化样板代码

• @RequiredArgsConstructor自动生成包含所有final字段的构造器，省去了手写构造器的繁琐，既简洁又保持了上述所有优势。

❌ 第二种方式（字段注入）的缺陷

@RestController public class PlatformUserTokenController { @Autowired private PlatformUserTokenService platformUserTokenService; // ... }

1.不可测试性

• 测试时只能通过 Spring 容器启动或借助ReflectionTestUtils设置字段，导致测试变得笨重且与 Spring 耦合。

2.NPE 风险

• 字段注入可能因为配置错误导致依赖未被注入，对象仍能被创建（因为无参构造器存在），后续调用时抛出NullPointerException，问题被延迟到运行时。

3.对 Spring 容器强依赖

• 类本身无法脱离 Spring 容器独立使用（例如在普通 Java 程序中），降低了可复用性。

4.循环依赖隐患

• 字段注入允许循环依赖存在（Spring 通过三级缓存解决），但这会掩盖设计问题，增加维护难度。

5.代码可读性差

• 依赖关系散落在字段声明中，不如构造器一目了然。

📌 结论与最佳实践

• 推荐：始终使用构造器注入（方式一），配合 Lombok 的@RequiredArgsConstructor或手动编写构造器。这正是 Spring 官方在文档中强烈建议的方式（参见 Spring 官方文档 中关于“基于构造器的依赖注入”的推荐）。

• 例外场景：在极少数情况下（例如需要注入非必要依赖，或存在循环依赖的遗留代码），才考虑使用字段注入或 Setter 注入，但这属于临时妥协，应从设计层面重构。