原文来自于：zha-ge.cn/java/115
Lazy能否有效解决循环依赖？答案比你想的复杂
记得有一次项目重构，刚好碰上了两个Bean「互相喜欢」的情境。A 里面要用 B，B 里面又要用 A。典型的循环依赖嘛。Spring 启动直接报错，像极了早恋被班主任逮住。
同事提了个办法：用 @Lazy！可行吗？说真的，当时我信了半截......
故事是这样的
我老老实实在A和B上都加了 @Lazy，美滋滋地以为一切OK。代码大概这样：
java
@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踩过坑？欢迎评论区互相嘲笑、安慰、抱团取暖～