` 语法到运行时按需拉取与持久缓存的完整实现)
Meteor dynamic-import 包源码解析从import(...)语法到运行时按需拉取与持久缓存的完整实现【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteordynamic-import是 Meteor 中实现 ECMAScript 动态import(...)语法的核心运行时包它把import(...)编译为module.dynamicImport(...)让模块在运行时才从服务器按需获取从而不必全部塞进初始 JavaScript 包。本文以 packages/dynamic-import/README.md 为骨架结合该包的客户端、服务端、缓存、版本清单等源码文件完整讲解其工作流程、缓存机制、服务端端点和配置项帮助你理解 Meteor 的精确代码分割exact code splitting是如何实现的以及在实际应用中如何正确使用和配置动态导入。一、包的作用与设计目标按 README.md 的定义该包实现了Module.prototype.dynamicImport(id)这一运行时 API用于从服务器动态获取模块使这些模块不必包含在初始 JavaScript bundle 中。包描述package.js也将其概括为 Runtime support for Meteor 1.5 dynamic import(...) syntax。核心设计目标有三点运行时按需加载静态import的模块会被打包进初始 bundle而动态import()的模块在运行时才从服务器获取永久缓存任何曾经获取过的模块版本会被永久缓存同一客户端即使关闭窗口、重启浏览器也不需要再次请求同一个版本版本感知如果模块内容变化版本 hash 变化客户端总能拿到最新副本。值得注意的是README 特别强调Meteor 1.5 是必要前提。这一点在 package.js 中也有硬性保证包通过api.use(isobuild:dynamic-import1.5.0)声明禁止在 Meteor 1.5 之前的应用中使用。二、整体架构一个请求-响应式的运行时模块系统从源码结构看该包由 8 个文件组成职责划分非常清晰文件职责client.js客户端运行时定义Module.prototype.dynamicImport负责收集缺失模块、发起网络请求、注册模块server.js服务端注册 HTTP 端点按请求树返回模块源码支持多平台与密钥鉴别cache.js客户端持久缓存基于 IndexedDB 按版本号缓存模块源码dynamic-versions.js动态版本清单读取构建期注入的__DYNAMIC_VERSIONS__哈希树common.js共享常量网络端点路径security.js与 browser-policy-content 协作允许evalpackage.js包描述与依赖声明CHANGELOG.md变更记录含 settings 配置项说明整个流程可以概括为构建期bundler计算所有动态模块的版本哈希树并注入客户端运行期客户端调用dynamicImport先用版本树判断哪些模块缺失再检查本地 IndexedDB 缓存最后把仍缺失的模块树 POST 给服务端服务端按树返回源码 JSON客户端逐个注册并求值。三、运行时 APIModule.prototype.dynamicImportclient.js 中定义了核心 APIModule.prototype.dynamicImport function (id) { var module this; return module.prefetch(id).then(function () { return getNamespace(module, id); }); };prefetch是 Meteor 模块系统由meteor/modules包提供自带的能力它会预取目标模块及其所有尚未获取的依赖getNamespace则通过module.link(id, {*: ns namespace ns})拿到模块的命名空间对象并为其定义一个不可枚举的__esModule: true属性以兼容 Babel 的 ES 模块互操作client.js。README 明确说With this package installed, supporting the dynamicimport(...)proposal is as easy as compilingimport(...)tomodule.dynamicImport(...)。也就是说编译层Babel只需做一个机械变换真正的运行时语义由该包提供。这正是 Meteor 3.x 之前基于 CommonJS 模块运行时实现标准动态导入的关键所在。四、客户端拉取流程缺失模块树的精确计算当prefetch发现存在尚未获取的动态模块时会调用meteorInstall.fetchclient.js。其算法可以拆解为四步版本树查询遍历请求的模块 id 列表通过dynamicVersions.get(id)即__DYNAMIC_VERSIONS__哈希树查出版本号查不到版本的记为缺失缓存命中检查对有版本的模块调用cache.checkMany(versions)从 IndexedDB 中按版本读取源码读到的直接加入待注册树读不到的记为缺失网络请求把仍缺失的模块树通过fetchMissing以POST请求发给服务端端点缓存写入把服务端返回的源码按{version, source}形式写入本地缓存cache.setMany并把源码加入注册树。fetchMissingclient.js的请求体是JSON.stringify(missingTree)——一个嵌套对象树例如{/libs: {example.js: 1}}。它先把模块 id 转成嵌套树addToTree服务端可以原样按树返回源码 JSON客户端再通过flattenModuleTree把它拍平成id - source的映射。这里有几个值得注意的实现细节求值延迟makeModuleFunctionclient.js把模块源码包装成function(require, exports, module) {...}形式的函数并通过(options options.eval || eval)延迟解析求值——只有模块第一次被真正 import 时才付出解析和求值的开销而不是下载完成后立即求值源码映射求值时拼接\n//# sourceURL id保证开发者在 DevTools 调试时能看到可读的模块名跨域兼容如果Meteor.absoluteUrl的主机与location.host不一致请求会变成跨域请求但服务端设置了对应的 CORS 头README 与源码注释都建议让ROOT_URL尽量与location.host一致以省去 CORS 预检OPTIONS带来的首包延迟。4.1 跨域相关的 settings 配置项client.js 从Meteor.settings.public.packages[dynamic-import]读取配置目前支持两个布尔选项见 CHANGELOG.md 中 0.5.3 的说明{ public: { packages: { dynamic-import: { useLocationOrigin: true, disableLocationOriginIframe: false } } } }useLocationOrigin为true时改用location.origin拼接请求 URL而非ROOT_URL允许从与ROOT_URL不同的源获取动态模块数据disableLocationOriginIframe为true时在 iframe 环境中禁用useLocationOrigin行为因为 iframe 的location.origin可能与页面主体不同。判断逻辑见 client.js。五、服务端端点/__meteor__/dynamic-import/fetch请求端点路径定义在 common.jsexports.fetchURL /__meteor__/dynamic-import/fetch;服务端在 server.js 中于Meteor.startup时把端点注册到Package.webapp.WebAppInternals.meteorInternalHandlers。有个重要细节该包不强制依赖 webapp。源码注释解释了原因——如果程序是 isopacket 或构建插件没有 web 服务器就不应该被 dynamic-import 单方面拖入 webapp 依赖因此代码先用if (! Package.webapp) return;判断若无 webapp 则跳过服务端逻辑此时Module.prototype.dynamicImport依然可用只是所有模块已在初始包内、无需拉取。5.1 HTTP 行为与 CORS中间件middlewareserver.js针对三种请求方法分别处理OPTIONSCORS 预检返回Access-Control-Allow-Origin: *、Access-Control-Allow-Methods: POST、Access-Control-Allow-Headers回显请求头或*POST解析请求体 JSON 树 → 按平台读取模块源码 → 返回200 application/json任何解析或读取错误返回400开发模式下附带真实错误信息生产模式只返回bad request其他方法返回405 Method Not Allowed并带Allow: OPTIONS, POST头。任何来源都允许Access-Control-Allow-Origin: *这与 4 节提到的跨域拉取场景配套。5.2 平台识别与密钥同一份动态模块树可以服务于不同平台web.browser、web.browser.legacy、web.cordova等。getPlatformserver.js的判定逻辑是如果请求带key查询参数且与某个平台的密钥匹配则使用该平台否则回退到Package.webapp.WebApp.categorizeRequest(request).arch按请求特征分类。其中web.browser等客户端平台之所以能用密钥是因为服务端为这些平台生成并下发了密钥randomId(40)见 server.jsserver平台由服务端进程自己持有客户端平台则在启动时通过client.setSecretKey注入随后的动态请求都会附带key参数。密钥机制保证了多平台各自拿到匹配自己架构的模块变体。5.3 路径安全与平台缓存read函数server.js负责把模块 id 映射为文件系统路径并读取内容有几个安全/健壮性设计模块 id 中的:会被替换为_Meteor 包名含冒号如meteor:accounts-base拼接后的绝对路径必须startsWith(dynamicRoot)否则拒绝读取并打印bad dynamic import path——防止路径穿越按平台维护内存缓存getCache读过的文件不再重复读盘读取失败返回null对应节点会在响应树中被剪除readTree的剪枝逻辑。readTreeserver.js递归遍历请求树若某模块读取返回null就把它从结果树中删除从而保证响应中不会有任何冗余模块——客户端只需要返回真正缺失的内容。5.4 热更新时的缓存失效server.js 监听了meteor/inter-process-messaging的client-refresh消息当发生纯客户端刷新代码变更、热重载时清空所有平台的文件读取缓存避免新客户端拿到过期的模块数据。该消息由tools/runners/run-app.js发出autoupdate包也会消费它。六、客户端持久缓存IndexedDB 按版本存储cache.js 实现了 README 中永久缓存的承诺。缓存数据库名为MeteorDynamicImportCache当前版本号 2对象仓库sourcesByVersion以version为主键keyPath。关键设计决策只在生产环境启用canUseCache Meteor.isClient !Meteor.isCordova Meteor.isProduction。开发环境禁用缓存是为了避免改了代码却看到旧模块的困惑Cordova 因为把所有模块打包进初始 bundle 而无需缓存cache.js按版本寻址而非按模块名因为模块版本 hash 是不可变的用version作主键天然就是immutable caching——同一个版本永远对应同一份源码永远不需要失效写入延迟批处理setMany不立即写库而是延迟 100ms 通过flushSetMany批量写入避免拖慢module.dynamicImport的返回若此时恰有读取事务checkCount 0则再推迟cache.js容错降级withDB在 IndexedDB 不可用如 Safari 隐私模式时优雅降级为不使用缓存每次回退到网络请求不影响功能CHANGELOG.md 记录了 0.7.1 对 Safari 14 的 indexedDB bugbugs.webkit.org 226547的修复client.js 中保留了var idb global.indexedDB这个看似无用实则触发 bug 规避的引用。读取路径checkMany同样是事务化的为每个待查版本发起sourcesByVersion.get(version)命中则复用缓存源码未命中则标记缺失交给网络层。七、版本清单__DYNAMIC_VERSIONS__与构建期注入客户端是如何不询问服务器就知道某版本是否已缓存的答案在 dynamic-versions.js// This magic double-underscored identifier gets replaced in // tools/isobuild/bundler.js with a tree of hashes of all dynamic // modules, for use in client.js and cache.js. var versions __DYNAMIC_VERSIONS__;构建期bundler.js 会把所有targetPath以dynamic/开头的文件加入版本树addToTree(file.hash(), file.targetPath, versions)key 是文件内容 hash然后把packages/dynamic-import.js中的__DYNAMIC_VERSIONS__占位符替换为JSON.stringify(versions.dynamic || {})。因此初始 bundle 内就携带了全部动态模块的哈希树。客户端无需向服务器确认即可判断缓存是否可用同版本模块永远不会被同一客户端重复下载。这正是 README 中所说永久缓存能成立的前提。dynamicVersions.get(id)在遍历时对冒号做了容错tree[part] || tree[part.replace(:, _)]兼容历史上包名冒号被替换为下划线的已知问题见源码注释引用的 PR 9103。此外dynamic-versions.js 还实现了一个与appcache包配合的预取逻辑页面load事件后若检测到Package.appcache存在就按每批 50 个模块调用module.prefetch把可能用到的动态模块提前缓存起来同一事件循环内的多次 prefetch 会合并成一次 POST 请求减少请求次数。预取失败时还会尝试把/node_modules/meteor/a_b修正为/node_modules/meteor/a:b再试一次兼容冒号/下划线问题。八、使用方式.then()、await与默认导出官方包文档 docs/source/packages/dynamic-import.md 给出了完整的使用姿势。import(...)返回一个 Promiseresolve 为模块的 exports使用.then()import(tool).then(tool tool.task());在异步函数中awaitasync function performTask() { const tool await import(tool); tool.task(); }默认导出Promise resolve 的是模块的 exports 对象默认导出位于结果的default属性上可用解构提高可读性import(another-tool).then(({ default: thatTool }) thatTool.go());九、动态表达式与模块白名单如果你想用计算表达式动态导入例如let path example; const module await import(/libs/${path}.js);会得到Error: Cannot find module /libs/example.js。原因在 docs/source/packages/dynamic-import.md 中解释得很清楚Meteor 的构建过程基于静态分析建立模块依赖图只有出现在静态 import、动态 import字符串字面量或 require 中的模块才会被构建并可供import()使用。解决方案是建立白名单模块让构建过程能读到、但不会实际运行if (false) { import(/libs/example.js); import(/libs/another-example.js); import(/libs/yet-another-example.js); }注意该白名单需要同时被客户端和服务端入口引用保证两端都能看到这些依赖。白名单之外字符串字面量直接写死的动态 import 也是支持的——这与 webpack/browserify 不同后两者会把模块标识符替换成数字运行时无法再解析动态字符串而 Meteor 的客户端模块系统保留字符串 id所以只要依赖在静态图上出现过运行时就能解析。十、与 webpack 等打包系统的区别精确代码分割client.js 与官方文档都点明了 Meteor 方案的独特之处客户端拥有完美信息清楚知道哪些模块在初始包里、哪些在本地缓存、哪些仍需拉取单次客户端请求之间零重叠服务器响应中也不会有多余模块——官方称之为exact code splitting精确代码分割以区别于传统打包bundling不可变缓存初始包携带全部动态模块的哈希树客户端不必询问服务器这个版本还能不能用天然具备 immutable caching 的所有优点动态字符串可解析只要依赖在代码中静态表达过运行时就能解析动态字符串而不像 webpack/browserify 那样把模块 id 替换为数字。关于性能与体验的取舍TODO.md 记录了维护者规划中的未来方向例如批量合并__dynamicImport调用、检测页面加载期间未求值的模块并建议改为动态导入、在路由回调中建议动态切割点、警告被动态导入的模块又被静态导入这会抵消收益等——这些可以看作该包演进思路的官方注脚。十一、与 Content Security Policy 的关系security.js 解决了 CSP 环境下动态模块求值的兼容问题如果应用启用了browser-policy-content该包会在启动时调用BrowserPolicy.content.allowEval()放行eval。源码注释论证了这一取舍动态模块必须能求值新代码否则只能退回到script src标签加载——那样就无法写入本地缓存也无法在无 Service Worker 的浏览器中实现缓存命中。更重要的是eval允许在原始包作用域内求值动态模块代码这是script标签永远做不到的。如果你部署的环境要求禁止eval的 CSP唯一选择是把所有动态模块打进初始 bundle——功能完全正常只是享受不到按需拉取的性能收益。从源码结构看这正是dynamic-import与 packages/browser-policy-content/browser-policy-content.js 的协作点。十二、依赖关系与使用前提小结综合 package.js 与 README使用本包需要满足Meteor 1.5硬性要求构建期由isobuild:dynamic-import1.5.0校验依赖modules、promise、fetch、modern-browsers包服务端额外依赖inter-process-messaging弱依赖hot-module-replacement服务端功能HTTP 端点依赖webapp包但包本身不强依赖webapp——无 web 服务器的场景isopacket/构建插件仍可安装使用生产环境浏览器缓存依赖 IndexedDBCordova 场景自动跳过若使用browser-policy-content包会自动请求allowEval配置项通过Meteor.settings.public.packages[dynamic-import]注入useLocationOrigin、disableLocationOriginIframe用于多源部署场景。结语通过阅读源码可以看到Meteor 的动态导入不是简单地把 webpack 式的代码分割照搬过来而是一套以版本哈希树为核心的精确按需加载系统构建期注入版本清单运行期先查缓存、后查网络服务端按缺失树精确回包客户端以 IndexedDB 实现不可变缓存。理解 client.js、server.js、cache.js 与 bundler.js 之间的协作关系能帮助你在实际应用中正确选择动态导入的切割点、配置跨域选项并理解 CSP 限制下的降级行为——这正是将大型 Meteor 应用启动性能做好的关键能力之一。【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/19 8:01:13 · 阅读 1.2k Meteor dynamic-import 包源码解析：从 `import(...)` 语法到运行时按需拉取与持久缓存的完整实现
Meteor dynamic-import 包源码解析从import(...)语法到运行时按需拉取与持久缓存的完整实现【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteordynamic-import是 Meteor 中实现 ECMAScript 动态import(...)语法的核心运行时包它把import(...)编译为module.dynamicImport(...)让模块在运行时才从服务器按需获取从而不必全部塞进初始 JavaScript 包。本文以 packages/dynamic-import/README.md 为骨架结合该包的客户端、服务端、缓存、版本清单等源码文件完整讲解其工作流程、缓存机制、服务端端点和配置项帮助你理解 Meteor 的精确代码分割exact code splitting是如何实现的以及在实际应用中如何正确使用和配置动态导入。一、包的作用与设计目标按 README.md 的定义该包实现了Module.prototype.dynamicImport(id)这一运行时 API用于从服务器动态获取模块使这些模块不必包含在初始 JavaScript bundle 中。包描述package.js也将其概括为 Runtime support for Meteor 1.5 dynamic import(...) syntax。核心设计目标有三点运行时按需加载静态import的模块会被打包进初始 bundle而动态import()的模块在运行时才从服务器获取永久缓存任何曾经获取过的模块版本会被永久缓存同一客户端即使关闭窗口、重启浏览器也不需要再次请求同一个版本版本感知如果模块内容变化版本 hash 变化客户端总能拿到最新副本。值得注意的是README 特别强调Meteor 1.5 是必要前提。这一点在 package.js 中也有硬性保证包通过api.use(isobuild:dynamic-import1.5.0)声明禁止在 Meteor 1.5 之前的应用中使用。二、整体架构一个请求-响应式的运行时模块系统从源码结构看该包由 8 个文件组成职责划分非常清晰文件职责client.js客户端运行时定义Module.prototype.dynamicImport负责收集缺失模块、发起网络请求、注册模块server.js服务端注册 HTTP 端点按请求树返回模块源码支持多平台与密钥鉴别cache.js客户端持久缓存基于 IndexedDB 按版本号缓存模块源码dynamic-versions.js动态版本清单读取构建期注入的__DYNAMIC_VERSIONS__哈希树common.js共享常量网络端点路径security.js与 browser-policy-content 协作允许evalpackage.js包描述与依赖声明CHANGELOG.md变更记录含 settings 配置项说明整个流程可以概括为构建期bundler计算所有动态模块的版本哈希树并注入客户端运行期客户端调用dynamicImport先用版本树判断哪些模块缺失再检查本地 IndexedDB 缓存最后把仍缺失的模块树 POST 给服务端服务端按树返回源码 JSON客户端逐个注册并求值。三、运行时 APIModule.prototype.dynamicImportclient.js 中定义了核心 APIModule.prototype.dynamicImport function (id) { var module this; return module.prefetch(id).then(function () { return getNamespace(module, id); }); };prefetch是 Meteor 模块系统由meteor/modules包提供自带的能力它会预取目标模块及其所有尚未获取的依赖getNamespace则通过module.link(id, {*: ns namespace ns})拿到模块的命名空间对象并为其定义一个不可枚举的__esModule: true属性以兼容 Babel 的 ES 模块互操作client.js。README 明确说With this package installed, supporting the dynamicimport(...)proposal is as easy as compilingimport(...)tomodule.dynamicImport(...)。也就是说编译层Babel只需做一个机械变换真正的运行时语义由该包提供。这正是 Meteor 3.x 之前基于 CommonJS 模块运行时实现标准动态导入的关键所在。四、客户端拉取流程缺失模块树的精确计算当prefetch发现存在尚未获取的动态模块时会调用meteorInstall.fetchclient.js。其算法可以拆解为四步版本树查询遍历请求的模块 id 列表通过dynamicVersions.get(id)即__DYNAMIC_VERSIONS__哈希树查出版本号查不到版本的记为缺失缓存命中检查对有版本的模块调用cache.checkMany(versions)从 IndexedDB 中按版本读取源码读到的直接加入待注册树读不到的记为缺失网络请求把仍缺失的模块树通过fetchMissing以POST请求发给服务端端点缓存写入把服务端返回的源码按{version, source}形式写入本地缓存cache.setMany并把源码加入注册树。fetchMissingclient.js的请求体是JSON.stringify(missingTree)——一个嵌套对象树例如{/libs: {example.js: 1}}。它先把模块 id 转成嵌套树addToTree服务端可以原样按树返回源码 JSON客户端再通过flattenModuleTree把它拍平成id - source的映射。这里有几个值得注意的实现细节求值延迟makeModuleFunctionclient.js把模块源码包装成function(require, exports, module) {...}形式的函数并通过(options options.eval || eval)延迟解析求值——只有模块第一次被真正 import 时才付出解析和求值的开销而不是下载完成后立即求值源码映射求值时拼接\n//# sourceURL id保证开发者在 DevTools 调试时能看到可读的模块名跨域兼容如果Meteor.absoluteUrl的主机与location.host不一致请求会变成跨域请求但服务端设置了对应的 CORS 头README 与源码注释都建议让ROOT_URL尽量与location.host一致以省去 CORS 预检OPTIONS带来的首包延迟。4.1 跨域相关的 settings 配置项client.js 从Meteor.settings.public.packages[dynamic-import]读取配置目前支持两个布尔选项见 CHANGELOG.md 中 0.5.3 的说明{ public: { packages: { dynamic-import: { useLocationOrigin: true, disableLocationOriginIframe: false } } } }useLocationOrigin为true时改用location.origin拼接请求 URL而非ROOT_URL允许从与ROOT_URL不同的源获取动态模块数据disableLocationOriginIframe为true时在 iframe 环境中禁用useLocationOrigin行为因为 iframe 的location.origin可能与页面主体不同。判断逻辑见 client.js。五、服务端端点/__meteor__/dynamic-import/fetch请求端点路径定义在 common.jsexports.fetchURL /__meteor__/dynamic-import/fetch;服务端在 server.js 中于Meteor.startup时把端点注册到Package.webapp.WebAppInternals.meteorInternalHandlers。有个重要细节该包不强制依赖 webapp。源码注释解释了原因——如果程序是 isopacket 或构建插件没有 web 服务器就不应该被 dynamic-import 单方面拖入 webapp 依赖因此代码先用if (! Package.webapp) return;判断若无 webapp 则跳过服务端逻辑此时Module.prototype.dynamicImport依然可用只是所有模块已在初始包内、无需拉取。5.1 HTTP 行为与 CORS中间件middlewareserver.js针对三种请求方法分别处理OPTIONSCORS 预检返回Access-Control-Allow-Origin: *、Access-Control-Allow-Methods: POST、Access-Control-Allow-Headers回显请求头或*POST解析请求体 JSON 树 → 按平台读取模块源码 → 返回200 application/json任何解析或读取错误返回400开发模式下附带真实错误信息生产模式只返回bad request其他方法返回405 Method Not Allowed并带Allow: OPTIONS, POST头。任何来源都允许Access-Control-Allow-Origin: *这与 4 节提到的跨域拉取场景配套。5.2 平台识别与密钥同一份动态模块树可以服务于不同平台web.browser、web.browser.legacy、web.cordova等。getPlatformserver.js的判定逻辑是如果请求带key查询参数且与某个平台的密钥匹配则使用该平台否则回退到Package.webapp.WebApp.categorizeRequest(request).arch按请求特征分类。其中web.browser等客户端平台之所以能用密钥是因为服务端为这些平台生成并下发了密钥randomId(40)见 server.jsserver平台由服务端进程自己持有客户端平台则在启动时通过client.setSecretKey注入随后的动态请求都会附带key参数。密钥机制保证了多平台各自拿到匹配自己架构的模块变体。5.3 路径安全与平台缓存read函数server.js负责把模块 id 映射为文件系统路径并读取内容有几个安全/健壮性设计模块 id 中的:会被替换为_Meteor 包名含冒号如meteor:accounts-base拼接后的绝对路径必须startsWith(dynamicRoot)否则拒绝读取并打印bad dynamic import path——防止路径穿越按平台维护内存缓存getCache读过的文件不再重复读盘读取失败返回null对应节点会在响应树中被剪除readTree的剪枝逻辑。readTreeserver.js递归遍历请求树若某模块读取返回null就把它从结果树中删除从而保证响应中不会有任何冗余模块——客户端只需要返回真正缺失的内容。5.4 热更新时的缓存失效server.js 监听了meteor/inter-process-messaging的client-refresh消息当发生纯客户端刷新代码变更、热重载时清空所有平台的文件读取缓存避免新客户端拿到过期的模块数据。该消息由tools/runners/run-app.js发出autoupdate包也会消费它。六、客户端持久缓存IndexedDB 按版本存储cache.js 实现了 README 中永久缓存的承诺。缓存数据库名为MeteorDynamicImportCache当前版本号 2对象仓库sourcesByVersion以version为主键keyPath。关键设计决策只在生产环境启用canUseCache Meteor.isClient !Meteor.isCordova Meteor.isProduction。开发环境禁用缓存是为了避免改了代码却看到旧模块的困惑Cordova 因为把所有模块打包进初始 bundle 而无需缓存cache.js按版本寻址而非按模块名因为模块版本 hash 是不可变的用version作主键天然就是immutable caching——同一个版本永远对应同一份源码永远不需要失效写入延迟批处理setMany不立即写库而是延迟 100ms 通过flushSetMany批量写入避免拖慢module.dynamicImport的返回若此时恰有读取事务checkCount 0则再推迟cache.js容错降级withDB在 IndexedDB 不可用如 Safari 隐私模式时优雅降级为不使用缓存每次回退到网络请求不影响功能CHANGELOG.md 记录了 0.7.1 对 Safari 14 的 indexedDB bugbugs.webkit.org 226547的修复client.js 中保留了var idb global.indexedDB这个看似无用实则触发 bug 规避的引用。读取路径checkMany同样是事务化的为每个待查版本发起sourcesByVersion.get(version)命中则复用缓存源码未命中则标记缺失交给网络层。七、版本清单__DYNAMIC_VERSIONS__与构建期注入客户端是如何不询问服务器就知道某版本是否已缓存的答案在 dynamic-versions.js// This magic double-underscored identifier gets replaced in // tools/isobuild/bundler.js with a tree of hashes of all dynamic // modules, for use in client.js and cache.js. var versions __DYNAMIC_VERSIONS__;构建期bundler.js 会把所有targetPath以dynamic/开头的文件加入版本树addToTree(file.hash(), file.targetPath, versions)key 是文件内容 hash然后把packages/dynamic-import.js中的__DYNAMIC_VERSIONS__占位符替换为JSON.stringify(versions.dynamic || {})。因此初始 bundle 内就携带了全部动态模块的哈希树。客户端无需向服务器确认即可判断缓存是否可用同版本模块永远不会被同一客户端重复下载。这正是 README 中所说永久缓存能成立的前提。dynamicVersions.get(id)在遍历时对冒号做了容错tree[part] || tree[part.replace(:, _)]兼容历史上包名冒号被替换为下划线的已知问题见源码注释引用的 PR 9103。此外dynamic-versions.js 还实现了一个与appcache包配合的预取逻辑页面load事件后若检测到Package.appcache存在就按每批 50 个模块调用module.prefetch把可能用到的动态模块提前缓存起来同一事件循环内的多次 prefetch 会合并成一次 POST 请求减少请求次数。预取失败时还会尝试把/node_modules/meteor/a_b修正为/node_modules/meteor/a:b再试一次兼容冒号/下划线问题。八、使用方式.then()、await与默认导出官方包文档 docs/source/packages/dynamic-import.md 给出了完整的使用姿势。import(...)返回一个 Promiseresolve 为模块的 exports使用.then()import(tool).then(tool tool.task());在异步函数中awaitasync function performTask() { const tool await import(tool); tool.task(); }默认导出Promise resolve 的是模块的 exports 对象默认导出位于结果的default属性上可用解构提高可读性import(another-tool).then(({ default: thatTool }) thatTool.go());九、动态表达式与模块白名单如果你想用计算表达式动态导入例如let path example; const module await import(/libs/${path}.js);会得到Error: Cannot find module /libs/example.js。原因在 docs/source/packages/dynamic-import.md 中解释得很清楚Meteor 的构建过程基于静态分析建立模块依赖图只有出现在静态 import、动态 import字符串字面量或 require 中的模块才会被构建并可供import()使用。解决方案是建立白名单模块让构建过程能读到、但不会实际运行if (false) { import(/libs/example.js); import(/libs/another-example.js); import(/libs/yet-another-example.js); }注意该白名单需要同时被客户端和服务端入口引用保证两端都能看到这些依赖。白名单之外字符串字面量直接写死的动态 import 也是支持的——这与 webpack/browserify 不同后两者会把模块标识符替换成数字运行时无法再解析动态字符串而 Meteor 的客户端模块系统保留字符串 id所以只要依赖在静态图上出现过运行时就能解析。十、与 webpack 等打包系统的区别精确代码分割client.js 与官方文档都点明了 Meteor 方案的独特之处客户端拥有完美信息清楚知道哪些模块在初始包里、哪些在本地缓存、哪些仍需拉取单次客户端请求之间零重叠服务器响应中也不会有多余模块——官方称之为exact code splitting精确代码分割以区别于传统打包bundling不可变缓存初始包携带全部动态模块的哈希树客户端不必询问服务器这个版本还能不能用天然具备 immutable caching 的所有优点动态字符串可解析只要依赖在代码中静态表达过运行时就能解析动态字符串而不像 webpack/browserify 那样把模块 id 替换为数字。关于性能与体验的取舍TODO.md 记录了维护者规划中的未来方向例如批量合并__dynamicImport调用、检测页面加载期间未求值的模块并建议改为动态导入、在路由回调中建议动态切割点、警告被动态导入的模块又被静态导入这会抵消收益等——这些可以看作该包演进思路的官方注脚。十一、与 Content Security Policy 的关系security.js 解决了 CSP 环境下动态模块求值的兼容问题如果应用启用了browser-policy-content该包会在启动时调用BrowserPolicy.content.allowEval()放行eval。源码注释论证了这一取舍动态模块必须能求值新代码否则只能退回到script src标签加载——那样就无法写入本地缓存也无法在无 Service Worker 的浏览器中实现缓存命中。更重要的是eval允许在原始包作用域内求值动态模块代码这是script标签永远做不到的。如果你部署的环境要求禁止eval的 CSP唯一选择是把所有动态模块打进初始 bundle——功能完全正常只是享受不到按需拉取的性能收益。从源码结构看这正是dynamic-import与 packages/browser-policy-content/browser-policy-content.js 的协作点。十二、依赖关系与使用前提小结综合 package.js 与 README使用本包需要满足Meteor 1.5硬性要求构建期由isobuild:dynamic-import1.5.0校验依赖modules、promise、fetch、modern-browsers包服务端额外依赖inter-process-messaging弱依赖hot-module-replacement服务端功能HTTP 端点依赖webapp包但包本身不强依赖webapp——无 web 服务器的场景isopacket/构建插件仍可安装使用生产环境浏览器缓存依赖 IndexedDBCordova 场景自动跳过若使用browser-policy-content包会自动请求allowEval配置项通过Meteor.settings.public.packages[dynamic-import]注入useLocationOrigin、disableLocationOriginIframe用于多源部署场景。结语通过阅读源码可以看到Meteor 的动态导入不是简单地把 webpack 式的代码分割照搬过来而是一套以版本哈希树为核心的精确按需加载系统构建期注入版本清单运行期先查缓存、后查网络服务端按缺失树精确回包客户端以 IndexedDB 实现不可变缓存。理解 client.js、server.js、cache.js 与 bundler.js 之间的协作关系能帮助你在实际应用中正确选择动态导入的切割点、配置跨域选项并理解 CSP 限制下的降级行为——这正是将大型 Meteor 应用启动性能做好的关键能力之一。【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考