是的，script放在head里默认会阻塞页面渲染；浏览器自上而下解析HTML时，遇无async/defer的script即暂停DOM构建，导致白屏、首屏延迟及DOM操作失败（如document.getElementById返回null）。
script放在head里会阻塞页面渲染
浏览器解析HTML是自上而下的，遇到 <script> 就会暂停 DOM 构建，去下载、解析、执行脚本。如果脚本放在 <head> 里，且没加 async 或 defer，那用户可能看到长时间白屏——因为连 <body> 都还没开始解析。
常见错误现象：document.getElementById("app") 返回 null，因为 DOM 还没生成；或者页面首屏内容迟迟不出现，尤其在弱网下更明显。
- 内联脚本（没
src）放<head>时，执行时机早但风险高，必须确保不操作尚未存在的 DOM - 外部脚本（带
src）放<head>时，默认同步加载，会阻塞后续所有资源（CSS、图片、甚至其他 JS） -
defer只对外部脚本生效，且保证执行顺序与 script 标签顺序一致；async不保证顺序，适合完全独立的脚本（如统计代码）
script放在body底部能安全操作DOM
把 <script> 放在 </body> 前，意味着 HTML 解析已基本完成，document.body 和所有常规元素都已就绪。这时候调用 getElementById、绑定事件、初始化框架（如 Vue 的 new Vue({ el: "#app" })）基本不会出错。
性能影响：页面结构优先渲染，用户感知更快；脚本加载和执行延迟对首屏无感，但要注意「功能就绪时间」是否满足业务要求（比如导航菜单需立即可用）。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 不要写成
</body><script>...</script></html>—— 虽然浏览器会自动把它“塞回”<body>内，但不符合 HTML 规范，CI 工具或团队 lint 可能报 warning - 多个脚本按依赖顺序从上到下排列，避免手动管理执行时机
- 如果某个脚本必须提前加载（如 Polyfill），就放
<head>+defer，而不是硬塞进<body>底部再用setTimeout等 DOM
现代项目中 defer 是 head 里的唯一合理选择
除非你明确需要脚本在 DOM 构建前运行（极少见），否则 <head> 里只应出现带 defer 的外部脚本。它解决了两个核心矛盾：既要全局变量/函数提前可用，又不能阻塞渲染。
注意点：defer 对内联脚本无效；它只在外部脚本上起作用，且执行时机是 DOMContentLoaded 之前、DOM 解析完成后。
-
async适合无依赖、可随时执行的脚本（如 Google Analytics），但无法保证执行顺序，也不等 DOM 就绪 - 混合使用时，
defer脚本总在async之后执行，即使它们在 HTML 中顺序相反 - Vite / Webpack 等构建工具默认注入的 runtime 脚本，通常已用
defer处理，无需手动改
真正容易被忽略的细节
很多人以为“只要在 </body> 前就行”，但实际开发中常踩的坑是：脚本里用了 document.write（已废弃）、或依赖了未声明的全局变量（比如 jQuery 没加载完就调用 $()）、或在模块化场景下误把 ES module 当普通脚本用（ESM 默认是 async 行为，即使放 body 底部也未必按预期执行）。
还有个隐蔽问题：服务端渲染（SSR）或静态站点生成器（如 Hugo、Astro）输出的 HTML，可能把脚本自动注入到 <head>，这时得查构建配置，而不是只看源码位置。
