ES Modules中循环引用致ReferenceError的根本原因是模块实例化阶段的顶层绑定求值顺序与暂时性死区（TDZ）共同作用；解决关键是延迟访问，将裸值导出改为函数封装（如getFromA()），或利用live binding先占位后填充，必要时重构为三方模块解耦。
ES Modules 中循环引用导致“变量未定义”或 ReferenceError: cannot access 'xxx' before initialization，根本原因不是运行时调用链，而是模块实例化阶段的顶层绑定求值顺序和暂时性死区（TDZ）共同作用的结果。解决的关键不是“绕开引用”，而是延迟对未就绪导出的访问时机。
把导出变成函数调用
这是最直接、最可控的解法。将原本在顶层直接计算并导出的值，改为封装在函数中，等模块完全初始化后再调用。
- 原始写法（危险）：模块 A 直接读取模块 B 导出的变量，而 B 又依赖 A 的顶层变量 —— 实例化时 A 尚未完成初始化，B 就已尝试读取，触发 TDZ 错误
- 改造后：A 不再导出裸值，而是导出一个函数，如
getFromA()；B 在需要时才调用它。此时 A 已执行完毕，内部变量已就绪 - 效果：打破静态依赖闭环，把“声明时求值”转为“调用时求值”，完全避开 TDZ
避免在顶层代码中读取循环依赖的模块变量
模块的顶层语句会按导入顺序同步执行。只要某模块在自己的顶层就去读另一个尚未初始化完成的模块导出项，就极易报错。
- 检查所有
import后的首层语句，尤其是console.log(xxx)、const y = xxx.someProp这类直接取值操作 - 把这类逻辑移到函数体内（如
init()）、事件回调、或异步微任务中（Promise.resolve().then(...)），确保模块生命周期已推进到安全阶段 - 特别注意默认导出对象的属性访问 —— 即使只读
import obj from './b.js'; console.log(obj.flag)，若obj是在 A 模块顶层构造的，而 B 又 import 了 A，同样可能失败
利用模块对象的实时绑定特性做状态协调
ESM 的导入是 live binding（实时绑定），这意味着即使导出模块后续修改了变量值，导入方也能看到更新。这个特性可被用来“先占位、后填充”。
立即学习“Java免费学习笔记（深入）”；
- 在模块 A 中，提前导出一个空对象或带默认值的对象字面量：
export const shared = { ready: false }; - 模块 B 导入该对象，并在其初始化完成后，往里面写入真实数据：
shared.data = realData; shared.ready = true; - 模块 A 在自身初始化末尾再读取
shared.data—— 此时 B 已执行完毕，数据可用 - 注意：仅适用于
let/var声明或对象属性赋值，不适用于const重新赋值
必要时重构依赖关系
如果循环引用逻辑复杂、难以通过封装函数理清，说明设计上可能存在职责耦合。这时应主动拆分：
- 提取公共逻辑到第三个模块 C，让 A 和 B 都只依赖 C，消除 A ↔ B 的直接关联
- 将部分功能从“模块级初始化”下沉为“运行时服务”，比如把状态管理抽成 class 实例，由主模块创建并传入各子模块
- 检查是否误将配置或常量写在业务模块里 —— 把它们单独提为
constants.js或config.js，通常能自然解开多数循环
