type="module"脚本在file://协议下不执行，因浏览器硬限制；必须通过HTTP服务器运行，且跨域模块需服务端配置CORS响应头。
type="module" 脚本不执行？先检查是否在 file:// 协议下双击打开
本地直接双击 HTML 文件（地址栏显示 file:///xxx/index.html）时，Chrome、Firefox 会直接拒绝加载任何 type="module" 脚本，控制台可能只报空错误或笼统的 CORS 错误，连网络请求都不会发出。这不是路径写错，而是浏览器策略硬限制。
解决方法只有两个：
– 用本地服务器启动（如 npx serve、python3 -m http.server 或 VS Code Live Server 插件）
– 把文件部署到 HTTP/HTTPS 环境（哪怕 localhost:8080）
普通 <script> 没这限制，所以同一份脚本移除 type="module" 就能跑，容易误判为“代码问题”。
import 路径必须显式带扩展名和前缀
ES 模块路径是静态解析的，浏览器不会自动补 .js，也不会把裸名当相对路径。以下写法全会报 Failed to load module script：
立即学习“前端免费学习笔记（深入）”；
-
import { foo } from 'utils'❌ 裸包名，不支持 -
import { foo } from 'utils.js'❌ 缺少./，被当作绝对 URL 解析 -
import { foo } from './utils'❌ 没扩展名，多数浏览器拒绝加载
正确写法只有一种：import { foo } from './utils.js' ✅（或 ../、/ 开头的绝对路径）
普通 <script src="utils"> 可以省略扩展名，服务端还能靠 MIME 类型兜底；模块不行，路径必须合法且明确。
模块默认 defer，但不共享 window，也不支持 document.currentScript
type="module" 天然具有 defer 行为：下载不阻塞 HTML 解析，执行时机等同于 DOMContentLoaded 后，且多个模块严格按 DOM 顺序执行。
但它和手动加 defer 的普通脚本有本质区别：
- 模块内声明的
const app = {}不会挂到window.app上——作用域完全隔离 -
document.currentScript在模块脚本里永远是null，没法靠它取当前<script>标签 - 模块顶层可直接用
await，普通脚本只能包在 async 函数里
如果你的旧逻辑依赖全局变量或 currentScript 获取配置，迁移到模块时必须重写。
CORS 是硬门槛，跨域模块必须服务端配头
哪怕只是引入 CDN 上的 https://cdn.jsdelivr.net/npm/lodash-es@4.17.21/index.js，只要用了 type="module"，浏览器就会发带 Origin 头的 CORS 请求。如果服务端没返回 Access-Control-Allow-Origin: *（或精确匹配源），脚本直接失败，控制台报 CORS error。
普通 <script src="...> 跨域不走 CORS，所以老项目切模块时容易突然崩掉。
临时绕过方法只有两个：
– 同源托管该模块（比如把 lodash-es 下载到自己域名下）
– 用 <link rel="modulepreload" href="..." crossorigin> 预加载时也得加 crossorigin 属性，否则静默失败
