defer脚本能安全操作DOM，因其严格在HTML解析完成、DOM构建完毕后且DOMContentLoaded事件触发前按文档顺序执行，此时document.body等元素已就位；async脚本下载完立即执行，可能在DOM未就绪时运行，导致document.body为null。
defer 和 async 都不阻塞 HTML 解析，但执行时机和顺序保障机制完全不同——选错一个，DOM 操作就可能报 document.body is null，脚本依赖也会直接崩。
defer 脚本为什么能安全操作 DOM？
因为 defer 脚本一定在 HTML 解析完成、DOM 构建完毕后执行，且严格按 <script> 在文档中出现的顺序排队运行，执行时 document.readyState 已是 interactive 或 complete。
- 多个
<script defer src="a.js">和<script defer src="b.js">会按 a → b 执行，b.js可放心调用a.js导出的函数 - 脚本内可直接写
document.getElementById('app')，不用包裹DOMContentLoaded监听器 - IE9 及更早版本中多个 defer 脚本有小概率乱序，生产环境需加兼容性兜底（如检查全局变量是否存在）
- 对内联脚本无效：
<script defer>console.log('hi')</script>的defer属性被忽略
async 脚本执行时机为什么不可控？
async 脚本下载完就立刻执行，此时 HTML 解析可能刚到一半，document.body 还没创建，甚至整个 <head> 都没闭合。
- 两个
<script async src="analytics.js">和<script async src="ads.js">谁先下完谁先跑，ads.js可能比analytics.js先执行 - 若脚本里写了
document.body.appendChild(...)，大概率触发TypeError: Cannot read property 'appendChild' of null - 必须主动判断：
if (document.body) { init() } else { document.addEventListener('DOMContentLoaded', init) } - IE10 以下不支持
async，旧项目需注意降级方案
混用 async/defer/同步脚本时，浏览器怎么调度？
三者完全独立：同步脚本阻塞解析；async 下载完就插队执行；defer 等解析完再排队。它们之间不协调、不等待，也不影响彼此下载优先级。
立即学习“前端免费学习笔记（深入）”；
- 预加载扫描器（preload scanner）能绕过 async/defer 脚本继续往下扫资源，所以把广告脚本设为
async，可能抢占关键 CSS 的带宽 -
type="module"脚本默认行为等价于defer，且不支持async（显式加会被忽略） - 通过
document.createElement('script')动态插入的脚本，默认表现类似async=true，顺序无法保证 - HTTP/2 推送的脚本不会触发预加载扫描，
async/defer属性可能失效，得配<link rel="preload">
什么时候该用 defer，什么时候必须用 async？
不是“哪个更快”，而是“依赖关系是否成立”——这是唯一决策依据。
- 必须用
defer：主应用入口（如main.js）、表单校验、菜单初始化——只要涉及document或依赖其他外部脚本输出 - 只能用
async：统计埋点（analytics.js）、广告 SDK（adsense.js）、社交分享按钮——完全独立、不改全局、不操作 DOM - 绝对禁用场景：脚本里含
document.write()；或通过innerHTML/document.write动态注入脚本——此时async/defer全部失效 - SSR 页面中，
defer仍可能太早：canvas 初始化、IntersectionObserver 绑定等需首屏渲染后动作，得靠requestIdleCallback或元素可见性检测来延迟
真正容易被忽略的不是属性本身，而是它们和 HTTP 缓存、模块类型、服务端推送、动态插入脚本之间的隐式耦合——同一份 HTML，在不同部署环境下行为可能不一致。
