模块加载器通过状态跟踪与缓存机制解决循环依赖。1. 用“未加载、加载中、已加载”状态机检测循环；2. CommonJS提前暴露模块对象，允许部分加载；3. ES Modules可静态分析依赖图，构建时发现环路；4. 解决策略包括延迟求值、重构共用逻辑、使用getter代理。核心是控制加载时机与引用一致性。
模块加载器中的循环依赖是指两个或多个模块相互引用，导致加载过程陷入无限递归或状态不一致。要实现有效的循环依赖检测与解决机制，核心在于跟踪加载状态、延迟求值以及合理设计模块缓存。
1. 检测循环依赖：记录模块加载状态
在模块开始加载时，标记其状态，通过状态机判断是否出现循环。
模块状态通常包括：- 未加载（UNLOADED）：模块尚未被请求
- 加载中（LOADING）：模块正在执行代码，但未完成导出
- 已加载（LOADED）：模块执行完毕，导出可用
当一个模块被请求时，检查其状态。若处于“加载中”，说明当前调用栈中已有该模块，即发生循环依赖，可抛出警告或采取恢复策略。
2. 使用模块缓存与提前暴露引用
CommonJS 和 ES Modules 的处理方式不同，但都利用了“提前创建模块对象”的思想。
以 CommonJS 为例，require 在模块执行前就创建 module 对象并放入缓存。即使模块还未执行完，再次 require 时仍能返回这个部分初始化的对象。
示例：
// a.js
console.log('a starting');
exports.done = false;
const b = require('./b'); // 加载 b
exports.done = true;
console.log('a done');
// b.js
console.log('b starting');
const a = require('./a'); // 此时 a 已存在缓存，但 done 为 false
console.log('in b, a.done = ', a.done);
exports.done = true;
输出会是：
a starting b starting in b, a.done = false a done
这说明虽然存在循环依赖，但由于 a 的 exports 对象已被提前暴露，程序不会崩溃，只是可能读到未完全初始化的值。
3. 静态分析检测（适用于编译型或预处理器）
对于支持静态分析的模块系统（如 ES Modules），可在解析阶段构建依赖图，检测环路。
步骤如下：
- 解析每个模块的 import 语句，提取依赖关系
- 构建有向图，节点为模块，边为依赖
- 使用深度优先搜索（DFS）检测图中是否存在环
一旦发现环，可在构建时提示开发者，而非运行时报错。这种方式更适合前端打包工具（如 Webpack、Rollup）。
4. 解决策略与最佳实践
检测之后，还需合理应对。常见策略包括：
- 允许部分加载：像 Node.js 那样返回未完成的 exports，程序继续运行，但需开发者注意初始化顺序
- 延迟求值（Lazy Loading）：将 require 放在函数内部，避免启动时立即执行
- 重构依赖结构：将共用逻辑抽离到第三个模块，打破循环
- 使用代理或访问器：通过 getter 获取依赖，确保取值时模块已初始化
基本上就这些。关键是在模块生命周期中精确控制状态和引用时机，结合缓存机制和静态分析，既能检测又能稳妥处理循环依赖。
