默认脚本放head必致白屏，因浏览器会暂停HTML解析、同步下载执行；defer适合需操作DOM或有依赖的外部脚本，按序在DOM就绪后执行；async仅适用于完全独立脚本，下载完立即执行但顺序不可控。

脚本放哪儿不重要，关键是怎么加载；默认不加属性的 <script></script> 放在 里，首屏白屏几乎是必然的。

为什么 <script src="app.js"></script> 放 会卡住页面

浏览器解析 HTML 是流式的，遇到没有 defer 或 async 的外部 <script></script>，会立刻暂停 DOM 构建，发起网络请求，等下载、解析、执行全部完成才继续。此时 里的所有内容都“冻住”了。

• 常见现象：document.getElementById("app") 报 is null，DOMContentLoaded 时间远晚于 first-contentful-paint
• 弱网下尤其明显：用户看到白屏几秒，控制台可能还没打开
• 哪怕脚本只有 console.log(1)，只要它在 里且没加属性，就阻塞渲染

defer 适合哪些脚本：DOM 操作 + 多文件顺序依赖

defer 让脚本并行下载、不阻塞解析，且严格按 HTML 中书写顺序，在 DOM 解析完成后、DOMContentLoaded 触发前执行——这是业务 JS 最自然的加载方式。

• 必须是外部脚本（带 src）；内联脚本加 defer 会被忽略
• 脚本要读取或操作完整 DOM，比如初始化组件、绑定事件、解析 data- 属性
• 多个脚本有依赖关系，如 utils.js 必须在 app.js 之前执行
• 示例写法：<script src="vendor.js" defer></script>、<script type="module" src="app.mjs"></script>（type="module" 默认带 defer 行为）

async 用错就报错：只适用于完全独立的脚本

async 脚本下载不阻塞，但一旦下载完成，会立刻中断 HTML 解析并执行——此时 DOM 可能只解析了一半，也不管其他脚本是否就绪。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

立即学习“前端免费学习笔记（深入）”；

• 只适用于不操作 DOM、不依赖其他 JS、失败也不影响主功能的脚本，如 analytics.js、广告 SDK
• 两个 async 脚本若存在依赖，A 下载快但 B 还没加载，执行 A 就会抛 ReferenceError
• 别把 async 脚本放在 底部还指望它晚执行——它可能比 <header></header> 还早运行
• 绝对不要在 async 脚本里调用 document.write()，页面直接清空

放在 前 ≠ 安全，不加属性照样阻塞下载

把 <script src="main.js"></script> 放在 前，只是让执行时机靠后，但下载阶段仍会同步阻塞 HTML 解析——尤其在弱网下，浏览器一边等 JS 下载，一边停着不往下扫。

• 真正解耦下载与执行，必须加 defer 或 async
• 即使放到底部，没加属性的外部脚本仍会触发“暂停 → 下载 → 执行 → 继续”的流程
• 规范上，<script></script> 放在 和 之间会被解析器自动纠正进 ，虽不影响运行，但审查工具可能警告

最容易被忽略的是：很多人以为“放到底部就万事大吉”，结果 Network 面板里看到 JS 下载时间占了首屏大头——那不是执行慢，是下载被默认同步行为拖住了。优化起点永远是明确声明加载意图，而不是靠位置赌时机。