必须写 as="image"，否则浏览器按普通 fetch 处理，不启用图片解码、缓存策略失效、Lighthouse 不识别；href 与实际 Content-Type、文件后缀、构建后路径须严格一致，否则预加载无效。
用 <link rel="preload"> 声明图片必须写 as="image"
不加 as="image"，浏览器会当普通 fetch 处理：走通用缓存策略、不启用图片解码管线、Lighthouse 不识别为预加载资源。即使路径对、文件存在，<img src="/logo.webp"> 仍可能重复请求。
常见错误包括：
-
href指向.webp，但服务端实际返回Content-Type: image/png（比如 CDN fallback 规则生效），缓存不复用 - 开发环境本地服务器返回
image/webp，生产 CDN 返回image/jpeg，导致首屏图二次加载 - Webpack/Vite 构建时小图被 inline 成
data:URL，而<link>还指向原始路径，完全无法命中
new Image() 预加载必须先绑事件再赋值 src
顺序错了就会丢事件：如果图片已缓存（img.complete === true），onload 同步触发，但此时回调还没挂上，就直接跳过了。
正确做法是：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 创建
new Image()实例后，立刻设置onload和onerror - 再赋值
src—— 这行才是触发下载的开关 - 赋值后检查
img.complete，为true就立刻执行成功逻辑，别等事件 - 避免在循环里密集
new Image()：浏览器并发限制通常 6~8 个，建议用 Promise 队列控制（例如每次最多 4 个）
fetchpriority="high" 只在 Chrome 101+ 生效且需配合 as="image"
单独写 fetchpriority="high" 没用：as="image" 缺失时，该属性会被忽略，Network 面板中 Priority 显示为 Low；有 as="image" 但没 fetchpriority="high"，Priority 多数是 High，但在弱网下容易被字体、CSS 挤到后面，首屏图延迟 300ms+。
真正起效的组合只有：
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">- 对应
<img src="/hero.webp">，URL 必须字面量完全一致（含查询参数） - 不要给
srcset图硬套 preload：浏览器按 DPR/宽度选中的 URL 和你 preload 的那个不一致，缓存就失效
轮播图预加载只加载当前页及相邻 1–2 张
轮播图不是“全量预加载”的场景。10 张图全 preloaded，既浪费带宽，又占满并发连接，反而拖慢首屏和关键 JS 加载。
合理策略是：
- 初始化时只预加载
currentIndex、currentIndex - 1、currentIndex + 1对应的图片 - 用户切换后，立刻触发新位置的相邻图预加载（比如从第 2 切到第 5，就预加载 4、5、6）
- 确保
data-src或 JS 中拼接的 URL 和最终img.src赋值的 URL 完全一致（含版本号、参数等） - 移动端尤其注意：一次别超 3 张，避免阻塞其他资源
真实项目里最容易被忽略的点是：URL 字面量一致性和MIME 类型与文件后缀的严格匹配。哪怕只是 CDN fallback 规则把 .webp 请求悄悄转成 .png，或者构建工具把图片 hash 后路径变了但 <link> 没同步更新，预加载就等于白做。
