浏览器preload缓存基于完整url精确匹配，大小写、斜杠、query参数等任一差异均导致重复下载；需确保preload href与实际加载src完全一致，并同步构建哈希、服务端参数及格式选择。
预加载 URL 和 ![]()
必须完全一致
浏览器的 preload 缓存是基于完整 URL 匹配的，哪怕一个字符不同（大小写、斜杠方向、query 参数有无），都会视为两个资源，导致重复下载。常见错误包括：
-
href="/images/banner.jpg但src="./images/banner.jpg—— 相对路径解析失败或不一致 -
href="/images/banner.webp但srcset中实际加载的是/images/banner.jpg（fallback 未命中） - 构建后文件带哈希，如
banner.a1b2c3.jpg，但<link rel="preload">还写死为banner.jpg - 服务端加了时间戳或版本参数（如
?v=1.2），但 preload 没同步加上
不要在 里写
HTML 解析器的 preload scanner 只扫描
， 中的<link rel="preload" as="image"> 完全被忽略——浏览器照常发起图片请求，但不会复用 preload 缓存，等于白写还多占 HTML 体积。验证方法：打开 DevTools → Network → 刷新页面，筛选 resource type = image，看是否有两条同名请求（一条来自 preload，一条来自 ），那就是重复了。
轮播图预加载只做当前 + 相邻三张
轮播图动态切换时，预加载范围失控是重复加载高发场景。比如一次预加载全部 10 张图，用户只看了前两张，剩下 8 张全浪费。
正确做法是初始化时只预加载 currentIndex - 1、currentIndex、currentIndex + 1 对应的图片；切换后立刻更新预加载目标，丢弃过期项。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
注意：new Image() 方式需手动清理引用，否则 img 对象长期驻留内存，且 onload 绑定未解绑可能引发多次回调。
WebP + fallback 场景下只预加载主格式
当用 srcset 提供 WebP + JPEG fallback 时，<link rel="preload"> 只能指定一种格式（推荐 WebP），且必须确保该格式在当前设备/浏览器中被实际选用。
否则会出现：预加载了 .webp，但 <img> 最终加载了 .jpg，缓存不命中，两次请求。
验证点：document.querySelector('img').currentSrc 返回的值，必须和 preload 的 href 完全相等。
最容易被忽略的是构建产物路径同步问题——Webpack/Vite 的 file-loader 或 asset modules 输出带 hash 的文件名后，preload 的 href 若没走同一套 resolve 逻辑，99% 会重复加载。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
