是的，script放在head里默认会阻塞页面渲染；浏览器自上而下解析HTML时，遇无async/defer的script即暂停DOM构建，导致白屏、首屏延迟及DOM操作失败（如document.getElementById返回null）。

script放在head里会阻塞页面渲染

浏览器的HTML解析器是“急性子”，它从上到下逐行解析，一旦遇到一个没有 async 或 defer 属性的 。虽然现代浏览器大多会“好心”地将其纠正到 内，但这不符合HTML规范，可能会在CI流程或团队的代码检查工具中引发警告。

现代项目中 defer 是 head 里的唯一合理选择

除非你有非常特殊的需求，必须在DOM构建前就运行脚本（这种场景极少），否则在 中放置脚本时，defer 属性几乎是唯一合理的选择。它巧妙地解决了一个核心矛盾：既能让脚本（及其定义的全局变量或函数）在文档早期就被声明，又不会阻塞页面的渲染进程。

这里有个关键细节：defer 只对带有 src 的外部脚本生效，对内联脚本不起作用。它的执行时机是在DOM解析完成之后、DOMContentLoaded 事件触发之前。

• async 的适用场景：适合那些完全独立、没有依赖、且执行时机不重要的脚本，例如网站分析代码。但它既不保证执行顺序，也不等待DOM就绪。
• 混合使用的顺序：当页面中同时存在 async 和 defer 脚本时，async 脚本会在加载完成后立即执行，因此其执行顺序可能早于 defer 脚本，无论它们在HTML中的书写顺序如何。
• 构建工具的默认行为：像Vite、Webpack这类现代构建工具，它们自动注入的运行时（runtime）脚本通常已经默认处理了 defer 逻辑，开发者一般无需手动干预。

真正容易被忽略的细节

很多人以为“只要把脚本放在 前面就万事大吉了”，但实际开发中，还有一些隐蔽的坑等着我们。

首先，是脚本内部的写法问题。例如使用已被废弃的 document.write，或者在依赖的全局库（如jQuery）尚未加载完成时就急切地调用 $()。另外，在模块化开发中，误将ES Module当作普通脚本使用也需要警惕，因为ESM默认具有类似 async 的行为，即使放在body底部，其执行顺序也可能出乎意料。

其次，一个更隐蔽的问题来自构建流程。在使用服务端渲染（SSR）或静态站点生成器（如Hugo、Astro）时，最终输出的HTML中脚本的位置可能由构建工具自动决定并注入到 中。这时候，光看源代码文件的位置是没用的，必须去检查相应的构建配置才能找到根源。