type="module" 是切换脚本执行模型的强制开关，而非可选配置；其核心约束包括：路径必须带扩展名和显式前缀、仅支持 file:// 协议外的本地服务器、模块作用域隔离、顶层 import 限制及依赖链中断机制。
type="module" 不是锦上添花的可选配置，而是切换整个脚本执行模型的开关。不按规范写，90% 的报错都源于路径、协议或上下文三处硬性约束。
import 路径必须带扩展名和显式前缀
浏览器对模块路径不做任何自动补全或推测——import 后面必须是字符串字面量，且含 .js（或其他合法扩展名）和 ./、../ 或 / 开头。
- ✅ 正确：
import { init } from './main.js'、import utils from '/lib/utils.js' - ❌ 错误：
import { init } from './main'（缺扩展名 →Failed to resolve module specifier） - ❌ 错误：
import { init } from 'utils.js'（裸路径 →SyntaxError，浏览器无法判断是相对还是绝对） - ❌ 错误：
import { init } from base + '.js'（动态拼接 → 解析阶段直接SyntaxError）
路径基准永远是 HTML 文件所在位置，不是当前 JS 文件位置；大小写、查询参数（如 utils.js?v=2）都会影响模块缓存键。
file:// 协议下模块加载必然失败
Chrome、Firefox 在本地双击打开 HTML 时，所有 type="module" 脚本静默拒绝加载——连网络请求都不会发出，控制台只报模糊的 CORS 错误或空异常。
立即学习“前端免费学习笔记（深入）”；
- 开发阶段必须用本地服务器：
npx serve、python3 -m http.server、Vite 预设的npm run dev等 - 不能依赖
document.currentScript：模块中该值恒为null，别用它取当前 script 的src - DOM 元素不可靠：模块默认
defer，但不等于能安全访问全部 DOM；若操作尚未解析的节点，仍需DOMContentLoaded或document.readyState === 'complete'
模块作用域隔离导致的隐式依赖断裂
传统脚本靠全局变量传递配置，模块化后这种模式直接失效：<script>let CONFIG = { api: '/v1' }</script> 定义的变量，在 <script type="module"></script> 中完全不可见。
- ❌ 常见错误：一个普通
<script></script>设window.APP_CONFIG，另一个type="module"里读window.APP_CONFIG—— 看似可行，实则违反模块设计初衷，易被压缩工具误删或污染 - ✅ 推荐做法：把配置也做成模块，
export default { api: '/v1' }，所有模块统一import config from './config.js' - ⚠️ 注意：
import必须在顶层，不能放在if、function或事件回调里；动态导入用import('./modal.js')，返回 Promise
模块加载失败会中断整条依赖链
浏览器在 HTML 解析阶段就静态构建依赖图，任一模块加载或解析失败（404、CORS、语法错误），后续所有依赖它的模块都不会执行，控制台报 Failed to load module script 或 TypeError: Failed to fetch dynamically imported module。
- 重复
import同一 URL 只触发一次请求，但./utils.js和../utils.js被视为不同模块 -
modulepreload仅预下载，不解析不执行，href必须与后续script[type="module"][src]的src完全一致（含查询参数） - 跨域模块（如 CDN 上的
lodash-es）必须加crossorigin属性，否则预加载静默失败
最常被忽略的一点：模块不是“更高级的传统脚本”，它是另一套执行环境——路径、协议、作用域、错误传播机制全都独立。试图用旧思维组织模块代码，几乎必然掉坑。
