spring boot依赖注入重构应统一使用构造函数注入、拆分职责过重的服务、优先消除循环依赖、配置类用抽象基类收敛重复；禁用字段注入，多构造函数时显式标注@autowired，可配合@requiredargsconstructor减少样板代码。
Spring Boot 中依赖注入的代码重构，核心目标是让依赖关系清晰、可测、可维护，同时规避常见陷阱（比如循环依赖、字段注入反模式）。规范化不是套模板，而是建立几条关键约束和对应实践。
统一使用构造函数注入
这是 Spring 官方推荐且从 4.3 起默认支持的方式。它天然强制依赖声明、配合 final 字段保证不可变性，也便于单元测试时直接 new 对象传入 mock。
- 去掉所有
@Autowired字段注入（@Autowired private XxxService xxx;属于反模式） - 单构造函数时可省略
@Autowired注解，Spring 会自动匹配 - 多个构造函数时，必须显式标注
@Autowired，否则 Spring 不知道选哪个 - 配合 Lombok 的
@RequiredArgsConstructor可大幅减少样板代码，但需确保所有final字段都有对应 Bean 可注入
按职责拆分依赖，避免“大服务”堆积
一个 Service 类依赖七八个其他 Service，往往不是注入方式问题，而是职责过重。重构时优先审视：这些依赖是否都服务于同一业务边界？能否按子域或操作类型横向切分？
- 例如把 “订单创建” 拆为
OrderValidationService、InventoryLockService、PaymentInitService - 拆分后，每个类依赖变少，构造函数更简洁，也更容易复用和单独测试
- 若确实存在多依赖聚合场景（如协调多个下游），可引入专门的
Orchestrator或Facade层，而非让业务 Service 自己承担编排逻辑
处理循环依赖：优先重构，次选 @Lazy
Spring Boot 2.6+ 默认禁止循环依赖，报错明确。此时不应绕过检查，而应判断是否真需双向调用。
- 先尝试提取共用逻辑到第三个独立 Service，打破闭环（如 A 和 B 都需要发通知，就抽出
NotificationService） - 若 A 必须调用 B 的某个方法，但 B 并不真正依赖 A 的实例行为，可考虑将该方法抽象为接口，由 A 实现并传入 B（策略/回调模式）
- 仅当重构成本过高且确认无副作用时，才在构造参数上加
@Lazy，例如：public A(@Lazy B b)—— 这会让 B 延迟到首次调用时才初始化，绕过构造期依赖链
配置类避免重复，用抽象基类 + 子类模板
当多个 @Configuration 类结构雷同（如不同环境注册相似 Bean），复制粘贴会带来维护风险。可用模板方法模式收敛共性。
- 定义一个 不加 @Configuration 的抽象基类，声明抽象方法（如
protected abstract String configPrefix();） - 每个具体配置类继承它，并加上
@Configuration，在@Bean方法中调用抽象方法生成名称或参数 - 这样既保持 Spring 容器识别能力，又消除重复逻辑，新增配置只需加一个子类
