async脚本下载完立即执行，可能中断html解析且不保序；defer脚本等dom就绪后按序执行，确保可安全操作dom。
Async 和 defer 都能避免脚本阻塞 HTML 解析，但行为完全不同：async 适合完全独立的脚本（如统计、广告），defer 更适合依赖 DOM 的初始化逻辑。
async 属性的执行时机与典型误用
async 让浏览器异步下载脚本，一旦下载完成就立即执行，不保证执行顺序，也不等 DOM 构建完成。这意味着它可能在 document.readyState 还是 "loading" 时就运行，甚至在 里就触发执行。
- 常见错误：在 async 脚本里直接操作
document.getElementById或document.body，结果拿到null—— 因为 DOM 根本还没解析到对应节点 - 适用场景：纯功能型脚本，比如
analytics.js、ads.js，不读取或修改页面结构 - 多个 async 脚本之间无执行顺序保证，即使它们在 HTML 中前后排列，也可能因下载快慢导致执行颠倒
- 注意：async 只对
<script src="..."></script>生效，内联脚本（无src）加 async 会被忽略
defer 属性的加载与执行约束
defer 同样异步下载脚本，但强制推迟执行，直到整个 HTML 解析完成、document.readyState 变为 "interactive" 后才按书写顺序依次执行 —— 这是它和 async 最关键的区别。
- 必须搭配
src使用，内联脚本加 defer 无效 - 多个 defer 脚本严格按 HTML 中出现顺序执行，适合有依赖关系的模块（如先加载
utils.js，再执行app.js） - 它能安全访问完整 DOM，但不能等
DOMContentLoaded事件 —— 因为 defer 脚本执行时该事件通常尚未触发（除非 DOM 极其简单） - 兼容性好，IE10+ 均支持；但注意：如果脚本本身含
document.write，defer 会直接报错并中断执行
如何判断该用 async 还是 defer
核心看脚本是否需要操作 DOM、是否依赖其他脚本、是否可容忍执行时机不可控。
- 选
async：脚本无 DOM 依赖、无跨脚本调用、内容完全自包含（如埋点 SDK） - 选
defer：脚本需操作document或body、要按序执行、或作为主应用入口（如 React/Vue 挂载逻辑） - 都不选：脚本体积小（
- 混淆点：把
defer当成“延迟加载”，其实它仍会尽早下载；真正延迟加载要用import()动态导入
实际部署中容易被忽略的细节
真实项目里最常踩的坑不是选错属性，而是忽略了它们与文档解析流程的耦合关系。
- 放在
的defer脚本，其下载不阻塞解析，但它的执行仍会阻塞DOMContentLoaded—— 所以长耗时的 defer 脚本会让首屏可交互时间变慢 - async 脚本若触发了重排（如读取 offsetHeight 后又改样式），可能在 DOM 尚未稳定时造成额外渲染开销
- 服务端渲染（SSR）页面中，如果 defer 脚本里调用了
document.querySelector却没做存在性判断，可能因 SSR 生成的 HTML 结构差异而报错 - 构建工具（如 Webpack/Vite）默认生成的
<script></script>标签不含 async/defer，需要显式配置scriptLoading: "defer"或手动加属性
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
