需在chrome devtools的network面板中筛选type=other或搜索文件名，确认initiator为preload、priority为highest/high，否则未生效。
怎么看浏览器有没有发预加载请求
光写 <link rel="preload" as="image"> 没用，得确认浏览器真发出了请求。打开 Chrome DevTools → Network 面板，刷新页面后做三件事：
- 筛选
type=other或直接搜索你的图片文件名（比如banner.webp） - 看
Initiator列：必须是preload，不是parser或script - 看
Priority列：应为Highest（as="image"时）或High；如果是Low或空，说明没被识别为高优资源
如果根本搜不到该资源，大概率是标签没生效——常见原因是写在了 里，或漏了 as="image"。
为什么写了 preload 却没进缓存或没被复用
预加载资源必须和后续真实使用的资源“完全匹配”，否则浏览器不会复用，等于白加。重点核对以下几项：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
href路径必须一致：不能一个写/assets/logo.webp，另一个用./assets/logo.webp（相对路径基准不同） - 协议、域名、查询参数都要相同：比如预加载
https://cdn.example.com/img.jpg，但<img src="https://cdn.example.com/img.jpg?v=2?x-oss-process=image/resize,p_40">就不会复用 - HTTP 响应头需支持缓存：
Cache-Control: public, max-age=31536000是理想配置；若返回no-store或max-age=0，预加载的响应会被丢弃 - 不要在预加载时加
crossorigin属性，除非后续<img>也带且值一致；不匹配会导致两个独立请求
Chrome 中 fetchpriority="high" 不起作用怎么办
fetchpriority="high" 只在 Chrome 101+ 生效，且仅对 <link rel="preload"> 和 <img> 有效。如果没效果，先确认：
- 浏览器版本是否 ≥ 101（地址栏输
chrome://version查） - 是否和其他高优资源冲突：比如同时预加载 10 张图，浏览器仍会按内部策略限流，并非全部都变
Highest - 别和
loading="lazy"混用在同一个资源上：首屏图加loading="lazy"会覆盖预加载意图，Chrome 可能直接忽略 preload - 旧版 Safari / Firefox 完全忽略该属性，无降级行为，也不报错
预加载后图片还是闪一下或延迟显示
预加载解决的是“下载时机”，不等于“渲染就绪”。如果看到图片加载完成仍有延迟或闪烁，问题通常不在 preload 本身：
- 没设
width/height：即使预加载完成，浏览器首次布局仍按 0×0 占位，图片解码渲染后触发重排，造成抖动（CLS） - 用了 WebP 但没 fallback：某些旧设备无法解码 WebP，预加载成功了但
<img>回退到<picture></picture>的srcset里其他格式，实际走的是另一条请求链 - JS 动态赋值
img.src过晚：预加载资源已进缓存，但你直到用户点击才设置src，中间有延迟；应确保 DOM 中的<img>标签在页面初始化阶段就存在且src已写死 - 图片太大没压缩：预加载只是提前下载，若单图超 2MB，解码仍卡主线程，视觉上仍是“慢”
真正容易被忽略的点是：预加载资源是否被后续 HTML 中的 <img> 标签“命中”——它不靠 class 或 id 匹配，只认 URL 字符串完全一致。哪怕多一个斜杠、少一个参数，就是两次请求。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
