ES6模块类与函数循环依赖：为何C未定义且删除F1()可修复？

为什么C会处于undefined状态？ #

这是**循环依赖触发ES模块暂时性死区（TDZ）**导致的问题，核心在于模块执行顺序和实时绑定机制：

1. 模块执行顺序规则：ES模块明确规定，被导入的模块会优先于导入它的模块执行。你的代码里c.js和main.js形成循环依赖：
   • c.js导入main.js的F1，因此main.js会被优先执行；
   • 但main.js又导入c.js的C，此时c.js还未执行到export class C {}的代码，C的导出绑定仅被创建但未初始化，处于暂时性死区，值为undefined；
   • 当main.js执行到let c = new C()时，自然会因C未初始化而报错。
2. 实时绑定机制：ES模块的导入是实时引用而非值复制，main.js中导入的C始终指向c.js里C的绑定，只有当c.js执行到定义C的代码时，这个绑定才会被赋值。但循环依赖导致main.js先执行，此时C还未完成赋值。

为什么删除F1()调用能修复问题？ #

这是因为未被使用的导入会被模块打包器通过Tree Shaking优化移除：

• 当F2函数中没有调用F1时，c.js里的import { F1 } from "./main.js"属于未使用的导入，打包器会自动移除这段代码；
• 此时c.js不再依赖main.js，浏览器会按照index.htm中script标签的顺序先执行c.js，完成C的定义和导出；
• 后续执行main.js时，导入的C已经是初始化完成的类，new C()就能正常执行。

关于“import确保被导入项已定义”的误解 #

import的作用是建立模块间的依赖关系，确保被导入模块的代码在当前模块执行前被执行，但在循环依赖场景下，这个规则会被打破：被导入模块的代码可能还未执行到导出项的定义，导致导入的绑定处于未初始化的暂时性死区状态。

内容的提问来源于stack exchange，提问作者Jorge Rodriguez