HTML defer延迟加载脚本的详细方法与实现教程

说到脚本加载优化，defer属性几乎是前端工程师的必修课。但你真的了解它的全部规则吗？它并非一个“加了就万事大吉”的魔法开关，其行为背后有一套精确的浏览器规范。今天，我们就来彻底搞懂defer，避开那些看似不起眼、实则影响深远的“坑”。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

首先明确一点：defer的核心作用是延迟脚本执行，直到浏览器完成整个HTML文档的解析。这意味着，在defer脚本执行时，DOM树已经构建完毕，你可以安全地操作document.body或通过document.getElementById获取元素。但请注意，它不会等待样式表、图片或其他子资源加载完成，这个时机在DOMContentLoaded事件之前。

defer 只对外部脚本（src）有效

这是一个关键限制。defer属性只对带有src属性的外部脚本文件生效。对于内联脚本，浏览器会直接忽略defer属性，既不报错，也不会延迟执行。

• 错误示例： —— 这里的init()函数会在HTML解析器遇到该标签时立即执行，与不加defer时行为完全一致。
• 正确用法： —— 脚本的下载过程是异步的，不会阻塞HTML解析，而其执行则被推迟到DOM就绪之后。
• 注意细节：defer是一个布尔属性，即使你写成defer="false"，它依然会生效。最佳实践是只写属性名而不赋值。

多个 defer 脚本按 HTML 顺序执行，但依赖链必须写对

另一个重要特性是执行顺序的保证。所有带defer属性的脚本，会按照它们在HTML文档中间出现的顺序依次执行。但这“保序”指的是执行顺序，而非加载完成顺序。浏览器会并行下载这些脚本，谁先下载完并不影响最终的执行序列。

然而，这带来了一个常见的逻辑陷阱：执行顺序保序不等于依赖关系自动满足。如果你的app.js依赖于lodash.js提供的_变量，但HTML中app.js的标签却写在lodash.js前面，那么执行app.js时就会抛出ReferenceError: _ is not defined的错误。

• 正确顺序： →
• 错误顺序： →
• 混用警告：如果在同一个，如果该文件内包含document.write('

  ...

  ')，很可能导致页面渲染异常。
• 替代方案：应使用document.body.insertAdjacentHTML或document.createElement配合appendChild等DOM操作方法来实现动态内容插入。
• 数据注入注意：对于服务端渲染时注入的全局初始化数据（例如window.__INITIAL_STATE__），其脚本标签必须放在所有defer脚本之前，并且自身不能添加defer属性。否则，后续的defer脚本在执行时将无法读取到这些数据。

最后，一个容易被忽略的核心事实是：defer只管理脚本的执行时机，并不对脚本的执行结果负责。如果脚本文件因404路径找不到、被内容安全策略(CSP)拦截、或者脚本内部的动态import()失败，defer机制并不会拦截或重试这些错误。这些运行时问题，必须依靠代码内部的错误捕获和降级逻辑来妥善处理。