旧版浏览器需模块polyfill而非仅babel转译；核心是用iife+运行时（如systemjs或2kb自建）模拟esm加载、解析与缓存，真正接管模块生命周期。
在不支持原生 ES 模块（import/export）的旧版浏览器（如 IE11、Android 4.4 WebView、旧版 Safari）中，直接运行模块化代码会报语法错误。要让模块语法“可用”，不能靠 Babel 转译语法（它不处理模块加载），而需配合模块加载器与运行时补丁——即真正的 模块 Polyfill 方案。
核心思路：用 IIFE + 运行时注册模拟模块系统
原生模块依赖静态解析和顶层作用域隔离，Legacy 环境无法提供。Polyfill 的本质是：把 import 和 export 编译为可执行的函数调用，再通过一个轻量运行时管理模块定义、依赖解析与缓存。关键不在“转语法”，而在“建系统”。
- 源码仍写标准 ES 模块语法（
import { foo } from './utils.js'） - 构建时用工具（如
esbuild --format=iife或rollup --format=iife）将所有模块打包为单个 IIFE，并注入模块注册逻辑 - 运行时提供
__require、__define等基础函数，模拟 CommonJS/ESM 行为 - 入口模块被自动执行，触发依赖链加载（注意：是同步加载，无动态
import()支持）
推荐方案：SystemJS + 配合构建转换
SystemJS 是目前最成熟、专为 Legacy 模块兼容设计的加载器，支持 AMD、CommonJS、ESM 甚至全局变量模块。它不依赖构建，但与构建结合效果更佳：
- 保留原始
.mjs文件结构，无需重写导入路径 - 通过
<script type="systemjs-module" src="main.mjs"></script>启动，自动解析import - 配合
systemjs-builder或现代打包器（如 esbuild 插件esbuild-plugin-systemjs）可预编译为单文件，避免运行时解析开销 - 对
import.meta.url、import.meta.resolve等有有限 polyfill（需额外配置）
极简替代：自建 2KB 运行时（适合小项目）
若只需支持静态导入导出（无循环依赖、无动态 import），可手写精简模块运行时：
- 所有模块输出为
__define('path', function(require, exports, module) { ... }) - 入口脚本调用
__require('./main')启动 - 运行时维护
modules对象缓存已执行模块，cache存 exports，pending处理简单依赖顺序 - 路径解析仅支持相对路径（
./、../），不支持裸导入（lodash）——需提前映射或内联
这类运行时可在 2KB 内实现，无外部依赖，调试透明，适合嵌入式或老旧 CMS 环境。
必须避开的误区
很多方案看似“支持模块”，实则无效或引入新问题：
-
只用 Babel + @babel/preset-env：它能把
export转成exports.foo =，但无法处理import的依赖加载，浏览器仍会因import语法报错 - 直接用 Webpack 的 UMD 输出 + <script> 引入</script>：虽能运行，但破坏了模块作用域和 tree-shaking，且无法按需加载，等同于放弃模块化优势
-
依赖
document.currentScript动态加载：IE10+ 支持，但 Android 4.4 不支持，且并发加载易出错，不适合多模块场景 -
用
eval()执行模块字符串：CSP 策略禁止，且破坏调试、source map 和性能优化
模块 Polyfill 不是语法降级，而是运行时环境补全。选型时优先考虑是否真正接管了模块生命周期，而非是否“看起来像 ES 模块”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
