在网页性能优化领域，脚本的加载策略是个绕不开的话题。其中，defer和async这两个属性，常常让开发者感到困惑。表面上看，它们都让脚本不阻塞HTML解析，但背后的执行时机和顺序保障机制，却有着天壤之别。

简单来说，判断它们影响的关键，不在于代码里“谁先写”，而在于浏览器里“谁什么时候真正开始跑”。一个耐心等待，一个火急火燎，这直接决定了你的页面初始化逻辑能否顺利执行。

defer：秩序井然的“排队者”

给脚本加上defer属性，就等于告诉浏览器：“别急，等整个页面结构（DOM）都搭好了，再按顺序叫我。” 所以，所有带defer的脚本，都会在HTML文档被完全解析、DOM树构建完毕之后，才统一执行，并且这个执行动作发生在DOMContentLoaded事件触发之前。

这意味着什么？意味着你可以放心地在这些脚本里使用document.getElementById或querySelector来操作元素，因为执行时DOM已经就绪了。

• 顺序有保障：多个defer脚本严格按照它们在HTML中间出现的顺序执行。哪怕后面的脚本先下载完，也得乖乖等前面的执行完毕。
• 时机明确：执行窗口非常清晰，就在DOM构建完成后、页面“DOM就绪”事件触发前。

因此，defer非常适合那些依赖DOM结构的初始化代码，比如表单验证、绑定事件监听器，或者需要操作页面元素的组件加载逻辑。

async：争先恐后的“抢跑者”

async脚本的性格就截然不同了。它的信条是“下载完就执行，一刻也不等”。一旦某个async脚本下载完成，浏览器会立即暂停当前的HTML解析（如果还在进行的话），转而去执行这个脚本。

这就带来了两个核心特征：执行时机不可预测，以及脚本间没有顺序保证。

• 顺序无保障：谁先下载完，谁就先执行。即使脚本B写在脚本A后面，只要B下得快，它就能抢在A前面执行。
• DOM可能未就绪：脚本执行时，DOM很可能还在构建中。如果你在脚本里尝试获取某个元素，很可能会得到一个null。

所以，async通常用于那些完全独立、不依赖DOM也不依赖其他脚本的代码块，比如网站分析统计（埋点）、广告加载SDK，或者一些自包含的功能模块。

如何一眼看穿执行时机？

理论说了不少，实战中怎么验证呢？打开浏览器的开发者工具，切换到Network（网络）面板，然后刷新页面，观察JS文件的“Waterfall”（瀑布流）时间轴：

• 识别defer：你会看到defer脚本的下载条很早出现（与HTML解析并行），但代表执行开始的那条小竖线或“Execute”标记，会明显出现在所有HTML解析完成之后、DOMContentLoaded事件触发之前的那段空隙里。
• 识别async：async脚本的下载条同样出现得早，但它的执行标记几乎紧贴着下载完成的瞬间，并且这个标记可能出现在瀑布流的任何位置，穿插在HTML解析的各个阶段。
• 结合验证：你还可以在脚本里加入console.log输出调试信息，同时在Performance（性能）面板里观察DOMContentLoaded和load事件的时间点，几方对照，就能把执行顺序摸得清清楚楚。

几个容易踩坑的误区

最后，有几个常见的误判点值得特别注意：

首先，别被标签的书写位置迷惑。async脚本不会因为写在前面就一定先执行；defer脚本也不会因为某个脚本网络慢就被跳过。真正定夺执行节奏的，是浏览器内部根据属性制定的调度规则。

其次，如果一个