async不能完全跳过脚本阻塞，仅绕过渲染阻塞：下载不阻塞HTML解析，但执行时仍暂停解析与渲染；defer更稳妥，按序执行于DOM构建后；模块脚本天然defer；真正消除阻塞需分离加载与执行。
async 属性真能跳过脚本阻塞吗
不能完全替代，但能绕过「渲染阻塞」——前提是脚本不依赖 DOM 初始化，也不被其他同步脚本依赖。async 让浏览器下载时不阻塞 HTML 解析，但一旦下载完成就立即执行，执行时仍会暂停解析和渲染。
常见错误现象：Uncaught ReferenceError: myFunc is not defined，因为 async 脚本比后续的内联脚本先执行，而后者可能调用了前者声明的函数。
-
async仅对<script src="..."></script>有效，对内联脚本无效 - 多个
async脚本的执行顺序不保证，哪怕它们在 HTML 中是按序写的 - 它不改变脚本自身的执行时机，只是把“下载”从阻塞流程中抽离出来
defer 比 async 更适合多数初始化场景
如果脚本要操作 DOM、或依赖 document.readyState === 'interactive'，defer 是更稳的选择。它同样不阻塞 HTML 解析，但会等到整个 HTML 解析完成、DOM 构建完毕后再统一按顺序执行。
使用场景：Vue/React 的挂载脚本、统计埋点、表单校验初始化等——只要不依赖 window.load 或图片加载完成，defer 几乎总是比 async 更安全。
立即学习“前端免费学习笔记（深入）”；
-
defer只适用于外部脚本（带src），且忽略type="module"的隐式 defer 行为 - 多个
defer脚本严格按 HTML 中出现顺序执行 - 在
DOMContentLoaded之前执行，但不会早于 DOM 构建完成
模块脚本（type="module"）自带 defer 效果
现代浏览器中，<script type="module" src="app.js"></script> 天然具有 defer 语义：不阻塞解析，按序执行，且自动启用严格模式和顶层 await 支持。
性能影响：模块脚本会触发额外的 CORS 请求（即使同源），且每个模块都是独立的执行上下文，闭包隔离更强，但也意味着不能靠全局变量通信。
- 不支持老版本 IE，需检查目标用户环境
- 动态导入
import('./utils.js')是真正的异步执行点，可用于按需加载逻辑 - 若混用
async和type="module"，async会被忽略——模块脚本不响应async属性
真正消除阻塞得靠加载策略+执行时机分离
光加 async 或 defer 只解决「下载阶段」的阻塞；脚本本身的长任务（如大型 JSON 解析、复杂计算）依然卡主线程。必须配合 requestIdleCallback、setTimeout(..., 0) 或 Web Worker 才能避免渲染掉帧。
容易被忽略的地方：第三方 SDK 往往默认用同步脚本注入自身 loader，比如某些广告或监控脚本，它们的 document.write 或立即执行函数会直接打断解析流——这时连 defer 都救不了，只能用 iframe 隔离或动态创建 script 标签并延迟插入。
