HTML脚本阻塞取决于执行时机：无async/defer会同步阻塞解析；async仅异步下载但执行仍阻塞且无序；defer异步下载且按序在DOM解析后执行，最安全。
HTML 异步本身不会消除脚本阻塞，它只是把“阻塞点”从下载阶段转移到执行阶段，或干脆移出 HTML 解析主线程——关键看用的是 async 还是 defer，以及脚本是否依赖 DOM 或其他脚本。
不加 async/defer 的 script 为什么一定阻塞
浏览器解析 HTML 时，遇到没有 async 或 defer 的 <script> 标签，会立刻暂停 DOM 构建，同步下载、解析、执行脚本。哪怕脚本只有一行 console.log(1)，也会卡住后续所有 HTML 解析和渲染。
- DOM 构建中断 →
document.getElementById可能返回null - 页面白屏时间直线上升，尤其当脚本放在
<head>中 - 多个无属性脚本按顺序串行加载，总延迟 = 所有下载 + 执行时间之和
async 脚本执行时仍会阻塞 DOM 解析
async 只解决“下载不阻塞”，不解决“执行不阻塞”。脚本一旦下载完成，浏览器会立即中断当前 HTML 解析，执行该脚本。
- 执行时机不可控：谁先下完谁先执行，不保证顺序
- 若脚本 A 依赖脚本 B 声明的全局变量（如
lodash），async下可能报ReferenceError - 适合完全独立的脚本，比如统计代码、广告 SDK、错误监控 —— 它们不读 DOM、不改 DOM、不依赖其他 JS
- 注意：
async对内联脚本（无src）无效，只作用于外部脚本
defer 是更安全的“非阻塞主逻辑”方案
defer 让脚本异步下载，但**推迟到 DOM 解析完成后、DOMContentLoaded 触发前**，再按书写顺序执行。
立即学习“前端免费学习笔记（深入）”；
- 不阻塞 HTML 解析 → 页面能持续构建 DOM、逐步渲染
- 保证执行顺序：多个
defer脚本按<script defer src="a.js"></script>出现顺序执行 - 仅对带
src的外部脚本生效；内联脚本加defer会被忽略 - 适合主业务逻辑、Vue/React 初始化、需要操作完整 DOM 的代码
容易被忽略的细节和兼容性坑
很多人以为加了 async 或 defer 就万事大吉，其实还有几个硬性限制和隐性行为：
-
document.write()在async或defer脚本里会直接报错或清空整个页面，必须彻底移除 -
defer脚本在 IE9- 中被忽略，降级为同步加载；若需兼容老 IE，得靠动态插入或条件注释 - 服务器返回 404 的
defer脚本，会触发error事件但不中断后续脚本执行；而async404 同样不中断，但没机会重试 -
type="module"脚本默认表现类似defer（即使没写），但模块脚本之间有严格的依赖顺序和顶层 await 支持，别混用defer和type="module"
真正决定是否阻塞的不是“异步”这个词，而是脚本何时执行、是否依赖上下文、以及浏览器是否允许它插队。别只看有没有 async，得看它执行那一刻，DOM 是否 ready、变量是否已定义、用户是否还在等首屏内容。
