Lazy能否有效解决循环依赖？答案比你想的复杂

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

Lazy能否有效解决循环依赖？答案比你想的复杂

记得有一次项目重构，刚好碰上了两个Bean「互相喜欢」的情境。A 里面要用 B，B 里面又要用 A。典型的循环依赖嘛。Spring 启动直接报错，像极了早恋被班主任逮住。

同事提了个办法：用 @Lazy！可行吗？说真的，当时我信了半截......

---

故事是这样的

我老老实实在A和B上都加了 @Lazy，美滋滋地以为一切OK。代码大概这样：

@Component
public class A {
    @Autowired
    @Lazy
    private B b;
    // ...
}

B里面也来一手，但是看到这里你可能都能猜到，心态飘了。

---

踩坑瞬间

真相只有一个：不是所有循环依赖，@Lazy 都能救场！

现场踩雷清单：

• 场景判断题：如果你用的是单例，Spring 的确能"缓一口气"；多例（prototype）？直接GG。
• @Lazy 不是万能钥匙。构造器注入碰循环依赖，@Lazy 小手一抖表示爱莫能助------除非你换回 setter 或 field 注入。
• 有些框架（比如MyBatis-Plus）暗中搞"花式注入"，你以为加了@Lazy，实际根本没进Spring默认处理流程！

我在开发环境跑了一下，结果：

	构造器注入	setter/field注入
单例	GG	可以试试
多例	全晕	全晕

最后，循环依赖的故事变成了：@Lazy 不是灵丹妙药，是保姆级平衡剂，有用时能帮买瓶可乐，没用的时候就像一瓶开了盖的雪碧------气全没了。

---

探索过的骚操作

当然，身为不服输的程序猿，怎么可能直接认栽！

• 把构造器注入都换成setter注入，项目里一堆代码火山爆发似的改......
• 用ApplicationContextAware手搓IoC，各种 getBean，堪称反直觉大合集。
• 重构业务逻辑，干脆避免"你中有我、我中有你"------这才是治本之道！

非要顶着循环依赖么？那就认认真真查到底是不是业务设计就不行。

---

经验启示

聊到最后，如果你正撸着咖啡想着用@Lazy优雅化解循环依赖，请务必牢记：

• 先看注入方式，再用@Lazy，别让自己踩进构造器注入的深坑；
• 能重构就重构，循环依赖本来就不优雅；
• 碰到多例Bean循环依赖，甭想了，赶紧调整设计；

总归一句话：@Lazy 能解一时之急，解不了结构性的矛盾。写代码嘛，咱既要有巧劲，也要有狠劲。

---

吹到这儿，故事就到这。你有没有用@Lazy踩过坑？欢迎评论区互相嘲笑、安慰、抱团取暖～