大厂倾向构造器注入，因其将依赖检查提前至编译和启动阶段，避免npe空窗期，保障final状态稳定、提升可测性与可维护性，并暴露循环依赖和职责过重等架构问题。
大厂规范倾向构造器注入，核心是把“依赖是否齐全”这个关键问题从运行时提前到编译和启动阶段，同时让代码更可控、更易维护。
依赖必须显式、不可绕过
构造器参数就是类的“生存必需品”。缺一个，编译不通过或 Spring 启动失败，问题当场暴露。字段注入则允许对象先被 new 出来，依赖靠反射后期塞进去——中间存在空窗期，容易在非 Spring 管理的上下文（比如工具类、静态方法调用）里触发 NPE。
- final 字段 + 构造器 = 依赖一旦注入就无法被修改，状态稳定
- 字段注入必须用非 final 字段，依赖可被反射篡改，破坏设计契约
- IDE 和静态分析工具能直接识别构造器参数，一眼看出类到底依赖什么
单元测试不再依赖 Spring 容器
写测试时，不需要加载整个上下文，也不用引入 @SpringBootTest 或 @InjectMocks 这类重量级注解。
- 直接 new UserService(mockRepo, mockLogger) 就完事，干净、快速、隔离性强
- 字段注入的测试往往要靠 ReflectionTestUtils.setField()，既脆弱又违背封装原则
- Mock 对象传入路径清晰，断言逻辑和业务逻辑完全解耦
及早发现架构隐患
构造器注入天然对“类职责”敏感。如果一个类的构造器参数超过 4～5 个，基本说明它承担了太多责任——这是重构信号，不是 bug。
- 循环依赖会在 Spring 启动时立刻报 BeanCurrentlyInCreationException，而不是等某个接口调用才崩
- 字段注入可能借助代理“绕开”校验，掩盖深层耦合，拖到上线后才出问题
- 团队协作中，新人看构造函数就能快速理解模块边界和协作关系
符合现代框架演进方向
Spring 自 4.3 起对单构造器自动装配的支持，Lombok 的 @RequiredArgsConstructor 配合 final 字段，已经让模板代码大幅减少。大厂推行这套规范，不是为了增加开发负担，而是用一点初期习惯成本，换来长期的稳定性、可测性和可维护性。
