script放head里会阻塞渲染吗？defer和async解析

是的，script标签默认放在head中会严重阻塞HTML解析、DOM构建和页面渲染，导致白屏时间延长、首屏延迟等实际性能问题；而defer和async是打破这一阻塞的关键方案——defer适用于有执行顺序依赖的外链脚本，确保异步下载、DOM就绪后按序执行；async则适合完全独立、无依赖的第三方脚本（如统计、广告），但执行时机不可控且可能早于DOM就绪；现代最佳实践推荐将带defer的外链脚本统一置于body底部前，并谨慎应对无法修改的第三方阻塞脚本，通过预加载、资源提示或服务端渲染进行兜底优化。

script在head里默认会阻塞渲染和后续JS执行

是的，只要没加 defer 或 async，放在 里的 和 都默认阻塞，没有例外

defer只对外链脚本生效，且按顺序执行

defer 不会改变脚本执行时机，只改变执行时点：它让下载异步进行，但执行仍等到 HTML 解析完成、DOM 构建完毕后，再按 加了也当没加）

async适合无依赖的独立脚本，执行时机不可控

async 让下载完全异步，一旦下载完成就立刻执行，不等 HTML 解析结束，也不管其他脚本顺序。这意味着它可能在 DOM 还没准备好时就运行，也可能比早写的 defer 脚本先执行。

典型适用场景：

• 统计埋点（如 Google Analytics、神策）、广告 SDK
• 第三方工具（客服组件、分享按钮）
• 纯计算型逻辑，不操作 DOM、不依赖全局变量

容易踩的坑：

• 写了 async 还去查 document.getElementById —— 很大概率返回 null
• 两个 async 脚本之间有依赖（A 必须在 B 前执行），结果执行顺序随机，出错难复现
• Chrome DevTools 的 Network 面板里看不到 async 脚本的 “blocking” 时间，但实际仍占用主线程

现代项目更推荐把 script 放 body 底部 + defer 组合

虽然规范允许 defer 放在 ，但实践中更容易出问题：比如团队成员误删 defer，或者后来加了个没加属性的内联脚本，整个阻塞链就回来了。

更稳的做法：

• 所有外链 JS 都加 defer，统一放在 前（不是 ）
• 保留一个最小化的内联