模块加载器分四步：解析→获取→实例化→评估；静态import编译期分析依赖，import()运行时按需加载；require与import模型不同不可混用；简易加载器易忽略状态管理、缓存及循环依赖处理。
模块加载器不是“加载完就执行”，而是分四步走
浏览器或 node.js 的模块加载器实际执行的是一个严格分阶段的过程：解析（Parsing）→ 获取（Fetching）→ 实例化（Instantiation）→ 评估（Evaluation）。很多人以为 import 一出现就去发请求、跑代码，其实不然——静态分析阶段就已构建好整个依赖图，所有模块路径被转成完整 URL 或文件路径，但此时连第一行 js 都没执行。
- 解析阶段不运行代码，只扫描
import语句，确定谁依赖谁；这正是 ESM 支持 tree-shaking 的前提 - 获取阶段才真正发起网络请求（浏览器）或读文件（node.js），且是并发但有依赖顺序保证的
- 实例化阶段为每个模块创建“导出绑定”（binding），即使循环依赖也能让
export let x存在（值可能还是undefined） - 评估（即执行模块体）严格按拓扑排序，叶子模块先执行，入口模块最后执行
动态 import() 和静态 import 的本质区别在哪
关键不在语法，而在**时机与控制权**：静态 import 是编译期决定的，必须是字符串字面量，打包工具能提前分析并分割代码；import() 是运行时函数调用，返回 promise，参数可以是模板字符串（如 `./pages/${page}.js`），但不能是任意变量（否则 webpack/vite 无法预知要打包哪些文件）。
- 静态
import被提升到模块顶部，且只能出现在顶层作用域；违反规则会直接报ParseError -
import()可以写在if、try、事件回调里，适合权限控制、A/B 测试、错误降级等场景 - 重复调用同一路径的
import('./utils.js')，后续都命中缓存 Promise，不会重新 fetch - 注意：浏览器中
import()加载失败会 reject，必须用catch或try/catch捕获，否则触发 unhandledrejection
为什么 require 和 import 不能混着用
因为它们属于完全不同的加载模型：CommonJS 的 require() 是同步、运行时、可拼接路径的；ESM 的 import 是异步、编译时、静态路径的。Node.js 虽然支持互操作，但行为有隐式转换——比如 import foo from 'lodash' 实际拿到的是 lodash.default，而 require('lodash') 拿到的是整个对象。
- 在 ESM 文件里写
require('./a.js')会直接报ReferenceError: require is not defined - 在 CommonJS 文件里用
import()是允许的，但返回 Promise，不能直接赋值给module.exports - Webpack 中
import()会自动转成__webpack_require__.e()，而require.ensure已废弃，别再用 - 真实项目中，若需兼容老库（如 jquery 插件），要用
shim配置或imports-loader注入全局变量
自己写个简易模块加载器，最容易漏掉什么
不是“怎么插入 标签”，而是**状态管理和缓存粒度**。用 document.createElement('script') 加载只是第一步，如果没做模块状态机（如 LOADING / READY / ERROR），多个地方同时 loadScript('a.js') 就会重复加载、重复执行。
立即学习“Java免费学习笔记（深入）”；
- 必须维护一个模块注册表（如
const cache = new map()），key 是模块 URL，value 是 Promise 或导出对象 - 脚本加载完成时，不能直接
eval，得用new function('exports', 'require', 'module', code)模拟模块作用域 - IE 下监听
onreadystatechange比onload更可靠，但现代项目基本不用考虑 - 最常被忽略的一点：没有处理循环依赖的“导出绑定提前暴露”。真实加载器（如 RequireJS）会在实例化阶段就创建空模块对象，让
import { a } from './b'不报错，哪怕b.js还没执行完
模块加载器的复杂性不在“怎么加”，而在“怎么确保每次加载都得到相同实例、相同执行顺序、相同导出引用”。哪怕只用 import()，也要意识到它背后是 Promise 链 + 模块图 + 缓存策略三者协同的结果。