✅ 第一种方式（构造器注入）的优势
@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 注入，但这属于临时妥协，应从设计层面重构。