type="module" 的 script 标签有哪些浏览器兼容性坑?

主流现代浏览器原生支持type="module",但需注意:旧版浏览器无自动降级,须手动用nomodule提供fallback;file://下模块加载必失败,须用本地服务器;路径必须带./或../及扩展名;async模块不保证执行顺序。

主流现代浏览器(Chrome 61+、Firefox 60+、Safari 11+、Edge 16+)都已原生支持 type="mod

ule",但实际开发中仍有几个关键兼容性坑必须注意。

不支持旧版浏览器,且无降级自动 fallback

IE 完全不支持;Android 4.4 WebView、iOS 10.3 以下 Safari 也不支持。重点是:浏览器遇到 type="module" 会直接忽略该 script 标签,但不会尝试加载对应的传统脚本。不能靠“写了 module 就自动兼容老版本”——必须手动提供 fallback:

  • 加载传统打包版(如 UMD 或 IIFE 格式)
  • 或服务端检测 User-Agent,动态返回不同 script 标签
  • 避免只写一个 type="module" 就上线,否则老用户页面 JS 彻底失效

本地文件系统(file://)下模块加载必然失败

直接双击 HTML 打开,或用 VS Code Live Server 以外的简易方式启动,会触发 CORS 错误,报类似:

“Access to script at 'file:///.../main.js' from origin 'null' has been blocked by CORS policy”

这是因为模块规范要求所有导入必须走网络请求,而 file:// 被视为特殊源 null,跨源限制无法绕过。解决办法只有:

  • 用本地开发服务器(如 python -m http.server、Vite、Webpack Dev Server)
  • 部署到真实 HTTP/HTTPS 环境(哪怕 localhost:8080)
  • 不要依赖 file:// 测试模块功能

路径和扩展名要求严格,老项目迁移易报错

模块解析规则比传统 script 严得多:

  • 所有相对路径必须以 ./../ 开头(src="utils.js" ❌,必须写成 src="./utils.js"
  • 导入语句中的路径必须带扩展名(import { foo } from './lib' ❌,要写 from './lib.js'
  • 裸模块名(如 import React from 'react')不被原生支持,需配合 或构建工具

async + defer 行为有隐含差异

type="module" 默认等效于 defer(HTML 解析完再执行,保持顺序),但加 async 后逻辑变化:

  • async 的模块会**立即下载、异步执行,不保证执行顺序**
  • 多个 async 模块之间无依赖顺序保障,可能破坏初始化逻辑
  • 如果模块有副作用(如注册全局插件、修改 DOM),混用 async 易引发竞态