预解析器扫描初始HTML中静态同步script标签并提前下载，不执行脚本；async/defer脚本仍被发现但执行时机不同，动态插入脚本则完全逃逸预解析。
预解析器到底在解析什么
浏览器的预解析器（preload scanner）不是在执行 JavaScript，而是在 HTML 解析器被阻塞时，单独启动一个轻量级扫描线程，快速向前查找 、<script></script>、 等资源声明，并提前发起网络请求。它不执行脚本，也不构建 DOM，只做“发现即下载”。
这意味着：即使你把 <script src="a.js"></script> 放在 底部，只要 HTML 解析器还没扫到它，预解析器就可能早已把它加入下载队列——前提是它没被动态插入、也没被 defer 或 async 干扰解析时机。
哪些 script 会被预解析器“看见”
预解析器只处理静态、同步、非内联的 <script></script> 标签，且必须出现在初始 HTML 字节流中（即服务端直出，非 JS 动态创建）。以下情况会直接失效：
-
<script async src="a.js"></script>：async 脚本仍会被预解析器发现并提前下载，但执行时机不可控，无法用于依赖链首环 -
<script defer src="b.js"></script>：defer 脚本同样会被预解析器抓取，且执行顺序有保证，适合非首屏关键逻辑 -
<script>fetch('c.js').then(...)</script>：动态加载完全逃逸预解析，资源发现延迟至少一个 event loop -
<script type="module"></script>：现代模块脚本默认异步，预解析器能识别并下载，但模块图解析由 ES 模块加载器接管，与传统预解析解耦
真正“看不见”的是：document.createElement('script')、import('./d.js')、或任何通过 JS 控制的加载路径。
用 rel="preload" 强干预优先级
当预解析器无法覆盖你的加载意图（比如想让某个非首屏但高优先级的工具库比 CSS 更早开始下载），就得手动介入。用 是最直接的方式——它绕过 HTML 解析顺序，强制浏览器在 earliest possible moment 发起请求。
但要注意三点：
- 必须指定
as="script"，否则浏览器不会设置正确的 Accept 头和 CORS 行为 - 不能和
defer/async混用在同一资源上，否则可能触发重复下载（Chrome 旧版已修复，但 Safari 16.4 前仍有风险） -
preload只负责下载，不执行；你需要额外用<script>window.utilPromise = import('./util.js')</script>或显式createElement来触发执行
典型误用：（缺 as）→ 请求发出去了，但响应体被当作 text/plain 缓存，后续 <script src="main.js"></script> 仍会重新请求。
检查是否真的生效了
别信文档，看 Network 面板的 Initiator 列和 Timing 选项卡：
- 如果某 JS 的 Initiator 显示为
Parser，说明是预解析器发现的；显示为Other或Script，大概率是 JS 动态加载 - 对比两个同 URL 脚本的
Start Time：被预解析的通常比其后出现的 CSS 或图片更早开始传输（尤其在慢网模拟下明显） - 在
chrome://flags/#enable-web-helpers启用 “Web Helpers” 后，Performance 面板会多出 “Preload Scanner” 事件，可直观看到扫描范围和命中项
一个容易被忽略的细节：HTTP/2 Server Push 已被主流浏览器弃用，别再把它和预解析混淆；Server Push 是服务端单方面推送，而预解析是客户端主动扫描，二者触发机制、可控性和调试方式完全不同。
