深入解析script的defer属性：避开那些意想不到的“坑”

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

说起提升页面性能，defer属性绝对是前端开发者工具箱里的老朋友了。关于“它能让脚本延迟执行”这一点，大家多少都听说过。但如果你真觉得只要加上defer就万事大吉，那可能已经踩在了一些微妙的“坑”边。

defer 属性只对外部脚本有效

先来看一个最容易被忽略的基本规则：defer只认外部脚本。什么意思？如果你给一个内联的标签加上defer，浏览器压根儿不会理会这个属性，只会当它不存在。脚本会立刻执行，不会有任何延迟效果。

真正触发defer行为的，必须是带src属性引入的外部脚本，比如。不少人在这里栽过跟头，满心以为加了defer就能把脚本执行时机牢牢掌控，结果却发现内联的逻辑依然在HTML解析中途就“跑”了起来，打乱了DOM就绪的预期。

所以，记住这几个关键点：

• 必须同时满足两个条件：既有src属性，又有defer属性。
• 禁止使用document.write()：在defer脚本里调用这个方法，要么直接报错，要么静默失败，绝对要避免。
• 顺序保证：页面中多个defer脚本，会严格按照它们在HTML中间出现的顺序执行，这点和async有根本性的不同。

defer 和 DOMContentLoaded 的关系很紧密

defer脚本的执行时机，一直是个精准的时间点问题。准确地说，它发生在HTML解析完成、DOM树构建完毕之后，但在DOMContentLoaded事件触发之前。这意味着，你在defer脚本里写任何DOM操作——无论是访问document.body还是使用querySelector——都是绝对安全的，完全不需要额外监听DOMContentLoaded事件。

不过，这里有个“前提”需要警惕：如果页面里还混杂了其他非defer脚本，比如普通的内联脚本或者带async的脚本，它们可能会抢跑，提前修改了DOM或者注册了监听器。这样一来，defer脚本执行时看到的DOM状态，可就不完全是那个“新鲜出炉”的原始状态了。

简单总结就是：

• defer脚本既不阻塞HTML解析，也不阻塞页面渲染。
• 它的执行时机，可以粗略理解为“DOM一就绪，它就立刻执行”。
• 别把它和window.onload搞混，后者要等到所有图片、样式表等资源都加载完毕才会触发。

defer 和 async 的关键区别不止是执行时机

defer和async这对兄弟经常被拿来比较，最常被提到的一句话是“它们都不阻塞解析”。但区别远不止于此。最关键的不同在于：defer会严格保证脚本的执行顺序，并且耐心等待DOM就绪；而async则是“谁先下载完，谁就先执行”，既不顾及顺序，也不管DOM是否准备好了。

典型的踩坑场景是这样的：你有两个存在依赖关系的外部脚本，比如a.js（定义了一些工具函数）和b.js（需要调用这些函数）。如果给它们都加上async，那么一旦b.js先下载完，它就会立刻执行，结果必然是报错：undefined is not a function。把属性换成defer，问题迎刃而解，顺序得到保证。

选择何时用谁，其实有个简单的原则：

• 用async：适合完全独立、不操作DOM、也不依赖其他脚本的代码，比如统计分析脚本或广告SDK。
• 用defer：适合需要操作DOM，或者脚本间有明确依赖关系的业务代码。
• 注意：两者不能共存于同一个