nomodule 属性不能直接“降级”旧脚本，因其设计意图是排除而非回退：仅在不支持 type="module" 的浏览器中执行，现代浏览器完全跳过，且不触发任何兼容逻辑。
nomodule 属性为什么不能直接“降级”旧脚本
nomodule 的设计意图不是做兼容层，而是告诉老浏览器“别执行这个 script”，它本身不触发任何降级逻辑。如果你写了 <script nomodule src="legacy.js"></script>，现代浏览器会跳过它——但你真正想加载的 legacy.js 反而没机会执行。常见错误是误以为加了 nomodule 就自动“兜底”，结果现代用户加载了新代码，旧用户啥也没加载。
关键点在于：nomodule 是“排除”而非“回退”。它只在不支持 type="module" 的浏览器中生效，而这类浏览器往往也不支持 async、defer 的精细控制，甚至不识别 nomodule 属性（IE11 完全忽略它，但也不会报错）。
正确组合 module + nomodule 的双 script 模式
必须成对使用：type="module" 脚本给现代浏览器，nomodule 脚本给旧浏览器。两者互斥，且都需显式声明 src。
-
<script type="module" src="app.mjs"></script>：仅现代浏览器加载并执行（支持 ES modules、import、top-level await等） -
<script nomodule src="legacy-bundle.js"></script>：仅不支持type="module"的浏览器加载（如 IE11、Android 4.4 WebView）
注意：nomodule 脚本不会被现代浏览器下载（Chrome/Firefox/Safari 均跳过），所以体积可以更大；但旧浏览器会同步阻塞解析，建议用构建工具把 legacy-bundle.js 压缩并内联关键逻辑。
旧脚本里调用现代 API 导致崩溃怎么办
即使用了 nomodule 加载旧脚本，如果里面还写了 const、箭头函数、Promise 或 fetch，旧浏览器照样报错。这不是 nomodule 能解决的——它只管加载，不管语法。
实操要点：
- 旧脚本必须是真正的 ES5 语法（Babel 编译目标设为
targets: { ie: "11" }） - 避免依赖未 polyfill 的全局对象，比如
Array.prototype.includes需要手动补丁或用core-js/stable - 不要在
nomodule脚本里动态import()，旧浏览器不支持 - 若用 Webpack/Vite，确认
build.target或babel-preset-env的 targets 和nomodule脚本实际覆盖范围一致
如何验证 nomodule 是否按预期工作
最可靠的方式不是看控制台，而是检查网络请求和执行上下文：
- 在 Chrome DevTools 的 Network 面板过滤
legacy-bundle.js，刷新页面——它不该出现在请求列表里 - 在 IE11 或 Edge 18 打开页面，打开开发者工具，执行
console.log(typeof module)应为"undefined"，且legacy-bundle.js的代码应正常运行 - 在现代浏览器中打断点进
app.mjs，确认legacy-bundle.js的全局变量（如window.myLegacyLib）不存在
容易被忽略的是：某些构建工具（如旧版 Vue CLI）会在 HTML 中同时注入 module 和 nomodule 脚本，但没清掉旧版 runtime，导致旧脚本里混入了 __webpack_require__ 这类现代打包痕迹——这时光靠 nomodule 挡不住语法错误。
