现代web开发倾向于使用esm而非传统脚本，原因包括：1. 作用域隔离，避免全局变量污染；2. 明确的依赖管理，自动解析模块顺序；3. 默认异步加载，提升页面性能；4. 支持严格模式和cors；5. 支持tree shaking优化代码体积。
html模块加载，现在我们主要说的就是ESM（ecmascript Modules），它通过，浏览器就能识别这是一个模块脚本。它天生就是异步的，不会阻塞HTML解析，而且内部可以自由地使用import和export来组织代码。这种方式的好处是显而易见的：模块内部变量互不干扰，依赖关系清晰，天然支持跨域（CORS），并且默认运行在严格模式下。这让代码的管理和协作变得异常清爽。
立即学习“前端免费学习笔记（深入）”；
然后是动态导入（Dynamic import()）。这玩意儿简直是懒加载的神器。它不是一个声明式的标签，而是一个返回promise的函数。你可以在代码运行时，根据需要或者用户交互，才去加载某个模块。比如，用户点击了一个按钮，才去加载一个庞大的图表库；或者当路由切换到某个页面时，才去加载对应的页面组件。这种方式极大地优化了初始加载时间，让用户能更快地看到可交互的内容。
当然，我们也不能忘了传统的<script>标签</script>。虽然在现代模块化开发中，它显得有些“老派”，但它依然是加载JavaScript文件最直接的方式。
底部引入或者使用defer/async属性来避免阻塞渲染，这是我们过去常用的优化手段。不过，它最大的缺点就是容易造成全局变量污染，而且脚本间的依赖关系需要手动维护，一旦顺序错了，就可能报错。
谈到性能优化，特别是针对import策略，我个人觉得有四种思路是特别值得深挖的：
-
按需加载（Lazy Loading）与动态导入的结合：这几乎是现代前端性能优化的基石。想象一下，你的应用有很多功能，但用户在第一次访问时可能只用到其中一小部分。通过import()，你可以把那些非核心、不紧急的模块拆分成独立的代码块，只在真正需要的时候才去请求和执行。比如一个复杂的富文本编辑器，你完全可以在用户点击“编辑”按钮时才去加载它。这能显著减少初始包的大小，让首屏加载速度飞快。
-
预加载（Preload）和预连接（Preconnect）的妙用：这其实是给浏览器“打个提前量”。当你知道某个模块在不久的将来肯定会被用到，或者某个域名的资源即将被请求时，你可以通过告诉浏览器，或者用提前建立TCP连接甚至TLS握手。modulepreload尤其针对ESM，能让浏览器在解析到
-
模块拆分与代码分割（Code Splitting）：这通常和构建工具（如webpack、Rollup、Vite）紧密相关。它不是一个单一的import策略，而是通过工具将你的整个应用代码，根据依赖关系和使用场景，智能地拆分成多个更小的JavaScript文件（chunk）。每个chunk都包含一部分代码。当浏览器加载页面时，它只需要下载当前页面或当前功能所需的chunk，而不是整个巨大的应用包。这和按需加载是相辅相成的，动态import()是实现代码分割的关键API之一。拆分后的模块可以并行下载，也能更好地利用浏览器缓存。
-
缓存策略与版本控制：这是个老生常谈的话题，但对模块加载性能至关重要。一旦模块文件被下载到用户浏览器，我们都希望它能被高效地缓存起来，下次访问时就无需再次下载。这需要合理设置http缓存头（如Cache-Control: max-age=...）。但问题来了，如果模块内容更新了怎么办？这时候就需要版本控制。通常的做法是在文件名中加入内容的哈希值，比如my-module.abc123.js。这样，只要文件内容不变，哈希值就不变，浏览器就继续使用缓存；一旦内容有任何改动，哈希值就会变，文件名也随之改变，浏览器就会下载新版本，完美避开缓存问题。
为什么现代Web开发倾向于使用ESM而非传统脚本？
说实话，这其实是个老生常谈的话题，但仔细想想，ESM之所以能成为主流，绝不仅仅是“新”那么简单。它解决了一堆传统脚本时代让人头疼的问题，带来了一种更优雅、更健壮的开发范式。
首先，最核心的就是作用域隔离。传统脚本加载后，所有变量和函数都默认挂载到全局对象（通常是window）上。这意味着如果你不小心，两个不同的脚本可能会定义同名的变量或函数，从而互相覆盖，导致难以追踪的bug。ESM则完全不同，每个模块都有自己的私有作用域，模块内部声明的变量和函数，除非明确export，否则外部是无法访问的。这就像把每个功能都封装在一个独立的“房间”里，房间之间通过明确的“门”（import/export）来交流，极大地减少了命名冲突和全局污染的风险。
其次，是依赖管理变得清晰明确。在传统脚本中，如果一个脚本依赖另一个脚本，你必须手动确保它们在HTML中的加载顺序。一旦顺序错了，或者依赖关系复杂起来，维护起来简直是噩梦。ESM通过import和export语句，将模块间的依赖关系以声明式的方式清晰地表达出来。你只需要import你需要的东西，浏览器或构建工具会负责解析依赖图，确保模块以正确的顺序加载和执行。这让代码的组织结构一目了然，也更容易进行静态分析和优化（比如后面要说的Tree Shaking）。
再者，ESM天生就是异步加载的。当你使用
还有一些细节，比如ESM默认在严格模式下运行，这有助于我们编写更规范、更少错误的JavaScript代码。它还天然支持CORS，这意味着你可以从不同的域名安全地加载模块，这对于CDN部署或者微前端架构来说非常方便。
最后，不得不提的是Tree Shaking（摇树优化）。由于ESM明确的import/export机制，构建工具能够更容易地分析出哪些代码被实际使用了，哪些是多余的。它能像摇晃一棵树一样，把那些“枯叶”（未使用的代码）摇掉，最终打包出来的文件会更小，进一步提升加载性能。传统脚本由于其全局作用域的特性，很难实现如此高效的代码剔除。
动态导入（import()）在实际项目中通常应用于哪些场景？
动态导入，也就是import()函数，它的灵活性和异步特性让它在很多实际项目中都扮演着关键角色，特别是在追求高性能和优秀用户体验的场景下。
一个非常典型的应用就是路由懒加载。在单页应用（SPA）中，我们通常会有很多页面或视图。用户初次访问时，并不需要加载所有页面的代码。通过动态导入，我们可以将每个页面的组件或模块拆分成独立的块，只在用户导航到该路由时才去加载对应的代码。比如，在React router或vue Router中，你经常会看到这样的写法：
// React Router 示例 const HomePage = React.lazy(() => import('./pages/Home')); const AboutPage = React.lazy(() => import('./pages/About')); // Vue Router 示例 const routes = [ { path: '/home', component: () => import('./views/Home.vue') }, { path: '/about', component: () => import('./views/About.vue') } ];
这能显著减少初始加载的JavaScript包大小，让首屏渲染更快。
其次，组件或功能模块的懒加载也是非常普遍的。有些组件可能很复杂，包含大量的逻辑和第三方库，但它们并非页面加载时就必须展示。例如，一个富文本编辑器、一个地图组件、一个大型图表库，或者一个不常用的管理后台功能。你可以把这些组件封装成独立的模块，只有当用户点击某个按钮、滚动到某个区域或者触发特定事件时，才通过import()去加载它们。
// 假设有一个按钮，点击后加载图表库 document.getElementById('loadChartBtn').addEventListener('click', async () => { try { const { default: Chart } = await import('chart.js'); // 动态加载 Chart.js const ctx = document.getElementById('myChart').getContext('2d'); new Chart(ctx, { /* ... */ }); } catch (error) { console.error('加载图表失败:', error); } });
这能避免在用户不需要时就加载和解析这些沉重的功能。
再来，条件加载也是动态导入的一个重要应用。有时，你可能需要根据用户的权限、浏览器特性、设备类型或者A/B测试的结果来加载不同的模块。比如，你可能只在旧版浏览器中加载特定的polyfill，或者只在特定用户组中加载一个实验性的新功能。
// 根据浏览器特性加载不同的模块 if (typeof IntersectionObserver === 'undefined') { // 如果浏览器不支持 IntersectionObserver，则动态加载 polyfill import('intersection-observer-polyfill').then(() => { console.log('IntersectionObserver polyfill loaded.'); }); }
最后，它也常用于处理用户交互触发的模块加载。比如，一个大型的弹窗或者模态框，里面的内容和逻辑可能很复杂。你可以在用户点击打开弹窗的按钮时，才去动态加载这个弹窗组件的JS和css。这样，用户在页面加载时就不会被这些不必要的资源拖慢。
除了import策略，还有哪些辅助手段可以进一步提升模块加载性能？
虽然import相关的策略是优化模块加载性能的核心，但整个Web性能优化是一个系统工程，还有很多辅助手段可以从不同层面进一步提升模块的加载效率和用户感知速度。
一个非常基础但极其有效的手段是启用HTTP/2或HTTP/3。HTTP/1.1时代，浏览器对同一个域名的并发请求数量是有限制的，这导致很多小文件（比如模块）需要排队下载。HTTP/2引入了多路复用（Multiplexing），允许在单个TCP连接上并行发送多个请求和响应，极大地减少了延迟。HTTP/3更进一步，基于udp的QUIC协议解决了队头阻塞问题，在网络不稳定的环境下表现更佳。这意味着你的多个模块文件可以几乎同时被传输，而不是一个接一个。
其次，CDN（内容分发网络）的运用是不可或缺的。将你的静态资源（包括JavaScript模块文件）部署到全球各地的CDN节点上，用户访问时，CDN会自动选择离用户最近的节点提供服务。这能显著缩短资源传输的物理距离，减少网络延迟，让模块文件更快地到达用户浏览器。对于跨国或跨区域的用户群体，CDN的效果尤为明显。
文件本身的优化也很重要，比如Gzip或Brotli压缩。在服务器端对JavaScript文件进行压缩，可以大大减小文件传输的大小。浏览器下载的是压缩后的文件，然后在本地解压。Brotli通常比Gzip有更高的压缩率，能进一步减少传输量。这就像是把一个大包裹先压扁了再寄送，能省下不少运费和时间。
再者，资源优化（Minification & Uglification）是前端构建流程中的标配。通过工具（如Terser）移除JavaScript代码中的空格、注释、换行符，缩短变量名和函数名，甚至进行一些代码优化。这能让最终的JavaScript文件体积变得更小，从而加快下载速度和解析时间。虽然对模块逻辑本身没有影响，但对传输效率的提升是实实在在的。
别忘了Service Workers。它们提供了一个强大的网络代理层，允许你拦截网络请求并缓存资源。通过Service Worker，你可以实现更精细的缓存策略，比如“网络优先”或“缓存优先”，甚至在用户离线时也能提供部分功能。对于已经访问过的模块，Service Worker可以从缓存中直接提供，完全跳过网络请求，实现近乎瞬时的加载体验。这对于提升二次访问性能和离线可用性是至关重要的。
最后，DNS预解析（）也是一个小而美的优化点。如果你的模块需要从不同的域名加载（比如CDN或者第三方库），你可以提前告诉浏览器去解析这些域名，这样当实际需要建立连接时，DNS解析的耗时就已经被消除了。
<link rel="dns-prefetch" href="//cdn.example.com"> <link rel="preconnect" href="https://api.example.com">
这些辅助手段与import策略协同作用，共同构建了一个高效、流畅的模块加载体系，让用户在访问你的Web应用时，能感受到更快的响应速度和更优质的体验。
