深入掌握Module对象的加载机制与实战应用
爱学习的旭东又卡住了，Module对象动态加载报错
今天下午在搞一个动态模块加载的功能，本来以为几分钟搞定的事，结果一坐就是三小时。问题是这样的：我需要根据用户操作动态从远程拉一段JS代码，然后以ES Module的形式执行它。这玩意儿说白了就是动态import，但这次不是静态路径，而是字符串拼接的URL，还带token验证。
最开始我直接写了个fetch + eval，心想完事了。结果控制台啪一下就红了：
eval('"use strict"; export const hello = "world"')直接报错：SyntaxError: Unexpected token ‘export’。这才想起来，eval不支持模块语法。MDN上早写了，eval运行的是脚本模式，不是模块模式。这里我踩了个坑，以前一直以为eval万能，其实它根本处理不了import/export。
试了三种方案，前两个都翻车了
第一种尝试是用new Function()，把代码包进去：
const src = await fetch('https://jztheme.com/module.js').then(r => r.text())
const mod = new Function('', "use strict"; ${src}; return { hello })
console.log(mod())看起来好像行得通，但问题来了——如果原模块里有import语句呢？比如：
import { something } from './utils.js'
export const hello = "world"那这段代码直接在Function里就崩了，因为浏览器根本没法resolve那个import。而且更麻烦的是，这种做法完全绕过了ESM的依赖解析机制，相当于手动模拟模块执行，简直是给自己挖坟。
第二种方案是改用import()动态导入，但前提是文件必须能通过URL访问，并且服务器要允许CORS。我本地测试没问题，但部署到预发环境后发现CDN那边没配CORS头，403了。折腾了半天让后端加header，加上之后又遇到跨域cookie问题……算了，这条路太累。
最终解法：Blob URL + import()
后来查资料发现一个野路子：用Blob创建一个虚拟的module文件，然后通过URL.createObjectURL生成一个临时地址，再用import()去加载它。这个方法的关键点在于设置type为’application/javascript’，并且确保整个内容是以module形式存在的。
核心代码就这几行：
async function loadModuleFromCode(code) {
const blob = new Blob([code], { type: 'application/javascript' })
const url = URL.createObjectURL(blob)
try {
const module = await import(url)
return module
} finally {
// 记得释放URL对象，避免内存泄漏
URL.revokeObjectURL(url)
}
}然后调用的时候：
const code = await fetch('https://jztheme.com/api/dynamic-module')
.then(r => r.text())
const mod = await loadModuleFromCode(code)
console.log(mod.hello) // 输出预期值这里要注意几个细节：
- Blob必须指定正确的MIME type，不然import会失败
- URL.revokeObjectURL一定要放在finally里，否则每次加载都会残留一个临时URL，内存占用越来越高
- 如果你的代码里有相对路径import，这条路走不通，因为Blob没有base URL概念。不过可以自己提前把import重写成绝对路径
我项目里刚好所有依赖都是通过全局变量注入的（ legacy系统没办法），所以不需要处理import语句。如果是现代项目，建议还是走标准构建流程，别玩这种动态加载的花活。
关于Module对象本身的一些理解
其实我一直对ES Module的“对象”形式有点误解。早期以为module就是个普通object，后来才发现它是特殊的Module Namespace Object。比如你import进来的东西，是只读的，不能重新赋值。
举个例子：
import * as utils from './utils.js'
utils.someFunc = () => {} // 这行会静默失败，严格模式下还会报错这是因为ESM导出的绑定是“活绑定”（live binding），不是简单的值拷贝。你改不了它的属性，因为它背后连的是原始模块的内存引用。
而我们上面通过import()返回的module对象，也是这种类型。你可以用Object.keys看它的结构，但它不允许被修改。这也是为什么我们不能直接new或者assign的原因。
还有一个小问题没完美解决
现在这个方案跑起来是没问题了，但有个小瑕疵：每次加载都会触发一次网络请求+解析+执行，没法缓存。理想情况应该按内容hash做一层缓存，相同代码不重复加载。
我后来试了下加个map缓存url -> module：
const moduleCache = new Map()
async function loadModuleFromCode(code) {
const hash = btoa(code) // 简单hash，实际可以用xxhash之类的
if (moduleCache.has(hash)) {
return moduleCache.get(hash)
}
const blob = new Blob([code], { type: 'application/javascript' })
const url = URL.createObjectURL(blob)
try {
const module = await import(url)
moduleCache.set(hash, module)
return module
} finally {
URL.revokeObjectURL(url)
}
}但这有个隐患：revokeObjectURL之后，虽然module已经加载进内存，但理论上这个临时URL就被销毁了。我不知道V8内部是怎么管理这部分资源的，会不会有潜在的引用问题。目前测了几轮没崩，生产也上了，暂时观察中。
如果你有更好的缓存策略，欢迎评论区教我做人。
总结一下
以上是我踩坑后的总结。动态加载模块这事听起来简单，真做起来一堆边界情况。我的建议是：
- 能用静态import就别搞动态那一套
- 非要动态的话，优先考虑标准import() + 远程URL
- 只有在代码是运行时生成、或必须绕过CORS限制时，才用Blob + import这种组合拳
- 记得清理URL.createObjectURL产生的临时资源
这个方案不是最优的，甚至有点hack的味道，但在当前业务场景下是最简单可行的。改完后还有一两个小问题，比如热更新时旧module没彻底卸载（function还在call stack里），但无大碍。
以上是我个人对这个动态Module加载问题的完整记录，有更优的实现方式欢迎评论区交流。
暂无评论