答案：浏览器加载外部JavaScript文件最直接的方式是通过HTML的标签，其行为受放置位置及async、defer属性影响。将脚本置于中会阻塞DOM构建，导致白屏；放在前可减少阻塞。使用async实现异步下载、下载完成立即执行，适用于无依赖的独立脚本；defer实现异步下载、延迟至DOM解析完成后按序执行，适合依赖DOM或有顺序要求的脚本。动态创建script标签可实现按需加载，不阻塞解析，适合条件加载。ES模块通过type="module"引入，具有defer特性，支持import/export语法。加载方式直接影响页面性能：阻塞式加载拖慢渲染，影响FCP和LCP；大体积脚本增加TBT，导致卡顿；过多请求增加网络开销；依赖错误引发运行异常；缺乏缓存则重复下载。优化实践包括：合理使用async/defer、脚本后置、代码分割、按需加载、压缩、CDN分发、强缓存策略、预加载与预获取、Tree Shaking、避免臃肿库、耗时任务移至Web Worker。综合运用可显著提升加载速度与用户体验。
浏览器加载外部JavaScript文件，最直接的方式就是通过HTML中的
<script>标签。当浏览器解析HTML文档遇到这个标签时，它会暂停DOM的构建，然后去请求并下载这个外部JS文件，下载完成后立即解析并执行其中的代码，之后才会继续HTML的解析。这个过程，简单来说，就是“停下来，拿过来，跑起来，再继续”。
解决方案
要让浏览器加载外部JS文件，我们主要有几种做法，每种都有其适用场景和需要考量的地方。
最常见且基础的方法，就是直接在HTML中插入
<script>标签，并指定
src属性指向JS文件的URL。
<!-- 放在 <head> 标签内 --> <script src="path/to/your-script.js"></script> <!-- 放在 <body> 标签闭合前 --> <script src="path/to/another-script.js"></script>
这种方式，如果脚本放在
<head>里，它会阻塞页面的渲染，直到脚本下载、解析并执行完毕。这在过去是个大问题，尤其对于体积大的脚本，用户会看到白屏。所以，很多时候我们会建议将脚本放在
</body>闭合标签之前，这样至少HTML内容可以先呈现出来。
但仅仅放到
</body>前还不够，为了更好地优化加载性能，我们引入了
async和
defer这两个属性。
-
<script async src="path/to/async-script.js"></script>
- 带有
async
属性的脚本，浏览器会异步下载它，即在下载的同时继续解析HTML文档。一旦下载完成，HTML解析就会暂停，脚本立即执行。执行完毕后，HTML解析继续。它的执行顺序不确定，哪个脚本先下载完哪个就先执行。
- 带有
-
<script defer src="path/to/defer-script.js"></script>
- 带有
defer
属性的脚本，浏览器也会异步下载它，同时继续解析HTML。但与async
不同的是，defer
脚本的执行会推迟到HTML文档解析完成后、DOMContentLoaded
事件触发之前。并且，多个defer
脚本会按照它们在文档中出现的顺序依次执行。
- 带有
除了直接在HTML中声明，我们也可以通过JavaScript动态地创建并加载脚本：
const script = document.createElement('script');
script.src = 'path/to/dynamic-script.js';
script.onload = () => {
console.log('脚本加载并执行完毕！');
// 可以在这里执行依赖此脚本的代码
};
script.onerror = () => {
console.error('脚本加载失败！');
};
document.head.appendChild(script); // 或者 document.body.appendChild(script);这种动态加载的方式非常灵活，可以根据条件按需加载脚本，避免一次性加载所有不必要的资源。它默认是异步的，不会阻塞HTML解析，但需要手动处理加载完成或失败的回调。
最后，如果你在用ES Modules，那么可以通过
<script type="module" src="path/to/module.js"></script>来加载。这种方式加载的脚本默认是
defer行为的，也就是异步下载，延迟到HTML解析完毕后按序执行，并且在模块内部可以使用
import和
export语法。
<script defer>
和 <script async>
有什么区别？
这真的是一个老生常谈但又极其重要的问题，尤其是在前端性能优化里。简单来说，两者都是为了解决传统
<script>标签阻塞HTML解析的问题，让脚本的下载不再卡住页面的渲染。但它们在执行时机和顺序上有着本质的不同，理解这些差异能帮助我们更好地组织代码，提升用户体验。
想象一下浏览器在解析HTML文档，它就像一个勤劳的工人，一行一行地阅读指令。
当它遇到一个普通的<script src="...">
标签时，这个工人会放下手头的所有工作（HTML解析和DOM构建），先去网络上把这个脚本文件“搬”回来，然后“读懂”（解析）并“照做”（执行）里面的所有指令。等脚本执行完了，他才继续回来解析HTML。这就像你在看书时，突然被一个电话打断，你必须把电话接完才能继续看书。这种“停下来”的行为，就是我们常说的渲染阻塞。
现在来看<script async src="...">
。当工人遇到它时，他不会停下，而是会派出一个“小弟”去后台异步下载这个脚本。工人自己继续解析HTML。一旦这个“小弟”把脚本下载回来了，不管工人手头在做什么，他都会立刻停下来，先执行这个脚本。执行完后，再继续之前的工作。这意味着：
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
- 下载是异步的。
- 执行是阻塞的，但阻塞的是执行点那一刻的HTML解析。
-
多个
async
脚本的执行顺序是不确定的，哪个先下载完哪个就先执行。这对于那些相互独立、不依赖DOM或不依赖其他脚本的工具型脚本（比如分析统计脚本）非常适用。
再看<script defer src="...">
。工人遇到它时，同样会派“小弟”去后台异步下载脚本，自己也继续解析HTML。但不同的是，即使脚本下载回来了，“小弟”也不会立刻打断工人。他会等到工人把整个HTML文档都解析完毕了（DOM构建完成），然后才开始执行这些
defer脚本。而且，如果有多个
defer脚本，它们会严格按照在HTML中出现的顺序依次执行。这就像你收到一个快递，但你决定等把手头的工作都忙完了，再统一拆开并处理这些快递。这意味着：
- 下载是异步的。
- 执行是延迟的，且不会阻塞HTML解析，只会在HTML解析完成后、
DOMContentLoaded
事件之前执行。 -
多个
defer
脚本的执行顺序是按照它们在文档中的顺序。这对于那些依赖DOM、或者有前后依赖关系的脚本非常有用，因为它保证了DOM是完整的，并且脚本的执行顺序可控。
总结一下核心区别：
-
async
： 下载异步，执行阻塞（一旦下载完成就执行），执行顺序不保证。适用于独立、不依赖DOM的脚本。 -
defer
： 下载异步，执行延迟（HTML解析完后），执行顺序保证（按文档顺序）。适用于依赖DOM或有依赖关系的脚本。
我个人在使用时，如果脚本之间没有明确的依赖关系，且不关心执行顺序，我会倾向于使用
async，因为它能让脚本尽早执行。但如果脚本需要操作DOM，或者有严格的执行顺序要求，
defer几乎是我的首选，因为它既保证了异步下载，又确保了DOM的可用性和脚本的有序执行。
外部JS文件加载会如何影响页面性能和用户体验？
外部JS文件的加载方式对页面性能和用户体验的影响是巨大且多方面的，这不仅仅是“快一点慢一点”那么简单，它直接关系到用户看到内容的速度、页面交互的响应性，甚至用户的耐心和去留。
首先，最直接的影响就是渲染阻塞。如果我们在HTML的
<head>中使用了没有
async或
defer属性的普通
<script>标签，浏览器在下载和执行这个脚本时，会暂停对HTML文档的解析和DOM的构建。这意味着，用户在脚本执行完成之前，可能只会看到一个空白的屏幕。想象一下，你打开一个网站，等了几秒钟才看到内容，这种体验是非常糟糕的，尤其是在网络条件不佳的情况下。这直接影响了首次内容绘制（FCP）和最大内容绘制（LCP）这两个核心Web Vitals指标。
其次，脚本的执行时间也是一个大问题。即使脚本是异步加载的，如果脚本代码量巨大、逻辑复杂，或者存在大量同步计算，它依然会占用主线程。当主线程被长时间占用时，页面就无法响应用户的输入（点击、滚动等），导致页面卡顿、无响应。这种现象在性能指标中常被称为总阻塞时间（TBT），它严重损害了页面的交互性和用户体验。用户会觉得页面“卡住了”或者“死机了”。
再者，网络请求的开销不容忽视。每个外部JS文件都需要发起一次HTTP请求。请求越多，建立连接、传输数据的时间就越长。虽然现代浏览器通常会进行并发请求，但请求数量过多、文件体积过大，都会增加网络延迟，尤其是在移动网络环境下。这直接拖慢了页面资源的整体加载速度。
还有，脚本的依赖关系处理不当也会引发问题。如果一个脚本依赖于另一个脚本或特定的DOM结构，但它却先执行了，那么就会导致运行时错误。例如，一个操作DOM的脚本在DOM还没完全构建好之前就执行了，就会报错，轻则功能失效，重则导致整个页面崩溃，这无疑是灾难性的用户体验。
async和
defer就是为了解决这类问题而生的，它们提供了更精细的控制。
最后，缓存策略也影响深远。如果外部JS文件没有设置合理的缓存策略（如
Cache-Control），用户每次访问页面都需要重新下载这些文件，这不仅浪费了用户的流量，也增加了加载时间。良好的缓存策略能让用户在二次访问时，从本地缓存中快速获取JS文件，显著提升加载速度。
因此，我们在处理外部JS文件时，需要像外科医生一样精准，仔细权衡其对性能和用户体验的潜在影响。不恰当的JS加载策略，就像在高速公路上设置了无数个减速带，让用户寸步难行。
优化外部JS文件加载有哪些最佳实践？
要优化外部JS文件的加载，提升页面性能和用户体验，我们有许多策略可以采用。这不仅仅是技术细节，更是一种对用户体验的深刻理解和责任感。
合理利用
async
和defer
属性： 这是最基本也是最有效的优化手段。对于那些不依赖DOM、相互独立的第三方脚本（如统计代码、广告脚本），使用async
可以确保它们尽快下载并执行，而不会阻塞页面渲染。对于那些依赖DOM、或有特定执行顺序要求的业务逻辑脚本，使用defer
能保证它们在HTML解析完成后、DOM就绪时按序执行，同时不阻塞初期渲染。这是我个人在项目中最常使用的策略，它能显著改善用户看到的白屏时间。将脚本放在
</body>
闭合标签之前： 对于那些既不能用async
也不能用defer
（比如一些老旧的库，或者必须同步执行的脚本），或者你就是想确保DOM先构建完成，那么将这些脚本放在</body>
标签之前是一个稳妥的选择。这样可以确保HTML内容和CSS样式能够优先加载和渲染，让用户能尽快看到页面的骨架。代码分割（Code Splitting）与按需加载（On-demand Loading）： 不是所有JS代码在页面加载时都需要。利用Webpack、Rollup等构建工具进行代码分割，将大的JS包拆分成更小的、按需加载的块（chunks）。例如，只有当用户点击某个按钮或导航到特定路由时，才加载对应功能的JS代码。这能大大减少初始加载的JS体积，加快页面启动速度。动态
import()
语法在现代JS中提供了原生的按需加载能力。精简（Minification）与压缩（Compression）： 通过移除代码中的空格、注释、缩短变量名等方式进行精简，再通过Gzip或Brotli等算法对JS文件进行压缩，可以显著减小文件体积，从而减少网络传输时间。这几乎是所有生产环境项目都会做的基础优化。
使用CDN（内容分发网络）： 将JS文件部署到CDN上，可以利用CDN在全球范围内的节点，让用户从离他们最近的服务器获取资源。这不仅能减少网络延迟，还能利用CDN更强大的缓存能力和带宽，加速文件传输。
缓存策略： 通过设置HTTP响应头中的
Cache-Control
和Expires
，让浏览器能够缓存JS文件。对于不经常变动的文件，可以设置较长的缓存时间，用户在二次访问时就能直接从本地缓存中加载，避免不必要的网络请求。对于需要更新的文件，可以通过文件名加哈希值（app.123abc.js
）的方式实现版本控制和缓存失效。-
预加载（Preload）与预获取（Prefetch）：
-
Preload
： 使用<link rel="preload" as="script" href="critical.js">
来告诉浏览器，这个JS文件在当前页面是必需的，请尽快下载，但不要执行。这对于那些在HTML中出现较晚，但又对页面功能至关重要的脚本非常有用。 -
Prefetch
： 使用<link rel="prefetch" as="script" href="next-page.js">
来告诉浏览器，这个JS文件可能在用户接下来的导航中需要，可以在浏览器空闲时偷偷下载。这对于优化用户从当前页面跳转到下一个页面的体验很有帮助。
-
移除不必要的代码（Tree Shaking）和死代码（Dead Code Elimination）： 利用构建工具的Tree Shaking功能，只打包项目中实际用到的模块和函数，移除未使用的代码。这能有效减小JS包的体积。
避免使用过大的第三方库： 在引入第三方库时，评估其体积和必要性。有时一个小的自定义实现或者使用更轻量的替代方案，比引入一个功能强大但体积庞大的库更划算。
Web Workers： 对于需要大量计算且耗时的JS任务，可以将其放到Web Worker中执行。Web Worker在独立的线程中运行，不会阻塞主线程，从而保证页面的响应性。
这些策略并非相互独立，而是可以组合使用的。我的经验是，从最基础的
async/defer和代码分割开始，结合CDN和缓存，就能解决大部分性能问题。之后再根据具体项目需求，深入到预加载、Web Workers等更高级的优化手段。
