相册大图预加载需分层策略：首屏缩略图和封面大图用，路径须绝对或根相对；后续大图用new image()滚动预载，先绑事件再赋src，并发限4；超大图（>5mb）交由web worker分块请求，校验后按需拉取。
相册类页面的大图预加载不能靠 loading="lazy" 或隐藏 <img> 标签糊弄过去——它需要分层策略：首屏缩略图用 <link rel="preload">，高清原图用 Image 对象或 Worker 按需拉取，否则用户点开瞬间卡顿、白屏、甚至触发重复请求。
用 <link rel="preload"> 预载缩略图和首张大图
这是最轻量、浏览器最懂的预加载方式，只适用于你**确定用户打开相册后 1 秒内必看**的资源（比如封面大图、前 2 张缩略图）。
-
as="image"必须写，漏掉会导致浏览器当普通 fetch 处理，失去图片缓存策略和解码优化 -
href路径必须是绝对路径或根相对路径（如/gallery/thumbs/01.webp），不能写成./thumbs/01.webp后再把 HTML 放到子目录下 - 如果首张大图有 WebP + JPEG fallback，只预加载 WebP 版本即可；
fetchpriority="high"在 Chrome 109+ 有效，旧版忽略无副作用 - 别在同一个
<link>上加media或 JS 模板，它是纯静态声明，href="/gallery/${id}.webp"这种写法会直接 404
用 new Image() 控制大图批量预加载
当用户滑动到第 5 张缩略图时，才开始预载第 6–8 张大图——这种“滚动即预载”逻辑只能靠 JavaScript 主动控制，Image 是最直接的选择。
- 顺序不能错：先绑
onload/onerror，再赋值src；否则缓存命中时事件同步触发，回调直接跳过 - 加载前检查
img.complete === true，为真说明已缓存，立刻 resolve，别等 onload - 并发数必须限制：浏览器通常只允许 6~8 个同域图片请求，建议用 Promise 队列控制，例如每次最多并发 4 个
- 封装示例中
preloadImage(url)返回 Promise，方便Promise.all([url1, url2].map(preloadImage))批量等待
超大图（>5MB）用 Web Worker 分块预取
相册里动辄 20MB 的 TIFF 或高分辨率 JPEG，全量下载会阻塞主线程、耗尽内存。Worker 不渲染、不操作 DOM，但能发起 fetch、解析头信息、分片请求，是唯一安全可控的方案。
- Worker 先发
HEAD请求校验链接有效性与Content-Length，避免无效下载 - 对确认要加载的大图，用
Range请求分块（如bytes=0-65535），只取头部几百字节解析宽高，不全量下载 - 真正需要渲染时，Worker 再按需拉取后续区块，主线程用
new Blob([chunks])组装并生成URL.createObjectURL() - 传输 ArrayBuffer 时务必用
postMessage(data, [data.buffer])实现零拷贝，否则大图数据序列化会卡死主线程
最容易被忽略的是缓存一致性：预加载的 URL 必须和最终 <img src> 完全一致（含查询参数、大小写、斜杠结尾），否则浏览器视为不同资源，预加载白做。另外，Service Worker 若拦截了图片请求，得确保它对预加载路径放行，否则 <link rel="preload"> 会被静默降级。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
