defer脚本在DOM解析完成、DOMContentLoaded触发前按序执行；仅对外部脚本有效，内联或动态插入的defer无效，且必须在HTML中声明。
defer 脚本不会在 DOM 解析完成前执行
不会。带有 defer 的 <script> 一定会等到整个 HTML 文档解析完毕（即 document.readyState === 'interactive' 或更准确地说，DOM 构建完成、DOMContentLoaded 触发前）才开始执行，且按书写顺序串行执行。
它和 async 的关键区别就在这里：async 下载完立刻执行（可能早于 DOM 构建完成），而 defer 保证 DOM 就绪、且脚本顺序不乱。
用 console.log + document.getElementById 验证 defer 是否生效
最直接的验证方式：在 defer 脚本里尝试访问一个位于该脚本下方的元素。如果能取到，说明 DOM 已就绪；如果为 null，说明脚本执行太早 —— 但 defer 不会出现后者。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在
<body>开头放一个<div id="test">hello</div> - 在
</body>前写：<script defer>console.log(document.getElementById('test'));</script> - 打开开发者工具 → Console，看到输出的是
<div id="test">…</div>（不是null），就确认 defer 生效了 - 对比去掉
defer后再试一次：若脚本放在<head>里且没加defer，大概率输出null
defer 脚本执行时机与 DOMContentLoaded 的关系
defer 脚本的执行时机紧邻 DOM 构建完成之后、DOMContentLoaded 事件触发之前 —— 它们属于同一轮微任务队列处理阶段，但严格来说，defer 脚本执行是 DOMContentLoaded 的前置条件之一。
验证方法：
- 在
defer脚本中打印document.readyState，结果一定是'interactive'（不是'loading'） - 注册
document.addEventListener('DOMContentLoaded', ...)，它的回调总在所有defer脚本执行完之后触发 - 注意：如果页面有同步脚本阻塞解析，或存在未关闭的标签导致解析延迟，defer 脚本也会被推迟 —— 它依赖 HTML 解析器的正常推进
容易被忽略的兼容性与嵌套陷阱
defer 只对外部脚本（带 src 属性）有效；内联脚本加 defer 会被浏览器忽略（HTML 规范明确要求）。
常见误用场景：
-
<script defer>console.log('hi');</script>→ 实际按普通同步脚本执行，defer无效 -
<script src="a.js" defer></script><script src="b.js"></script>→b.js会阻塞解析并立即执行，破坏a.js的 defer 顺序保障 - 动态插入的
<script defer>（如用document.createElement('script')）→defer属性不起作用，必须在初始 HTML 中声明
真正可靠的写法只有：<script src="xxx.js" defer></script>，且所有依赖脚本都加 defer，并确保它们出现在文档流中（不能靠 JS 动态注入）。
