preload无法预加载相册图片序列，因其仅支持单个确定URL；需手动列出关键图片URL并用preload或JavaScript动态预加载，同时注意缓存、并发限制及兼容性。
preload 不能直接预加载相册图片序列
HTML 的 link rel="preload" 只能预加载**单个确定 URL 的资源**，无法自动识别“相册”这种逻辑概念。如果你有一组图片（比如 photo-1.jpg、photo-2.jpg…），浏览器不会因为你 preload 了第一个就顺带拉取其余几个——它连“这是相册”都不知道。
所以所谓“预加载相册”，本质是：明确列出要提前获取的图片 URL，并用 preload 或其他机制触发请求。
用 link rel="preload" 手动预加载关键图片
适用于你知道哪些图大概率会被用户点开（比如首张缩略图对应的大图、当前页展示图的下一张）。
- 必须指定
as="image"，否则浏览器可能不按图片优先级处理 - URL 必须准确，路径错误会导致 404 预加载（浪费一次请求）
- 不要滥用：预加载太多图片会抢占主文档、JS 的带宽，反而拖慢首屏
- 示例写法（放在
<head>中）：<link rel="preload" href="photos/photo-2.jpg" as="image"> <link rel="preload" href="photos/photo-3.jpg" as="image">
用 JavaScript 主动 fetch() 或创建 Image 实例
比 preload 更灵活，适合动态决定预加载哪些图（比如用户滑到第 3 张时，预加载第 4、5 张）。
立即学习“前端免费学习笔记（深入）”；
-
fetch(url).then(r => r.arrayBuffer())能进 HTTP 缓存，但不会自动解码；new Image().src = url会触发解码，内存开销更大 - 建议加
loading="lazy"到真实<img>上，避免预加载和懒加载冲突 - 别在页面加载初期一口气 new 10 个
Image：可能触发浏览器并发限制（通常 6 个），后续请求排队 - 简单示例：
const urls = ['photo-4.jpg', 'photo-5.jpg']; urls.forEach(url => { const img = new Image(); img.src = '/photos/' + url; // 触发请求 });
注意缓存策略和实际效果验证
预加载没效果？大概率卡在缓存或网络配置上。
- 检查响应头是否有
Cache-Control: no-store或Expires过期时间太短——预加载的资源如果被丢弃，等于白忙 - 用 Chrome DevTools 的
Network标签页，筛选type: image，看预加载请求是否出现在initiator列为preload或script - 移动端尤其要注意：部分安卓 WebView 对
preload支持不完整，Image方式兼容性更稳 - 相册类场景真正影响体验的，往往不是“是否预加载”，而是“是否用了
decoding="async"+ 合适尺寸的srcset”——这些比盲目 preload 更关键
