内联脚本不被预解析器扫描，async/defer属性对其无效，执行时立即阻塞html解析；预解析器仅识别带src的script标签，内联脚本会中止其工作，导致后续资源无法预加载。
内联脚本根本不会被预解析器扫描
浏览器的预解析器（Pre-Parser）只识别带 src 属性的 <script></script> 标签，遇到 <script>console.log(1)</script> 这类内联脚本，直接跳过、不发起任何预加载，也不做资源推测。它不是“扫描到但忽略”，而是语法上就不匹配识别规则。
常见错误现象：在 里写 <script async>fetch('/api').then(...)</script>，以为能异步加载——其实 async 被忽略，脚本立刻同步执行，且完全逃不出预解析器的雷达范围。
- 预解析器只扫描静态 HTML 字节流，不执行 JS，也不解析内联内容
-
document.write()在内联脚本中会强制主解析器暂停，此时预解析器也必须停，但它压根没启动过 - 即使内联脚本很小（比如只有一行
var CONFIG = {...}），只要没src，就等于对预加载“隐身”
async 属性对内联脚本无效是规范硬限制
HTML 规范明确要求：async 和 defer 只对具有 src 属性的外部脚本生效。浏览器实现严格遵守这点，不是兼容性问题，而是行为定义本身。
你写 <script async>alert('hi')</script>，结果和 <script>alert('hi')</script> 完全一样：立即阻塞解析、同步执行、无预加载、无并行下载。
- 写
async="false"或async=""没区别，布尔属性只要存在即启用，但内联场景下启用也无意义 - Webpack/Vite 等工具生成的内联初始化代码（如
window.__INITIAL_STATE__ = {...}）若放在<script defer></script>里，defer同样被忽略，别指望它延迟执行 - 想让内联逻辑“不阻塞”，唯一办法是把它包装进
DOMContentLoaded或requestIdleCallback，而不是依赖 HTML 属性
预解析器何时因内联脚本彻底失效
预解析器不是“看到内联脚本就退出”，而是在主解析器遇到内联 <script></script> 时被迫中止——因为内联脚本可能调用 document.write() 动态插入后续 HTML，预解析器无法预测这种运行时修改，只能等主解析器执行完再继续。
这意味着：哪怕页面只有 1 行内联脚本，且位于 底部，只要它出现在主解析器路径上，预解析器就会在那个位置停止扫描，后续所有 <link rel="stylesheet">、<img> 都失去预加载机会。
- 内联脚本越靠前（尤其在
），对预加载的破坏越严重 - 现代框架 SSR 输出的内联状态数据（如
<script>window.__data = {...}</script>）应尽量压缩体积，并确保不带document.write调用，否则会连锁阻塞整个预加载流程 - 服务端模板中混入大量内联 JS（如统计代码、AB 测试配置），比外链脚本更伤首屏性能——它既不能被缓存，又废掉预解析
真正影响解析节奏的是脚本执行，不是加载方式
很多人以为“用了 async 就不卡”，但内联脚本或同步外链脚本执行时，主线程会真实暂停 HTML 解析——这个暂停时间取决于 JS 执行耗时，而非网络下载耗时。几 KB 的内联脚本如果含复杂正则或循环，可能比 100KB 的 async 外链脚本更拖慢 DOM 构建。
实测中，一个含 JSON.parse() 大对象的内联脚本，在低端安卓机上可导致解析中断 >80ms；而同样逻辑外链 + defer，解析全程流畅，仅在 DOMContentLoaded 前集中执行。
- 内联脚本的执行时机不可控：它总在解析到该标签时立刻跑，没有缓冲窗口
- 外链脚本即使没加
async/defer，至少还有网络 IO 时间作为天然缓冲；内联脚本则是“零延迟打击” - 调试时看 Network 面板没请求，不代表没开销——内联 JS 的 parse & compile & execute 全在主线程同步完成
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
