ESM 的 import 声明是否会被提升？这对代码执行顺序有何影响？

机制：链接先于执行

ESM 加载不像传统脚本即时执行，而是经历三阶段。解析阶段只分析语法，构建模块记录。随后实例化阶段根据 import 引用递归加载依赖模块，为每个模块创建环境记录，并将导入绑定连接到对应导出绑定。最后才执行模块顶层代码。由于 import 的绑定在实例化时已经建立，运行时无论在代码哪里写 import，绑定都已存在，表现出“提升”。

这种提升不同于变量初始化：var 声明会被初始化为 undefined，而 import 绑定只是对导出绑定的实时引用，本身没有默认值。真正影响值可用性的是模块的执行顺序：在没有循环依赖的常规加载中，导出模块会先于导入模块执行完毕，因此导出绑定已完成初始化（未赋值的 let 变量会是 undefined）。但若存在循环依赖，某模块可能在导出绑定初始化之前就被访问，此时会触发暂时性死区（TDZ），抛出 ReferenceError。也就是说，提升只保证绑定存在，不保证值可用——值是否可用取决于导出模块的执行进度，而不是 import 的位置。

具体场景：工具模块与调用顺序

考虑一个简单的配置模块 config.js，它导出常量 export const apiUrl = '...'。在入口 app.js 中，我们在文件第一行使用 console.log(apiUrl)，而 import 语句写在最后一行。尽管通常认为 import 应在使用前，由于实例化先执行，输出不会因位置出错。

若把 config.js 改为导出 export let apiUrl; setTimeout(() => { apiUrl = '...' }, 0);，由于 config.js 的顶层代码同步执行完时 apiUrl 仅被声明但尚未被 setTimeout 回调赋值，app.js 顶层立即访问会得到 undefined，不会触发 TDZ。这显示绑定已存在但值尚未就绪。若要获得最终值，需要等待异步回调完成后再访问。若存在循环依赖且导出模块尚未执行到 let apiUrl 的初始化语句，则访问会触发 TDZ。

边界：模块解析失败与 TDZ

提升有一个硬边界：模块必须能成功解析。如果 import 目标路径无效或语法错误，整个模块图不会进入执行阶段，因此任何代码都不会运行。所以不能用条件或动态路径写 import，它是静态的。此外 import 只能出现在顶层，不能嵌套在块或函数中。

若在循环依赖中，实例化顺序可能导致某个绑定在初始化阶段不可用，此时访问会触发 ReferenceError，因为导出模块尚未初始化某些 let 绑定。但这不在题目范围。处理办法是避免在模块顶层读取依赖值，而是通过函数调用等延迟到依赖完成。

容易答错的地方

把 import 提升与 var 提升混淆

一些人认为 import 也会像 var 一样被初始化为 undefined，允许在模块执行早期读取并得到 undefined。实际上 import 绑定是导出绑定的别名，没有自身初始化过程。依赖模块中的代码决定了值何时可读。若导出的是 let x;（未赋值），读取得到 undefined；只有在导出模块尚未执行到该声明（如循环依赖）时，读取才会抛出 ReferenceError。

认为 import 可放在块内

有开发者误以为 import 声明可以像局部变量一样放在 if 或 try 块中。但 ES 模块是静态结构，必须在模块顶层。即使 import 写在块内，解析阶段就会失败。正确做法是用动态 import 来有条件导入。

面试官还会怎么问？

把知识连起来