17370845950

选 defer 还是 async 取决于脚本是否依赖 DOM 或其他脚本：defer 等 HTML 解析完按序执行，适合操作 DOM 或有依赖的外部脚本；async 下载完立即执行、无序，适合独立第三方脚本；默认同步加载会阻塞渲染，应避免。

选 defer 还是 async，关键看脚本是否依赖 DOM、是否依赖其他脚本，以及你是否希望它尽早执行但不阻塞页面渲染。

defer：等 HTML 解析完再按顺序执行

defer 会让脚本下载与 HTML 解析并行进行，但执行必须等到整个 HTML 文档解析完成（即 DOMContentLoaded 之前），且多个 defer 脚本严格按书写顺序执行。

• 适合：需要操作 DOM 的 JS（如初始化菜单、绑定事件），或有依赖关系的多个脚本（如先加载 jQuery，再加载插件）
• 注意：只对**外部脚本**（带 src）生效；内联脚本加 defer 会被忽略
• 示例： → 保证 a 先执行、b 后执行，且都在 DOM 构建完后运行

async：下载完就立

刻执行，不保证顺序

async 让脚本下载与 HTML 解析并行，但一旦下载完成，**立即中断 HTML 解析、执行该脚本**，执行时机不可控，多个 async 脚本之间无执行顺序保障。

• 适合：完全独立、不操作 DOM、不依赖其他脚本的逻辑（如统计埋点、广告加载、第三方 SDK）
• 注意：如果脚本中调用了 document.write 或直接读取未生成的 DOM 节点，很可能报错或失效
• 示例： → 尽快加载并上报访问数据，不影响首屏渲染

不写 defer/async：阻塞式加载（应避免）

默认行为是同步加载：浏览器遇到 会暂停 HTML 解析，等待脚本下载、执行完毕后再继续。这会显著拖慢首屏时间，尤其在网络慢或脚本大的情况下。

• 除非脚本极小、必须同步执行（如内联的 Polyfill 检测），否则不要省略加载策略
• 现代项目中，几乎所有的外部脚本都应明确指定 defer 或 async

一句话决策流程图

你的脚本是否：

• 需要访问或修改 DOM？→ 选 defer
• 和其他脚本有执行先后依赖？→ 选 defer
• 完全独立、越快执行越好、且不碰 DOM？→ 选 async
• 是内联脚本（没 src）？→ 不支持 defer/async，考虑外置或用 DOMContentLoaded 手动控制