async与defer加载差异测试指南

async和defer属性仅对带src的外部脚本生效，内联脚本添加二者完全无效——浏览器会直接忽略，仍立即执行并阻塞HTML解析，这是HTML规范明确要求且所有主流浏览器严格遵循的；当两者共存时，浏览器以async为准，导致脚本下载后即刻执行、可能打断DOM构建；多个defer脚本严格按HTML中书写顺序在DOMContentLoaded前执行，适合有依赖的模块链，而async脚本则无序执行，仅适用于完全独立的代码（如统计、广告）；尤其需警惕IE9–IE10的兼容陷阱：defer仅对静态写入的外部脚本可靠，动态插入或放在底部均可能退化为同步执行。真实项目中，加载行为是否符合预期不能只靠console.log判断，必须结合network timing与DOM就绪时间戳交叉验证，避免因构建工具误删src、老浏览器静默降级等隐蔽问题引发线上故障。

async 和 defer 在没有 src 的 script 标签里完全无效

直接说结论：async 和 defer 属性只对带 src 的外部脚本生效。如果 这种内联脚本加了这两个属性，浏览器会忽略它们，行为和没加一样——立即执行、阻塞 HTML 解析。

常见错误现象是：开发者在调试加载顺序时，给内联 ，会直接忽略 defer，按 async 行为处理：脚本下载不阻塞 HTML，但一旦下载完成就立刻执行，可能打断 DOM 构建。

这个细节容易被忽略，尤其在构建工具自动生成标签或多人协作改配置时。实际效果不是“先异步下载、再延迟执行”，而是彻底的异步执行。

• async 和 defer 语义冲突，规范要求以 async 为准
• 即使 async 脚本体积很小、下载极快，它仍可能在 中就执行，此时 document.body 可能还不存在
• 测试时可用 performance.getEntriesByType('resource') 查看真实下载/执行时间点，别只靠 console.log 推断

多个 defer 脚本严格按书写顺序执行，但 async 不保证

这是最常被拿来控制依赖关系的点：defer 脚本不仅延迟执行，还保持