真正决定带宽成本的是浏览器实际发起的HTTP请求路径是否唯一且不可绕过；大规模并发下，srcset/sizes误配、picture断点失准、AVIF解码瓶颈、lazy加载失效等均会因解析差异放大冗余请求。
大规模活动期间，响应式图像的带宽成本主要来自未被加载却仍被解析/预加载的冗余资源，而非单张图大小本身。关键不是“压得更小”，而是“让浏览器只下载它真要显示的那一张”。
为什么 srcset + sizes 在高并发下反而放大带宽压力
常见误操作是把所有尺寸版本（如 400w–3200w）一股脑塞进 srcset，再配一个笼统的 sizes="(min-width: 1200px) 800px, 100vw"。浏览器会基于视口宽度和设备像素比（dpr）计算出“所需显示宽度”，然后从 srcset 中选最接近且不小于该值的源 —— 但这个过程在低端 Android 或旧版 Safari 上容易误判，导致小屏用户也拉取 1600w 图片。
- 实际测试中，
srcset在 dpr=3 的 iPhone 上常触发 2x 或 3x 降级逻辑，即使页面布局只占 300px 宽，仍可能加载 900w 版本 -
sizes若未精确匹配容器渲染宽度（比如用100vw但父容器有 padding/margin），浏览器估算偏差 >20%，就会跳过更小的可用源 - CDN 缓存粒度通常按 URL 区分，
img-800w.jpg和img-1200w.jpg是两个独立缓存 key，无法共享压缩上下文或复用解码结果
<picture> 的 media 属性必须绑定真实容器断点，不能照搬视口断点
活动页常使用卡片、网格等复杂布局，图片实际渲染宽度 ≠ 视口宽度。例如一个三列卡片在 768px 视口下每张图只占 ~220px，但 media="(max-width: 768px)" 会让所有 768px 以下设备都加载同一套源，浪费严重。
- 真实做法：用 JavaScript 动态读取图片父容器的
offsetWidth，生成对应media值，例如media="(max-width: 240px)"对应 220px 容器（留 10px 余量） - 服务端可预渲染：Node.js 渲染时注入容器宽度上下文，生成精准
<source>列表，避免客户端 JS 竞态 - 禁止把
type="image/webp"放在最后 —— 浏览器一旦匹配到前面的 JPEG<source>就停止解析，WebP 永远不会被选用
AVIF 格式在 CDN 边缘节点的解码成本常被低估
虽然 AVIF 体积比 WebP 小 20%~30%，但其解码耗时是 WebP 的 2~4 倍（尤其在低端安卓机）。大规模并发时，客户端解码瓶颈会推高首屏时间，间接导致用户重复刷新，反而增加总请求数。
立即学习“前端免费学习笔记（深入）”；
- 实测数据：在骁龙 625 设备上，解码一张 800w AVIF 平均耗时 120ms，WebP 仅 35ms；若页面含 6 张图，首屏延迟直接增加 510ms
- CDN 不一定支持 AVIF 自动转码 —— 若源站只传 AVIF，iOS 13 以下、Chrome 85 以下用户将看到空白，必须 fallback 到 JPEG，此时双格式存储+双 CDN 缓存反而推高成本
- 推荐策略：对 banner、主视觉图用 AVIF（用户停留久，可接受解码延迟）；对列表图、头像图坚持 WebP + JPEG fallback
懒加载与 loading="lazy" 的协同失效点
loading="lazy" 依赖 Intersection Observer，但在 iOS 15.4 以下、Android WebView 旧版本中完全不生效，所有 <img> 仍会触发预加载。此时若 srcset 里塞了 6 个尺寸，浏览器会并发请求全部候选源（直到首个完成才中断）。
- 补救措施：用
data-srcset替代srcset，配合轻量 JS 监听滚动，只对进入视口的图片注入真实srcset - 关键细节：注入前必须先设置
img.src = ""，否则旧版 Safari 会忽略后续srcset更新 - CDN 配置需开启
Accept头识别（如Accept: image/avif,image/webp,*/*），否则边缘节点无法按需返回对应格式，fallback 逻辑就断了
真正决定带宽成本的，不是你准备了多少种图，而是浏览器在每一毫秒内实际发起的 HTTP 请求路径是否唯一且不可绕过。任何“多给几个选项让浏览器选”的思路，在百万级并发下都会因解析差异变成成本黑洞。
