script 的 defer 与 async 区别：为什么头部脚本拿不到 DOM 元素

约 6 分钟读完 · 更新于 2026-10-21 · 文中每条都能在下面的配套工具里动手验证

一句话结论：要有序用 defer，要独立用 async，默认同步最危险

浏览器解析 HTML 遇到 <script src> 时默认会停下来：下载并执行完才继续。defer 让脚本在 HTML 解析完后、DOMContentLoaded 之前按顺序执行；async 则是下载完立刻执行、顺序不保证。头部脚本拿不到元素，就是因为默认脚本在 DOM 构建完成之前就执行了。

五种写法一张表看清

选型前先看清每种的阻塞行为、执行时机与顺序保证。

三种加载方式写法对照

<!-- 1. 默认：阻塞解析，头部慎用 -->
<script src="/app.js"></script>

<!-- 2. async：下载不阻塞，下载完立即执行，顺序不保证
     适合独立脚本：统计、广告 -->
<script async src="/analytics.js"></script>

<!-- 3. defer：不阻塞，解析完后按顺序执行
     适合有依赖关系的主脚本 -->
<script defer src="/vendor.js"></script>
<script defer src="/app.js"></script>

为什么头部脚本 getElementById 返回 null

document 按顺序解析，<head> 里的普通脚本执行时，<body> 里的元素根本还不存在，所以 getElementById 得到 null，接着给 null.addEventListener 就报「Cannot read properties of null」。这不是加载问题，是执行时机问题：代码跑得比 DOM 快。

DOMContentLoaded：等 DOM 就绪再动手

// defer 脚本执行完之后才触发 DOMContentLoaded，
// 所以 defer 脚本里通常不需要再监听它
document.addEventListener('DOMContentLoaded', () => {
  const btn = document.getElementById('submit');
  btn.addEventListener('click', handleSubmit);
});

// window.load 更晚：还要等图片、样式表全部加载完
window.addEventListener('load', () => {
  console.log('所有资源加载完毕');
});

排查「脚本拿不到元素」四步

绝大多数情况卡在第 1 步和第 4 步。

1. 看报错行号对应的脚本在哪里加载：head 里还是在元素之后
2. 给脚本加上 defer 或移到 </body> 前，再刷新验证
3. 确认元素 id 拼写无误、没有被模板条件渲染掉（v-if、条件渲染）
4. 若元素是 JS 动态创建的，改为监听其父容器的事件委托，而不是直接绑定

现在的脚本放置建议

defer 早已全量支持，老习惯可以退休了。

• 首选：脚本全部放 <head> 并加 defer，HTML 写起来干净，下载也最早开始
• 独立第三方脚本（统计、广告）用 async，别让它排队
• 有严格依赖链的（先库后业务）用 defer，天然按顺序执行
• 不再推荐把脚本堆在 </body> 前：这是 defer 普及前的老习惯
• 需要极早执行的关键逻辑才考虑内联，普通逻辑别内联

动态插入的 script 默认是 async

用 JS 创建的 script 标签行为和静态写法不同：默认 async = true，顺序不保证。

const s = document.createElement('script');
s.src = '/chunk.js';
// 动态脚本默认 async = true，执行顺序不保证
// 要按顺序执行必须显式关掉
s.async = false;
document.head.appendChild(s);

一行修复：给头部脚本加上 defer

把 <script src="app.js"> 改成 <script defer src="app.js">，「Cannot read properties of null」大概率立刻消失。改完用 HTML 格式化工具检查标签与属性写法，再用兼容性查询确认 defer/async 的支持情况——早已是 100%。

常见问题