该用preload而非lazy时：首屏关键图（如banner、logo）必须删掉loading="lazy"，改用<link rel="preload" as="image" href="...">置于<head>最前；非首屏图禁用preload，仅用lazy。
预加载图片不是“多下几张图就更快”，而是用对时机、对方式、对资源——错配策略反而拖慢首屏、浪费流量。
什么时候该用 link rel="preload" 而不是 loading="lazy"
二者目标相反：link rel="preload" 是“提前拿”，loading="lazy" 是“尽量晚拿”。混用会自相矛盾。
- 首屏 banner、logo、登录页主视觉图 —— 必须删掉
loading="lazy"，改用<link rel="preload" as="image" href="/assets/hero.webp">放在<head>最顶部 - 列表页第 3 张以后的缩略图、用户可能不点的弹窗配图 —— 禁用 preload，只用
loading="lazy"（且必须配sizes和正确srcset） - 父容器有
overflow: hidden或transform——loading="lazy"会静默失效，此时若图非首屏，应改用 IntersectionObserver 手动控制，而非硬加 preload
link rel="preload" 的三个硬性条件缺一不可
浏览器只认死规则，漏一条，preload 就退化成普通 fetch，失去图片缓存和解码优化。
-
as="image"必须显式写上，否则不进图片缓存池，也不走解码管线 -
href必须是静态字符串，不能含${name}、url()、或任何 JS 表达式；路径需绝对或基于根目录（如/images/logo.webp），相对路径易因 HTML 部署位置不同而 404 - 必须放在
<head>内，且越靠前越好；动态插入（如 JS 创建后 append）或写在<body>里，preload scanner 根本看不到
运行时预加载用 new Image() 怎么不翻车
适合 hover 后预载下一页、按设备像素比选图等场景，但事件绑定顺序和并发控制稍错就会失败静默或雪崩。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 赋值
src前必须先绑定onload和onerror，否则缓存命中时事件同步触发，回调直接丢失 - 赋值后立刻检查
img.complete === true，为真则立即执行成功逻辑，不等 onload - 避免 for 循环中密集
new Image()；浏览器并发上限通常为 6~8，建议用 Promise 队列控制（如每次最多 3 个并发） - 弱网下要兜底：检查
navigator.connection?.effectiveType，值为'2g'或'slow-2g'时跳过或降级（如只拉 base64 占位图）
WebP/AVIF 预加载必须带 fallback
现代格式体积小，但旧浏览器不支持；单独 preload WebP 而不处理 fallback，会导致 Safari 15.2 及更早版本白屏或报错。
- 不要只写
<link rel="preload" as="image" href="/hero.webp"> - 应在
<picture>中声明 fallback：<source type="image/webp" srcset="hero.webp"><img src="hero.jpg" alt="">，再对hero.jpg做 preload（确保兜底图一定可加载） - 服务端开启 Accept 头协商时，客户端请求 WebP 成功，但 preload 的 jpg 仍会进缓存 —— 这是预期行为，不必强求“只 preload 一种格式”
真正容易被忽略的点是：预加载资源是否真的进了缓存并被后续 <img> 复用。用 Chrome DevTools 的 Network → Size 列看请求是否显示 (from cache)，而不是只看 status 200；如果没复用，大概率是 href 路径不一致（大小写、斜杠、查询参数差异）或 as 缺失导致缓存隔离。
