es modules支持循环依赖，通过静态分析构建依赖图并用实时绑定机制处理，但变量可能未初始化就被访问导致报错。
ES Modules 本身不会因为循环依赖而“加载失败”，它用静态分析+实时绑定机制绕过了传统加载阻塞，但代价是变量可能未初始化就访问——报错位置常远离根源。
加载阶段：静态解析不报错，只记录依赖图
ESM 在编译期就解析所有 import 语句，构建模块依赖图。遇到 A → B → A 这类环，它不会中断构建，而是标记为“已知循环”，继续往下走。这和 CommonJS 运行时 require 的递归调用不同，ESM 不会卡在加载环节。
- 所有模块都会被加载进内存，只是不一定执行完
- import 声明本身不触发执行，只建立绑定关系
- 浏览器或 Node.js 会按拓扑顺序尝试执行，但环内顺序无法严格保证
执行阶段：绑定存在，但值可能还是 undefined
ESM 使用“实时绑定（live binding）”，导出的变量是引用而非拷贝。但若模块 A 尚未执行到赋值语句，模块 B 却已通过 import 访问该变量，就会读到 undefined（或初始值，如 let 声明未赋值时的状态）。
- export let x = 'x' 在模块顶部声明，但赋值发生在执行阶段
- 如果 B 在 A 执行完前就 console.log(x)，输出就是 undefined
- 函数声明（function fn() {}）会被提升，但 const/let 不会，所以更易出问题
常见错误表现与定位方法
典型报错不是“循环依赖”，而是 ReferenceError: Cannot access 'xxx' before initialization 或读到 undefined 后引发后续逻辑崩溃。这类错误往往出现在模块初始化函数、默认导出对象属性访问、或副作用调用中。
- 用 circular-dependency-plugin（Webpack）或 madge（命令行）扫描项目，可视化依赖环
- 在疑似模块顶部加 console.log('start module X')，观察实际执行顺序
- 把关键导出改为函数（如 export const getValue = () => value），延迟取值可避开初始化时机问题
真正可靠的解法不是绕开，而是拆解
靠运行时行为“凑合能跑”不可靠。稳定方案是打破环的结构，让依赖变成单向。
- 抽离共享逻辑到第三个模块 C，A 和 B 都只依赖 C
- 把强依赖改成弱依赖：用函数参数传入、回调注入、或事件通信代替直接 import
- 对配置类、常量类模块，确保它们无副作用、纯声明，放在环外作为基础层
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
