defer 脚本在 html 解析完成后按序执行，可安全操作 dom；async 脚本下载完立即中断解析执行，执行时机不可控且无序；选择依据是是否依赖完整 dom 或脚本间顺序，而非文件大小。
长脚本加载时，defer 和 async 的行为差异会非常明显——不是“都异步”，而是“异步时机”和“执行时机”完全不同。关键不在下载快慢，而在浏览器如何调度执行。
defer：等页面解析完，再排队执行
即使脚本体积大、下载耗时长，带 defer 的脚本也不会打断 HTML 解析。浏览器一边继续构建 DOM，一边在后台下载脚本；等整个 HTML 解析完毕（DOMContentLoaded 触发前），才按顺序依次执行所有 defer 脚本。
- 执行一定发生在 DOM 完全就绪之后，可安全操作 任何元素
- 多个 defer 脚本严格按 HTML 中的书写顺序执行，哪怕 script2 比 script1 先下载完，也必须等 script1 执行完再轮到它
- 如果某个 defer 脚本卡住（比如内部有死循环或长时间同步计算），会延迟 DOMContentLoaded 触发，但不会影响页面视觉渲染进度
async：谁先下完谁先跑，不管 DOM 状态
async 脚本一旦下载完成，立刻中断当前 HTML 解析流程来执行它——哪怕此时
- 执行时机完全不可控：可能在 标签刚读完时就执行，也可能在 之后才执行
- 长脚本若下载慢，async 不会“等”，但短脚本若提前下完，就会抢在 DOM 构建中途插入执行，此时 document.body 可能还为 null
- 多个 async 脚本之间无执行顺序保障，scriptB 即使写在 scriptA 后面，也可能因体积小而先执行
对页面渲染的实际影响
两者都不阻塞下载阶段，但阻塞点不同：
- defer：只在 DOM 解析完成后集中阻塞一次（执行队列），且阻塞时间可控（所有脚本顺序执行）
- async：可能在解析过程中多次随机阻塞（每个脚本各自插队），导致渲染中断点分散、难以预测
- 长脚本配 async 时，若它恰好是第一个下载完的，会强制暂停解析、执行、再恢复——此时用户可能只看到
，其余内容全白屏
怎么选：看脚本是否依赖完整 DOM 或其他脚本
不看体积大小，看逻辑关系：
- 需要操作 document.getElementById('app')？→ 用 defer
- 脚本之间有 require 关系（如 jQuery + 插件）？→ 必须 defer
- 只是上报 PV、加载广告位、埋点 SDK？→ async 更合适，早执行早收集
- 脚本本身含 document.write()？→ 两种都禁用，它会清空当前文档
