识别循环依赖的关键在于理解模块加载顺序与符号绑定时机，它是一种运行时或构建期暴露的结构性隐患；成因明确、风险具体但易被忽略，典型表现包括Python的partially initialized module、JS的Cannot access 'X' before initialization、Spring的dependencies form a cycle。
识别循环依赖的关键，在于理解模块加载时的执行顺序与符号绑定时机。它不是语法错误，而是一种运行时或构建期才暴露的结构性隐患——成因明确，风险具体，但容易被忽略。
成因：模块加载机制决定了“谁先定义、谁先可用”
不同环境处理 import 的方式不同，但核心逻辑一致：模块内容必须执行完才能对外提供导出值。
-
Python：导入时会把模块对象先注册进
sys.modules，再执行模块体；若此时另一个模块也正在导入它，就会读到一个“已注册但未初始化完成”的空壳，引发AttributeError: partially initialized module -
ES6 Modules：静态分析阶段就建立导出绑定，但执行顺序由导入链决定；A → B → A 会导致 B 中对 A 的顶层引用取到
undefined（因为 A 尚未执行完） -
CommonJS：
module.exports是值拷贝，首次require时返回当前已赋值的部分；若 B 在 A 执行中途 require A，可能拿到不完整对象 - Spring Bean：构造器注入时，A 需要 B 实例才能 new 出来，B 又需要 A，容器无法打破这个创建死锁
未定义变量风险：不是报错，而是静默失效
循环依赖最危险的地方，是它不一定立刻崩溃，而是在特定调用路径下产生不可预测的 undefined、null 或空对象。
- 前端中，store 初始化前就被 request 拦截器调用，
useUserStore()返回空实例，token字段为undefined - Python 中，
app.prefs在dialog.py导入时被访问，但此时app.py还没执行到prefs = Prefs()这一行 - Java 中，setter 注入虽能绕过构造器死锁，但如果方法内访问了尚未初始化的字段，仍会触发
NullPointerException
如何快速定位：看警告信号，而非等崩溃
真正有效的识别，靠的是提前捕捉“可疑模式”，而不是等程序挂掉。
- 构建工具警告：Rollup/Vite 明确提示
circular dependency，并附带路径（如src/store/index.js → src/api/request.js → src/store/index.js） - 静态检查提示：Pylint 启用
cyclic-import插件后标出 A→B→A 路径；或出现大量import-error/undefined-variable且集中在顶层代码 - 运行时异常特征：Python 报
partially initialized module；JS 报Cannot access 'X' before initialization；Spring 启动日志出现dependencies form a cycle - 调试线索：在模块顶部加
print("loading X")或console.log("init X")，观察执行顺序是否出现跳变或中断
本质判断标准：是否存在“双向强引用”
只要满足以下任意一条，就构成高风险循环依赖：
- 两个模块在顶层（非函数/类内部）直接相互
import或require - 模块 A 的导出值，被模块 B 的顶层逻辑直接使用；同时模块 B 的导出值，也被模块 A 的顶层逻辑直接使用
- 一个模块在初始化阶段（如
__init__.py、Vue 组件setup()、Spring@PostConstruct）就调用了另一个尚未完成初始化的模块
