defer属性仅对外部脚本（含src属性）生效，执行于DOM构建完成之后、DOMContentLoaded事件触发之前，且按HTML顺序依次执行。

script 标签的 defer 属性到底什么时候生效

defer 只对**外部脚本**有效，也就是带有 src 属性的 <script></script> 标签。内联脚本（比如 <script>console.log('hi')</script>）写上 defer 完全被忽略，浏览器照常同步执行。

它生效的前提是：脚本必须通过 src 加载，且 HTML 文档中该标签不能有 type="module"（模块脚本默认具有类似 defer 的行为，但规则更严格）。

• ✅ 正确用法：<script src="app.js" defer></script>
• ❌ 无效写法：<script defer>init();</script>（内联，defer 被丢弃）
• ⚠️ 注意：<script type="module" src="app.js"></script> 自动延迟并按顺序执行，无需加 defer，加了也无害但冗余

defer 和 DOMContentLoaded 的执行顺序关系

defer 脚本会在 HTML 解析完成、DOM 构建完毕后，但在 DOMContentLoaded 事件触发前执行——准确说，是所有 defer 脚本按出现顺序依次执行完，才派发该事件。

这意味着：你在 defer 脚本里能安全访问 document.getElementById、querySelector 等 API，不需要额外监听事件或加 setTimeout。

• 如果页面有多个 defer 脚本，它们严格按 HTML 中的书写顺序执行
• 哪怕某个 defer 脚本下载慢，整个执行队列也会等它加载完再开始，不会“跳过”或“并发”
• DOMContentLoaded 一定在所有 defer 脚本执行完毕后才触发，可放心依赖

defer vs async：选错就可能读不到 DOM

async 是完全不同的机制：它不保证执行时机，只保证“下载不阻塞解析”，一旦下载完成就立刻执行，可能发生在 DOM 解析中途——此时 document.body 都可能还没创建，querySelector 直接返回 null。

而 defer 始终等到解析结束，适合操作 DOM 的初始化逻辑；async 更适合独立、无依赖的分析脚本（如埋点、广告 SDK）。

• 需要操作页面元素？用 defer，别用 async
• 脚本之间有依赖（如 jQuery + 插件）？只能用 defer（async 不保序）
• 想尽早加载又不关心 DOM？async 可能更快，但风险自担

常见失效场景和调试方法

如果你加了 defer 却发现脚本还是报 Cannot read property 'xxx' of null，大概率不是 defer 失效，而是脚本本身逻辑问题。

先确认是否真的用了外部脚本；再检查是否误把脚本放到了 里却依赖了 中尚未解析的元素（defer 确保 DOM 就绪，但不保证特定元素“已渲染完成”，比如动态插入的内容）。

• 用浏览器开发者工具的 Network 面板查看脚本是否带 defer 属性加载（Status 列旁会标 “Deferred”）
• 在脚本开头加 console.log(document.readyState)，应输出 interactive 或 complete
• 避免在 defer 脚本里直接操作 document.write，它会清空当前文档

真正容易被忽略的是：defer 不解决资源加载竞态（比如图片、iframe 还没加载完），也不推迟 CSSOM 构建。如果脚本依赖某个 img.naturalWidth 或 iframe.contentDocument，仍需单独监听对应事件。