循环依赖概述：从一次线上事故说起

先讲个真事。几年前我接手一个微服务项目，代码跑得好好的，突然有一天部署时全挂了。日志里只有一行：ImportError: cannot import name 'X' from partially initialized module 'Y'。我盯着屏幕愣了十秒——又是循环依赖。

循环依赖说白了就是：模块A引用了模块B，模块B又直接或间接引用了模块A。像一个死循环。你以为只是导入报错？太天真了。它会让你项目启动时就崩溃，CI流水线卡住，甚至线上服务频繁重启却找不到原因。

我个人习惯把循环依赖比作“代码界的先有鸡还是先有蛋”。你想想看，A需要B才能初始化，B需要A才能初始化，那谁先加载？解释器或运行时根本没法决定。

最常见场景：Python import 循环依赖

Python 里这个问题尤其烦人。我见过一个大型后端项目，团队协作半年后，import 关系乱成了蜘蛛网，每次启动都要十几秒，还经常报 ImportError。

举个典型例子：

# module_a.py
from module_b import B

class A:
    def __init__(self):
        self.b = B()

# module_b.py
from module_a import A

class B:
    def __init__(self):
        self.a = A()

这段代码一运行，Python 解释器先尝试加载 module_a，遇到 from module_b import B 就去加载 module_b，结果 module_b 又回头导入 module_a——此时 module_a 还没完全初始化，直接报错。这就是经典的“部分初始化”问题。

JavaScript 里的循环依赖（require / import）

很多人觉得 JavaScript 是动态语言，应该不会出事吧？其实恰恰相反。CommonJS 的 require() 是同步加载，循环依赖时返回的是部分导出的对象，对象还没完全初始化，某些属性会是 undefined。我有个朋友调试了一整天，最后发现是模块之间的循环引用导致某个函数没暴露出去。

// a.js
const b = require('./b');
module.exports = { name: 'A', friend: b.name };

// b.js
const a = require('./a');  // 此时 a 是 { name: 'A' }，但是 friend 属性还不存在
module.exports = { name: 'B', friend: a.friend };  // a.friend -> undefined

ES Modules 也好不到哪去。虽然用了静态分析，但循环依赖依然可能导致 undefined 引用。不同捆绑器（webpack、Rollup）的处理方式还不一样，有些能勉强工作，有些直接抛异常。

其他语言也逃不过

Java 的 import 在编译期就解决了，但类加载器之间的循环依赖（比如两个 jar 包互相引用）依然会引起 NoClassDefFoundError。C++ 的循环 #include 会导致前向声明问题。说白了，只要是模块化系统，就绕不开这个坎。

为什么循环依赖是毒瘤？

不只是报错那么简单。它还会：

• 让代码耦合度爆炸——两个模块强行绑在一起，改一处必须改另一处
• 增加测试难度——你没法单独 mock 其中一个模块
• 降低可读性——新成员看代码时根本理不清依赖关系
• 拖慢启动速度——加载器要反复跳转、等待

下面这张图清晰展示了循环依赖的典型结构。注意箭头方向表示“导入/依赖”方向。

一张表格看透不同语言的处理差异