第二章 循环依赖的后果

这一章我要聊的是循环依赖带来的实际痛苦。你可能觉得，不就是模块A引用了B，B又引用了A嘛，编译能过就行。但真实情况远没那么简单。我在项目里亲眼见过一个循环依赖，最后把整个团队的交付节奏拖慢了两个月。说白了，循环依赖就像代码里的定时炸弹，迟早会爆。

2.1 编译错误

最直接的后果，就是编译过不去。尤其是C/C++这类语言，头文件相互包含，预处理器直接懵圈。

// A.h
#include "B.h"
class A { B* b; };

// B.h
#include "A.h"
class B { A* a; };

我个人习惯的做法是：一旦编译报这个错，先别急着改代码，先画个依赖图看看。你想想看，很多时候头文件循环包含只是表象，真正的设计问题在接口层。

2.2 运行时错误

编译能过，不代表就安全了。有些循环依赖在初始化阶段才会暴露。

我记得有一次，一个Java项目的两个单例相互引用对方，启动时明明没报错，但过几分钟就莫名其妙地空指针。查了两天才发现是循环依赖导致初始化顺序乱掉了。说白了，运行时错误比编译错误更难定位，因为你不知道它什么时候会触发。

2.3 性能问题

循环依赖还可能引发性能灾难。最常见的就是无限递归调用——A调用B，B又调回A，栈直接爆掉。

我曾经接手过一个遗留系统，接口返回特别慢，偶尔直接超时。分析堆栈发现，消息处理模块和缓存模块互相调用，形成了循环。每次请求都要绕十几圈才能出来，CPU跑满，吞吐量直接腰斩。修复后性能提升了4倍。

2.4 维护困难

这个后果最隐蔽，也最致命。循环依赖意味着模块之间的耦合度极高，改一个地方可能牵连一串。

你想想看，一个团队负责模块A，另一个团队负责模块B，二者互相依赖。每次接口变更都要两边同时改，版本对齐、分支合并、回归测试……一个简单需求可能拖一两周。我见过最严重的情况：两个模块的负责人为了谁先改接口吵了三天架。

• 难以测试：模块A依赖B，B又依赖A，没法单独单元测试。
• 难以重构：牵一发动全身，重构成本呈指数增长。
• 难以理解：新人看代码，绕半天搞不清谁依赖谁。

小结