是的，head中默认script会阻塞渲染和后续js执行；必须加defer或async才可避免，其中defer仅对外链脚本有效且保序执行，async则无序执行、适合无依赖脚本。
script在head里默认会阻塞渲染和后续JS执行
是的，只要没加 defer 或 async，放在 里的 <script></script> 就会同步下载、解析、执行——浏览器会暂停 HTML 解析，等它跑完才继续构建 DOM。这不是“可能阻塞”，而是规范行为。
常见现象包括：白屏时间长、首屏内容迟迟不出现、后续 <script></script> 被卡住不动。
实操建议：
- 非必要不放阻塞式
<script></script>在；如必须（比如早期埋点或 CSS-in-JS 初始化），优先考虑defer -
<script src="a.js"></script>和<script>console.log(1)</script>都默认阻塞，没有例外 - 即使脚本内容为空或只有一行，也会触发同步加载流程
defer只对外链脚本生效，且按顺序执行
defer 不会改变脚本执行时机，只改变执行时点：它让下载异步进行，但执行仍等到 HTML 解析完成、DOM 构建完毕后，再按 <script></script> 出现顺序依次运行。
关键限制：
-
defer对内联脚本无效（<script>...</script>加了也当没加） - 多个
defer脚本严格保序，适合有依赖关系的模块（如先加载lodash.js，再加载业务逻辑） - 不支持
document.write()，用它会直接报错DOMException: document.write() is not available in defer scripts - 在 IE9 及更早版本中被忽略（但现代项目通常不需兼容）
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，统一放在前（不是） - 保留一个最小化的内联
<script></script>在（如设置data-layer或__NEXT_DATA__），确保它极轻、无外部依赖、不操作 DOM - 用
type="module"替代defer（自动具备 defer 行为），但注意 Safari 10.1+ 才支持，且模块脚本默认是严格模式、不共享全局作用域
真正难处理的，其实是那些你没法改的第三方脚本——它们往往只提供一段含 document.write 的代码，或者强制要求放在 顶部。这种时候，阻塞就是硬成本，得靠预加载、资源提示（<link rel="preconnect">）或服务端渲染兜底。
