预加载多视角图片应按需动态预加载相邻帧，而非全量加载；首帧和关键过渡帧用<link rel="preload" as="image">静态声明，其余通过new Image()按滑动节奏预加载第n±1帧，并严格控制并发与节流。
预加载多视角图片（比如 360° 旋转图、产品多角度图、建筑环视图）的关键不是“一次性全拉下来”，而是按需提前加载下一张或相邻视角，同时避免阻塞首屏、浪费带宽。真要全量预加载十几张 2MB 的 WebP，用户还没点开就卡死了。
用 link rel="preload" 加载首帧和关键过渡帧
首帧（front view）和最常被点击的过渡帧（如 right、top）适合用 <link rel="preload"> 声明。它不渲染、只进缓存，且能被浏览器优先调度。
-
as="image"必须写，否则浏览器不会启用图片专用的缓存策略和请求头 - 路径必须是静态绝对路径，比如
href="/assets/product-front.webp"，不能含模板变量或相对路径误算 - 如果首帧是 WebP，记得在
<picture>或<img>中提供type="image/jpeg"fallback，preload本身不处理降级 - Chrome 109+ 可加
fetchpriority="high"，对首帧有效；但别给全部 12 张都加，会挤占其他关键资源带宽
用 new Image() 按视角滑动节奏预加载相邻帧
用户拖拽到第 5 张时，立刻预加载第 4 和第 6 张——这是最实用的多视角预加载逻辑。靠 <link> 做不到动态判断，必须用 JS。
- 务必先绑定
onload/onerror，再赋值src，否则缓存命中时事件直接同步触发，回调丢失 - 检查
img.complete === true，若为真，说明已缓存，可立即触发成功逻辑（比如更新 loading 状态） - 并发控制很重要：一次预加载超过 4 张高分辨率图，容易触发浏览器并发限制（通常 6~8 个），建议用 Promise 队列，例如
Promise.allSettled(preloadQueue.slice(0, 4)) - 不要在
scroll或mousemove里直接 new Image()，先节流（如 Lodashthrottle100ms）再触发预加载
避免用 loading="lazy" 或 display: none 伪预加载
这是多视角场景中最容易踩的坑：把所有视角图都写进 DOM，然后靠 loading="lazy" 或藏在 display: none 里“假装预加载”。实际效果是——它们和页面其他资源一起加载，甚至因 lazy 被延迟到滚动后才发请求，完全背离预加载目标。
立即学习“前端免费学习笔记（深入）”；
-
loading="lazy"是推迟加载，不是提前加载；哪怕你给第 12 张图也加上它，Chrome 仍可能等到它进入视口前 500px 才发起请求 -
display: none的<img>仍会触发加载（除非 src 为空），且无法控制加载时机和失败反馈 - 真正需要的是“不在 DOM 中、不占布局、可监听状态、按需触发”的加载方式，只有
new Image()或fetch()+createObjectURL()满足
多视角图片预加载真正的复杂点不在语法，而在节奏判断：预加载太激进（比如用户刚看 front 就把全部 12 张都拉下来），浪费流量；太保守（只预加载下一张），拖慢交互响应。你需要结合用户操作历史（比如平均停留时长、滑动速度）做轻量预测，而不是堆代码。
