预加载扫描器仅浅层扫描初始html字节流，深度限6层，不执行js、不解析css、不识别动态注入或深层嵌套资源；语义标签可提升资源探测可信度，而错误preload位置、缺失as/crossorigin、fetchpriority误用等均导致失效。
预加载扫描器根本看不到你藏在六层里的资源
浏览器的预加载扫描器（Preload Scanner）只做一次浅层字节流扫描，不构建完整 DOM，也不执行 JS。它最多读到 DOM 深度 6 层，再深就截断——不是“没耐心”，是设计如此。
常见失效现象：LCP 候选图片始终卡在 Medium 优先级、link rel="preload" 声明了字体却仍 FOUC、首屏大图加载延迟明显。
-
<picture></picture> 内部的 <source></source> 能被识别，但整个 <picture></picture> 若嵌套在 <div class="lazy-load-wrapper"> 里，且该 wrapper 没有 <code>src 或 loading="eager"，扫描器直接跳过
- 服务端渲染（SSR）中，JS 动态注入的资源（如
innerHTML 或 hydration 后挂载）完全不会被扫描到——它只看初始 HTML 字节流
-
<details></details>、<dialog></dialog>、<slot></slot> 这类惰性容器，只要没显式触发加载逻辑，扫描器连标签名都懒得解析
fetchpriority="high"只对![]()
和
fetchpriority 不是运行时 API，它只在 HTML 解析阶段被读取一次；也不是强制指令，只是提示信号。浏览器会结合网络状态、CPU 负载、是否在视口内综合判断最终优先级。
典型踩坑点：
- 给非首屏图片设
fetchpriority="high"，Chrome 仍可能降级为 low——尤其当它还没进入预扫描范围时
-
<script></script>、<link rel="stylesheet"> 加 fetchpriority 完全无效，属性被忽略
-
src 或 srcdoc 必须存在且非空；JS 动态设置 src 后再加该属性，不会触发优先级调整
- Safari 17.2+ 仅部分识别
<img> 上的 fetchpriority，Firefox 完全不支持
link rel="preload"放错位置或写错as，等于没写
link rel="preload" 必须出现在 <meta charset> 和 <title></title> 之后、其他 <link rel="stylesheet"> 之前。晚于这个时机，浏览器可能已开始下载关键资源，指令被丢弃。
常见错误：
- 用 JS 动态插入：
document.head.appendChild() —— 完全无效，不参与初始解析流
-
as 属性漏写或错写：比如字体写成 as="font/woff2" 或省略，浏览器当普通 fetch 处理，Priority 降为 low
- 字体必须配
crossorigin，否则因跨域限制被丢弃；同域字体也建议加——Chrome 120+ 已默认启用 CORS 检查
- CSS 预加载后必须手动切换：
onload="this.onload=null;this.rel='stylesheet'"，否则只是“下完放着”，不参与 CSSOM 构建
语义标签不是为了 SEO，而是为了让预扫描器“认得清”
预扫描器内部有一套轻量级标签白名单和上下文感知逻辑：<main></main>、<article></article>、<section></section> 这些语义标签本身会提升其子元素中资源的探测可信度；而连续多个 <div> 嵌套，会被当作“结构噪声”快速滑过。
<p>实操建议：</p>
<ul><li>首屏关键图片尽量放在 <code><main></main> 或 <article></article> 直接子节点下，避免套 3 层以上 <div>
<li>不要用 <code><style></style> 块里的 @import 加载 CSS——预扫描器不解析 CSS 内容，@import 是 CSSOM 阶段才触发的串行阻塞行为
- 条件渲染内容（如
{isLoaded && <img>}）在 SSR 输出中若不存在，扫描器就无从响应；Next.js 的 <image></image> 组件即使默认带 fetchpriority="high"，也逃不过这个限制
真正起效的协同，不在“加了多少 preload”，而在 HTML 字节流第一眼就被扫描器抓住关键路径——结构越直白，信号越干净。
浏览器的预加载扫描器（Preload Scanner）只做一次浅层字节流扫描，不构建完整 DOM，也不执行 JS。它最多读到 DOM 深度 6 层，再深就截断——不是“没耐心”，是设计如此。
常见失效现象：LCP 候选图片始终卡在 Medium 优先级、link rel="preload" 声明了字体却仍 FOUC、首屏大图加载延迟明显。
-
<picture></picture>内部的<source></source>能被识别，但整个<picture></picture>若嵌套在<div class="lazy-load-wrapper"> 里，且该 wrapper 没有 <code>src或loading="eager"，扫描器直接跳过 - 服务端渲染（SSR）中，JS 动态注入的资源（如
innerHTML或 hydration 后挂载）完全不会被扫描到——它只看初始 HTML 字节流 -
<details></details>、<dialog></dialog>、<slot></slot>这类惰性容器，只要没显式触发加载逻辑，扫描器连标签名都懒得解析 - 给非首屏图片设
fetchpriority="high"，Chrome 仍可能降级为low——尤其当它还没进入预扫描范围时 -
<script></script>、<link rel="stylesheet">加fetchpriority完全无效，属性被忽略 -
src或srcdoc必须存在且非空；JS 动态设置src后再加该属性，不会触发优先级调整 - Safari 17.2+ 仅部分识别
<img>上的fetchpriority，Firefox 完全不支持 - 用 JS 动态插入：
document.head.appendChild()—— 完全无效，不参与初始解析流 -
as属性漏写或错写：比如字体写成as="font/woff2"或省略，浏览器当普通fetch处理，Priority 降为low - 字体必须配
crossorigin，否则因跨域限制被丢弃；同域字体也建议加——Chrome 120+ 已默认启用 CORS 检查 - CSS 预加载后必须手动切换：
onload="this.onload=null;this.rel='stylesheet'"，否则只是“下完放着”，不参与 CSSOM 构建 - 条件渲染内容（如
{isLoaded && <img>}）在 SSR 输出中若不存在，扫描器就无从响应；Next.js的<image></image>组件即使默认带fetchpriority="high"，也逃不过这个限制
真正起效的协同，不在“加了多少 preload”，而在 HTML 字节流第一眼就被扫描器抓住关键路径——结构越直白，信号越干净。
fetchpriority="high"只对![]()
和
fetchpriority 不是运行时 API，它只在 HTML 解析阶段被读取一次；也不是强制指令，只是提示信号。浏览器会结合网络状态、CPU 负载、是否在视口内综合判断最终优先级。
典型踩坑点：
link rel="preload"放错位置或写错as，等于没写
link rel="preload" 必须出现在 中，且紧随 <meta charset> 和 <title></title> 之后、其他 <link rel="stylesheet"> 之前。晚于这个时机，浏览器可能已开始下载关键资源，指令被丢弃。
常见错误：
语义标签不是为了 SEO，而是为了让预扫描器“认得清”
预扫描器内部有一套轻量级标签白名单和上下文感知逻辑：<main></main>、<article></article>、<section></section> 这些语义标签本身会提升其子元素中资源的探测可信度；而连续多个 <div> 嵌套，会被当作“结构噪声”快速滑过。
<p>实操建议：</p>
<ul><li>首屏关键图片尽量放在 <code><main></main> 或 <article></article> 直接子节点下，避免套 3 层以上 <div>
<li>不要用 <code><style></style> 块里的 @import 加载 CSS——预扫描器不解析 CSS 内容，@import 是 CSSOM 阶段才触发的串行阻塞行为
