srcset里写的是图片固有宽度（w单位）或设备像素比（x单位），非分辨率；w单位需配合sizes声明的页面占位宽度，由浏览器结合视口尺寸与DPR匹配最适源，缺sizes则w失效、退化为x匹配。
srcset 里写的到底是像素密度还是宽度？
很多人在写 srcset 时直接套用 2x，结果高清屏下图片还是糊——因为现代浏览器默认按设备像素比（dpr）匹配，但如果你的 sizes 没告诉它“这张图在页面上实际占多宽”，浏览器就只能瞎猜。真正起作用的是 srcset 中的 w 单位（比如 400w），它表示该资源的**原始像素宽度**，不是显示宽度，也不是 dpr 倍数。
实操建议：
- 优先用
w描述符（如srcset="photo-400w.jpg 400w, photo-800w.jpg 800w"），不用x，除非你只针对固定 DPR 设备（比如仅 iOS Retina） -
srcset中每个资源必须对应一个明确的宽度值，不能混用w和x - 资源文件名不必含数字，但宽度值必须和实际图像自然宽度一致，否则浏览器计算错误
sizes 属性不是“给浏览器看的 CSS 宽度”
sizes 的作用是提前告知浏览器：在不同视口条件下，这张 img 元素将占据多少**CSS 像素宽度**。它不改变布局，也不触发重排，纯属提示。如果写成 sizes="(max-width: 768px) 100vw, 50vw"，意思是“小屏时占满视口，大屏时占一半”，浏览器据此结合 srcset 中的 w 值，算出哪个资源最接近所需渲染宽度（考虑 DPR 后）。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 写了
sizes="100vw"但父容器有 padding/margin，导致图片被拉伸或裁剪——sizes只管逻辑宽度，不管盒模型 - 响应式布局中用媒体查询动态改
width，但sizes没同步更新，浏览器仍按旧值选图 - 漏写
sizes，浏览器退化为仅按 DPR 匹配（即只看2x），完全忽略响应式宽度逻辑
必须保留 src 属性，否则低版本浏览器无法降级
src 不是可选项。即使你写了完整的 srcset 和 sizes，也得配一个基础图源：src 是所有浏览器都认的兜底地址。没有它，IE、老版 Safari 或某些邮件客户端会直接不显示图片。
使用场景与参数差异：
-
src应指向中等分辨率、通用尺寸的图（比如 800px 宽），作为 fallback 和首次加载主力 -
srcset中最小宽度项（如400w）应略大于src图宽，避免重复下载 - 若用 WebP/AVIF 等新格式，
src仍需是 JPEG/PNG，否则不支持新格式的浏览器空白
调试时怎么看浏览器到底加载了哪张？
别靠肉眼猜。打开 DevTools → Network 面板，过滤 Img，刷新页面，看请求的 URL 是否匹配你 srcset 中某一项；再点开该请求的 Headers，检查 Request Headers → Device-Memory 和 DPR（部分浏览器暴露），结合当前视口宽度，反推浏览器的决策逻辑。
容易踩的坑：
- 本地测试用 file:// 协议，部分浏览器禁用
srcset自适应（尤其 Safari），务必起本地服务（如python3 -m http.server） - Chrome 模拟器里切设备后没刷新，
sizes仍按上一次视口计算，要硬刷新 - CDN 或图片服务自动压缩/转码，可能把原图 1200w 改成 1183w，导致
srcset宽度声明失准，浏览器误判
真正麻烦的是设计稿给的“适配规则”和前端实现之间存在语义断层：设计师说“小屏占满，大屏留边”，你得把它翻译成精确的 sizes 表达式，再对齐到真实图片尺寸链。这一步错一点，后续所有资源选择就全偏了。
