ES6模块静态导入在编译阶段暴露错误，因其路径、导出名和绑定关系在解析时即确定：路径须为字符串字面量，导入名须严格匹配导出声明，且受顶层作用域和无环依赖约束。
ES6 模块的静态导入（import）在编译阶段就能暴露错误，核心原因是它的语法结构是**静态可分析的**——路径、导出名、绑定关系在代码解析时就确定，不依赖运行时逻辑。
导入路径必须是字符串字面量
ES6 规定 import 的模块说明符（module specifier）只能是字符串字面量，不能是变量、表达式或模板字符串（除非是静态模板字面量，如 `./utils.js`）。这使得构建工具或类型检查器在词法/语法分析阶段就能提取所有依赖路径。
- ✅ 合法：
import { foo } from './math.js';、import mod from 'lodash'; - ❌ 非法：
const path = './math.js'; import { foo } from path;（语法错误，直接被解析器拒绝） - ❌ 非法：
import { foo } from `./${name}.js`;（动态模板，不被允许）
导入名称必须与目标模块的导出声明严格匹配
静态分析工具（如 TypeScript、ESLint、Webpack、Vite）在解析 import 语句时，会尝试定位并读取被导入模块的 export 声明。只要模块存在且导出结构可推断，就能在编译/构建前验证绑定是否有效。
- 如果
import { notExist } from './api.js';，而api.js并未导出notExist，TypeScript 会报TS2305，ESLint 的import/named规则也会告警 - 默认导入（
import React from 'react'）要求模块有export default或符合 CommonJS 默认导出约定；缺失时工具可提前报错 - 命名空间导入（
import * as utils from './utils'）虽不校验具体成员，但若./utils不存在或无任何导出，仍会触发“无法解析模块”错误
循环依赖和顶层作用域限制也参与静态检查
ES6 模块的执行顺序和绑定机制是确定的：所有 import 必须出现在顶层作用域，且模块图需形成有向无环图（DAG）。打包器（如 Webpack、Rollup）在构建依赖图时会检测循环引用，并在编译阶段给出警告或错误。
- 例如 A.js
import { x } from './B.js'，B.js 又import { y } from './A.js'，Rollup 默认报WARN: Circular dependency，Webpack 5 在experiments.topLevelAwait: true下仍会标记循环但允许构建；启用严格模式（如mode: 'development'+resolve.fullySpecified: true）可提升检测精度 - 非顶层的
import（如函数内）是语法错误，解析器直接抛ParseError
实际开发中如何利用这一特性
要真正发挥静态导入的检查能力，需配合支持 ES 模块语义的工具链：
- 用 TypeScript 编写：开启
compilerOptions.allowSyntheticDefaultImports和moduleResolution: 'node'，它会在类型检查阶段模拟 Node.js 的模块解析逻辑，提前捕获导出不匹配 - 配置 ESLint 插件
eslint-plugin-import，启用no-unresolved、named、default等规则，对未解析路径和无效命名导入实时提示 - 使用 Vite 或 Webpack 5+：它们默认以 ESM 方式解析模块，在启动 dev server 或运行
build时即执行完整依赖图分析，路径不存在或导出缺失会立即中断并报错
