不能一键无损升级IIFE为ESM，因二者作用域、依赖声明、执行时机和模块标识存在根本差异；需通过标记、提取、桥接、替换四步渐进迁移，并借助jscodeshift等工具辅助。
目前不存在能“一键无损升级 IIFE 为现代模块”的通用自动化脚本。IIFE 是手动封装的运行时模式，而 ES Module 是静态语法+编译时约束，二者语义层级不同，无法靠正则或 AST 简单映射完成“无损”转换。
为什么不能一键无损升级
关键差异在于：
-
作用域机制不同：IIFE 依赖闭包和全局挂载（如
window.moduleA），ESM 依赖静态export/import和模块图拓扑 - 依赖关系隐式 vs 显式：IIFE 通常靠 script 标签顺序或手动传参注入依赖，ESM 要求所有依赖在源码中静态声明
-
执行时机不可控：IIFE 立即执行，可能含副作用（DOM 操作、全局状态初始化）；ESM 的
import是声明式、惰性求值，需重构执行逻辑 - 无标准模块标识：IIFE 没有统一命名、版本、入口约定，工具无法自动识别“哪个函数是模块主体”“哪些变量该导出”
可行的渐进式迁移路径
不是替换，而是分层解耦：
-
第一步：隔离与标记
用注释或 JSDoc 标记每个 IIFE 的意图，例如：
// @module my-utils<br>// @exports {init, validate}<br>// @requires $, lodash - 第二步：提取纯逻辑 将 IIFE 内部不依赖全局环境、无副作用的函数/类抽成独立文件，用 ESM 重写并导出，保留原名和行为
-
第三步：桥接旧入口
新建一个兼容层（如
iife-bridge.js），用import加载新模块，再把接口挂回window或模拟旧调用方式，供遗留代码继续使用 - 第四步：逐步替换调用方 修改引用 IIFE 的 HTML script 标签，改为加载 ESM 入口，并用构建工具（如 Vite 或 Webpack）处理模块解析和 polyfill
可辅助的工具链组合
虽不能全自动，但以下工具能显著降低人工成本：
-
jscodeshift：编写自定义 codemod，批量将
return { a: ..., b: ... }结构转为export const a = ...; export const b = ...; -
esbuild + plugins：用
onResolve拦截旧路径（如./legacy/utils.js），动态注入 ESM 兼容包装 -
eslint-plugin-import：启用
no-unresolved和no-extraneous-dependencies，强制暴露未声明的隐式依赖，倒逼补全import - Rollup + @rollup/plugin-commonjs：若项目仍混合 CommonJS，可用它作为过渡打包器，统一输出 ESM
特别注意的雷区
跳过这些，90% 的“自动升级”会引入运行时错误：
- 不要试图把
var globalConfig = {...}直接改成export const globalConfig = {...}—— ESM 中顶层变量是模块级，非全局共享 - IIFE 中的
this、arguments、new.target在箭头函数或模块顶层无意义，必须结合上下文重写 - 含
document.write、eval、with或动态Function构造的 IIFE 无法安全转为 ESM，需重写业务逻辑 - jQuery 插件式 IIFE（如
$.fn.myPlugin = function(){...}）应改用 UMD 包装或直接迁移到现代组件方案
