JS降级处理，兼容旧脚本技巧

本文深入解析了 `nomodule` 属性的真实作用与常见误区：它并非自动降级机制，而是通过浏览器对 `type="module"` 的支持与否实现精准分流——现代浏览器只执行 `type="module"` 脚本并完全忽略 `nomodule` 脚本，旧浏览器则反之；若单独使用 `nomodule`，反而可能导致旧用户无脚本可执行。文章强调必须成对使用 `module` 和 `nomodule` 双脚本，并指出真正决定兼容性的关键在于旧脚本本身是否严格遵循 ES5 语法、是否完成必要的 polyfill 补丁，以及构建配置（如 Babel target、Webpack/Vite 输出目标）是否与目标浏览器能力严格对齐；最后提供基于网络请求和运行时环境的实测验证方法，帮助开发者避开“看似写了 nomodule 实际仍崩溃”的典型陷阱。

nomodule 属性为什么不能直接“降级”旧脚本

nomodule 的设计意图不是做兼容层，而是告诉老浏览器“别执行这个 script”，它本身不触发任何降级逻辑。如果你写了 ，现代浏览器会跳过它——但你真正想加载的 legacy.js 反而没机会执行。常见错误是误以为加了 nomodule 就自动“兜底”，结果现代用户加载了新代码，旧用户啥也没加载。

关键点在于：nomodule 是“排除”而非“回退”。它只在不支持 type="module" 的浏览器中生效，而这类浏览器往往也不支持 async、defer 的精细控制，甚至不识别 nomodule 属性（IE11 完全忽略它，但也不会报错）。

正确组合 module + nomodule 的双 script 模式

必须成对使用：type="module" 脚本给现代浏览器，nomodule 脚本给旧浏览器。两者互斥，且都需显式声明 src。

• ：仅现代浏览器加载并执行（支持 ES modules、import、top-level await 等）
• ：仅不支持 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 挡不住语法错误。

以上就是《JS降级处理，兼容旧脚本技巧》的详细内容，更多关于的资料请关注golang学习网公众号！