动态导入（import()）是JS按需加载核心机制，测试须覆盖语法正确性、加载行为、错误处理、环境兼容性及构建协同，重点验证Promise行为、模块单例语义、路径解析准确性与各环境稳定性。
动态导入（import()）在 JS 中是按需加载模块的核心机制，编写综合测试方案需覆盖语法正确性、加载行为、错误处理、环境兼容性及与构建工具的协同。重点不是“能不能跑”，而是“在各种边界下是否稳定可控”。
覆盖核心使用场景
测试应包含以下典型调用方式，每种都需验证返回 Promise 的 resolved 值、模块内容可用性及副作用执行情况：
-
字符串字面量路径：如
import('./utils.js')—— 验证基础加载与默认导出获取 -
变量拼接路径（受限于静态分析）：如
import(`./features/${name}.js`)—— 测试合法变量替换（name = 'auth'），并检查构建工具是否能正确收集 chunk -
条件导入：如
if (env === 'admin') await import('./admin-panel.js')—— 验证未命中时不发起请求、命中时准确加载 -
多次导入同一模块：连续调用
import('./shared.js')两次 —— 确认模块只执行一次（单例语义），且两次 Promise 都 resolve 到同一模块实例
模拟和断言加载行为
浏览器环境可借助 jest 或 vitest 的 mock 功能，Node.js 环境需注意 vm 模块或实验性 ESM 支持：
- 用
vi.mock()（vitest）或jest.mock()拦截目标模块路径，返回带标识的 mock 模块（如{ loaded: true, value: 42 }），验证导入结果是否匹配 - 监听
fetch或XMLHttpRequest（若底层用它们加载）来确认请求 URL、次数与时机；也可 mockimport.meta.resolve和自定义 loader（如通过esbuild插件）控制解析逻辑 - 对 code-splitting 后的 chunk 文件名（如
utils.abc123.js），在打包后测试中检查 network tab 或服务端日志，确认请求的是实际生成的 hash 文件而非原始路径
强制触发错误路径
动态导入失败不抛同步错误，而是 reject Promise，必须显式 catch。测试要覆盖常见失败原因：
- 导入不存在的路径：
import('./missing.js')→ 断言 Promise reject 且 error message 包含 “not found” 或 404 - 模块语法错误（如
export default let a = 1;）→ 检查 reject reason 是否为SyntaxError - 网络中断或 CORS 阻止 → 在测试环境模拟 fetch 失败（如
vi.mock('node:fs', () => ({ readFile: vi.fn().mockRejectedValue(new Error('ECONNREFUSED')) }))） - 循环依赖中的动态导入 → 构建最小复现案例，验证是否进入 pending 死锁或给出清晰错误提示
跨环境与构建协同验证
动态导入行为受运行时环境与打包配置强影响，测试需分层执行：
-
开发服务器环境（Vite / Webpack Dev Server）：验证 HMR 是否正常（修改被动态导入的模块后，下次
import()是否拿到新版本） -
生产构建产物：启动本地静态服务（如
serve -s dist），运行端到端测试，检查 chunk 是否被正确分割、预加载提示（）是否存在、首屏无阻塞 -
Node.js ESM 环境：启用
--experimental-import-meta-resolve，测试import(`${path}`)在服务端的路径解析与加载（注意file://协议限制） - 微前端/沙箱环境（如 qiankun）：验证子应用内动态导入是否仍能正确解析相对路径，而非被主应用 base 路径污染
不复杂但容易忽略：动态导入的测试必须运行在真实模块系统上下文中（非 CommonJS require 模拟），否则无法暴露解析逻辑缺陷。建议用 vitest 的 testEnvironment: "node" 或 "jsdom" 配合原生 ESM 支持开启测试。
