用错注入方式？你的代码可能早就埋下隐患

原文来自于：zha-ge.cn/java/125

用错注入方式？你的代码可能早就埋下隐患

有次排障到凌晨两点，我盯着一段"看起来没错"的业务代码发呆：线上偶现 NPE、线程安全问题、单元测试难以编写，改来改去像打地鼠。最后定位到------注入方式选错了。

很多 Spring 项目早期跑得挺顺，越到后期越"玄学"。罪魁祸首之一，就是：字段注入滥用、构造器注入缺失、Setter 注入边界不清。这些问题埋在地底，等到并发、测试、重构来临时一起爆。

误用现形：这三种"常见但危险"的做法

1) 字段注入一把梭（`@Autowired private X x;`）

症状

单测 mock 困难（无法无参构造 + 传依赖）
循环依赖更隐蔽
依赖"隐身"，类的契约不清晰
反射注入在某些容器/代理边界下更脆弱

代码

java 复制代码

@Service
public class OrderService {
    @Autowired private PaymentClient paymentClient;
    @Autowired private DiscountPolicy discountPolicy;
    // ...
}

后果

构造时依赖不完整的风险更高（容器外使用直接 NPE）
重构时看不出该类到底"需要哪些东西"
无法做到不可变（final），状态更容易被不小心改变

2) 可选依赖写死在构造器

症状

构造器越来越长，且某些依赖只在特定分支用到
线上出问题时，替换策略很困难（需要改构造签名）

反例

java 复制代码

public OrderService(PaymentClient pay, DiscountPolicy discount, @Nullable CouponClient coupon) { ... }

后果

设计上把"必需/可选"混在一起，破坏职责划分
可选依赖升级为"强耦合"

3) Setter 注入乱用

症状

Bean 已实例化但未注入依赖前就被调用（生命周期窗口）
多线程场景被意外重设依赖
可变依赖导致行为不可预测

反例

java 复制代码

@Service
public class ReportService {
    private Formatter formatter;
    @Autowired public void setFormatter(Formatter f) { this.formatter = f; }
}

根因剖析：为什么"方式"会影响稳定性？

可见性 & 契约性

构造器注入把依赖显式化（签名即契约），字段注入把依赖藏起来。
"看类名猜依赖"≠"读签名就知道它要什么"。

不可变性

final + 构造器注入 → 依赖只注入一次，线程更安全。
字段/Setter 注入 → 容易被意外覆盖，难以保证只读。

生命周期与测试

构造器注入利于纯 Java 单测（直接 new + 传假实现/Mock）。
字段注入离开容器就"断粮"，测试必须启动 Spring 上下文，重型且慢。

循环依赖定位

构造器注入在循环依赖处"立刻失败"，逼你改设计；
Setter/字段注入可能"先过关、后埋雷"，问题延迟显现。

改法：把注入当成"设计动作"而不是"语法糖"

✅ 首选：构造器注入（配合 `final`）

java 复制代码

@Service
public class OrderService {
    private final PaymentClient paymentClient;
    private final DiscountPolicy discountPolicy;

    public OrderService(PaymentClient paymentClient, DiscountPolicy discountPolicy) {
        this.paymentClient = paymentClient;
        this.discountPolicy = discountPolicy;
    }
}

好处

依赖可见、不可变、易测试
单例 Bean 并发更稳
一旦依赖变更，编译期即刻暴露

♻️ 可选依赖：Setter 注入 / `ObjectProvider` / 策略映射

Setter 注入（用于真正可选、可热切换场景）
ObjectProvider<T>（延迟获取，避免强绑定与循环依赖）
策略映射 （多实现注册到 Map<String,T>，按 key 选策略）

java 复制代码

@Service
public class ReportService {
    private Formatter formatter; // 可换

    @Autowired
    public void setFormatter(@Qualifier("markdown") Formatter f) {
        this.formatter = f;
    }
}

@Service
public class SnapshotService {
    @Autowired private ObjectProvider<ArchiveClient> archiveClientProvider;

    public void archiveIfNeeded(boolean on) {
        archiveClientProvider.ifAvailable(ArchiveClient::archive);
    }
}

🔒 避免字段注入：除非框架层或确实必要

框架/样例/演示可用，业务代码尽量避免。
如果历史包袱太重，逐步从外围新类开始用构造器注入，慢慢"绿化"。

代码异味清单（看到就警觉）

构造器参数超过 5 个 → 可能是上帝类，考虑拆分职责（Facade/子服务）。
@Autowired 在类里满天飞 → 依赖可见性差、难测试。
出现 @Lazy 才能"把循环依赖按下去" → 多半是设计耦合。
注入 List<T> 却在方法里 get(0) → 伪多实现，应该用 @Qualifier 精选一个。
同一依赖既在构造器又在 Setter → 生命周期混乱。

进阶：更优雅的"可配置 + 可替换"

按语义注解区分实现 ：@Primary + @Qualifier("foo")
Profile 切换实现 ：@Profile("dev") / @Profile("prod")
条件装配 ：@ConditionalOnClass/@ConditionalOnProperty（starter 场景）
组合配置 ：@Configuration + @Bean 管理第三方客户端，业务类依然构造器注入接口

常见问答（面试友好）

Q：为什么推荐构造器注入？ A：显式依赖、可测试、可用 final 保证不可变、循环依赖早失败，降低运行期风险。

Q：Setter 注入什么时候用？ A：真正可选 或需要运行时热切换的依赖；或为框架提供"后置配置位"。配合校验：初始化后检查必需依赖是否存在。

Q：字段注入真的不能用吗？ A：不是不能，是不该作为默认选项。业务层优先构造器；字段注入仅用于框架示例/极简样例/遗留兼容。

Q：如何消除循环依赖？ A：重构拆环（引入中介/事件/消息），或改用 ObjectProvider/Setter 注入作延迟；从设计源头减少双向强引用。

从面试走向实战：一套落地准则

默认构造器注入 + final 字段。
第三方客户端用 @Bean 管理，业务类依赖接口而非实现。
可选/多实现用 @Qualifier / ObjectProvider / 策略 Map。
避免字段注入，逐步替换遗留代码。
看到循环依赖，先重构再技巧。
单测先写纯 Java（不启容器），验证依赖契约与可替换性。

写在最后｜一句话记住这篇文

注入方式是"设计决策"，不是"写法口味"。 构造器注入让依赖显式、对象不可变、测试友好；Setter 只给真正可选的依赖；字段注入慎用。今天省下的一行 new，可能是明天省下的一晚通宵。

用错注入方式？你的代码可能早就埋下隐患