srcset未生效主因是浏览器按DPR、网络条件等动态选图，并非强制用大图；需确保候选图可访问、优先用宽度描述符、picture中source按顺序匹配媒体查询、优化图片体积与格式、配置cdn缓存及响应头。
srcset 为什么没生效？检查浏览器是否忽略高 DPR 图片
很多开发者写了 srcset 却发现页面始终加载小图，实际是浏览器根据设备像素比（DPR）、网络条件（如 Save-Data 头）和自身策略动态选择——不是写了就一定用大图。chrome 会优先选「刚好够用」的尺寸，比如 DPR=2 的手机访问时，1x 图可能被跳过，但若你只提供了 1x 和 3x，它可能因无 2x 而降级回 1x。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
chrome://net-internals/#events过滤URL_REQUEST，看实际发起的图片请求地址 - 确保
srcset中每个候选源都真实存在且可访问，404 会导致浏览器静默 fallback 到src - 避免只写缩放倍率（如
img.jpg 2x），优先用宽度描述符（如img-400w.jpg 400w），更可控
picture 标签里 media 查询没触发？注意语法和匹配顺序
media 条件的即生效**，后续不管是否更匹配都会被跳过。常见错误是把宽屏规则写在窄屏前面，或者 media 值写成 (min-width: 768px) 却忘了加单位（768 不合法，必须是 768px）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把最具体的媒体查询（如
(min-width: 1200px) and (orientation: landscape)）放在前面，通用兜底（如(min-width: 320px)）放最后 - 用 DevTools 的「Toggle device toolbar」手动切换 viewport 宽度 + 刷新，观察
currentSrc属性变化 -
srcset或src，空
加载还是卡顿？关键不是 srcset，而是图片体积和解码开销
即使 srcset 正确选中了 800w 的图，如果这张图是未压缩的 PNG 或原图直出的 JPEG，首字节时间（TTFB）和解码时间仍会拖慢渲染。浏览器下载后还要解码、缩放、合成，尤其在低端 android 设备上，一张 3MB 的 WebP 可能比 200KB 的 AVIF 多花 300ms 解码。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对同一张图生成多尺寸 + 多格式：WebP（现代浏览器）、AVIF（Chrome 110+、firefox 119+）、JPEG（兼容兜底）
- 用
- 所有图片必须加
decoding="async"，避免阻塞主线程解码；对非首屏图加loading="lazy"
CDN 和缓存头配置不当，让 srcset 形同虚设
CDN 默认可能对不同 srcset 地址做独立缓存，但若你用的是带查询参数的 URL（如 img.jpg?w=400），而 CDN 没开启 Ignore Query String，就会为每个尺寸建一个缓存键，导致缓存命中率暴跌。更隐蔽的问题是，服务端返回的 Cache-Control: no-cache 或缺失 ETag，会让浏览器反复请求同一张图。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用固定路径代替查询参数：
/img/photo-400w.webp而非/img/photo.webp?w=400 - 确认 CDN 缓存策略识别
Accept请求头（用于格式协商），并为image/avif和image/webp设置独立缓存规则 - 服务端响应必须带
Vary: Accept, DPR（若支持 DPR 检测）或至少Vary: Accept，否则中间代理可能混发格式
真正卡住的往往不是标签怎么写，而是图片生成链路没闭环：设计稿切图 → 自动化压缩 → 多格式导出 → CDN 缓存策略 → 浏览器解析行为，漏掉任意一环，srcset 和 picture 都只是纸面优化。