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