HTML中async和defer属性的区别与使用场景

在脚本标签上随手加上 async 或 defer，很多时候被当作一种性能优化的“仪式”。但真相是，用错了它们，不仅不会提速，反而会埋下隐患。轻则控制台报出 document.getElementById is not a function，重则导致核心业务逻辑失效、关键埋点数据漏报，甚至让页面白屏时间翻倍。所以，核心原则不是“加了就快”，而是“加对才稳”。

什么时候脚本执行会报 document.querySelector 返回 null？

这个问题堪称前端开发中的“经典报错信号”。其根源非常明确：脚本试图访问某个DOM元素，但浏览器解析HTML的进度条，还没走到那个元素的位置。这通常发生在错误地使用了 async，或者干脆什么属性都没加的情况下。

• async 脚本：它的行为是“下载完成，立即执行”。一旦脚本下载完毕，它会立刻中断浏览器的HTML解析过程，抢跑执行。此时， 可能只解析了一半，你代码里写的 #app 根节点，在DOM树里根本还不存在。
• defer 脚本：它的策略是“耐心等待”。它会等到整个HTML文档被完全解析、DOM树构建完成之后，才按顺序执行。因此，在执行 defer 脚本时，document.body 以及所有在HTML中定义的元素都已是“可访问状态”。
• 无属性脚本：这其实是最危险的情况。默认的 这样的代码，并不会延迟执行，而是会立刻执行。另外，现代构建工具（如Vite）生成的 type="module" 脚本，默认就具有 defer 的行为。此时再手动添加 defer 属性，虽然不会报错，但也没有任何额外效果。

async 真的“谁下完谁先执行”吗？

是的，这就是 async 最核心的行为：下载完毕，立刻执行，先到先得。这个“立刻”有多快呢？它可能发生在DOM构建的中途，甚至极端情况下，在 标签刚被解析时，如果脚本已经下载好了，它就会立刻执行。

立即学习“前端免费学习笔记（深入）”；

• 适用场景非常特定：通常只有三类脚本适合用 async：网站分析脚本（如 analytics.js）、错误追踪脚本（如 error-tracking.js）以及广告加载脚本（如 ads.js）。它们的共同点是：不操作DOM、不依赖其他JS、也不被其他JS依赖。
• 依赖是禁忌：多个 async 脚本之间绝对不能存在调用关系。否则，你可能会遇到 utils.init() 这个函数调用，在 utils.js 文件本身加载完成之前就执行了的诡异错误。
• 属性互斥：当 async 和 defer 同时出现在一个