迁移IIFE到ESM需理清依赖、消除全局污染、适配环境；分步验证，拆解隐式依赖，用export/import替代全局挂载，处理执行时机差异，通过工厂函数控制初始化，并采用混合共存→边界隔离→逐步替换策略。
将旧版IIFE模块迁移到ESM不是简单替换export和import，关键在于理清依赖关系、打破全局污染、适配构建与运行环境。迁移过程需分步验证，避免一次性大改导致运行时错误。
识别并解耦IIFE中的隐式依赖
IIFE常通过闭包或全局变量（如window.utils）共享逻辑，这类隐式耦合在ESM中不被允许。需逐个模块检查：
- 找出所有挂载到全局对象（
window、self、globalThis）的变量或函数 - 识别IIFE内部读取但未声明的外部变量（如直接使用
$却未传入jQuery） - 将每个逻辑单元拆为独立文件，明确其输入（参数）与输出（返回值/导出项）
例如，原IIFE中：(function(global) { global.API = { get() { ... } }; })(this);
应重构为：// api.js<br>export const get = () => { ... };<br>// main.js<br>import { get } from './api.js';
处理循环依赖与执行时机差异
IIFE按书写顺序立即执行，ESM则是静态分析+异步加载+单例缓存。若两个IIFE相互引用对方挂载的全局属性，直接转为ESM会报undefined错误。
立即学习“Java免费学习笔记（深入）”；
- 用
export default或具名导出替代全局赋值，确保导出内容是纯值或函数，而非执行结果 - 对必须初始化的模块（如配置、日志实例），改用工厂函数：
export const createLogger = () => ({ log() { ... } }); - 在入口文件统一调用初始化逻辑，避免模块内自执行
适配浏览器与构建工具
ESM在现代浏览器中可直接通过<script type="module"></script>运行，但路径必须是相对或绝对URL（不支持bare import）；而Webpack/Vite等工具支持自动解析别名和node_modules。
- 浏览器环境：确保所有
import路径带扩展名（如'./utils.js'），避免404 - 构建工具：在
package.json中添加"type": "module"，或使用.mjs后缀明确标识ESM文件 - 兼容旧代码：可通过
import()动态导入过渡，逐步替换require或全局访问
渐进迁移策略与测试要点
不建议全量重写。推荐“混合共存→边界隔离→逐步替换”三阶段：
- 先让ESM模块通过
export暴露接口，IIFE仍存在但不再新增逻辑 - 用
import在新功能中调用ESM，旧逻辑通过一层适配器（如const legacy = await import('./legacy-wrapper.js')）桥接 - 测试重点：全局变量是否消失、模块是否只初始化一次、跨模块状态是否符合预期（如单例类实例是否唯一）
