+ 是唯一能按视口宽度切换不同分辨率素材的 HTML 原生方案，因 srcset 单独使用仅适配设备像素比（如 1x/2x），不响应视口宽度变化；若无 sizes，浏览器默认按 100vw 计算导致小屏加载大图，且混用 w 与 x 描述符会使整个 srcset 失效。
srcset 里只写像素密度描述符会掉进分辨率陷阱
很多人以为 srcset 加上 2x 就万事大吉，结果在 iPad Pro（逻辑分辨率 1024×1366，设备像素比 2）或 Windows 高分屏（缩放 125%+）下图片依然糊或加载过大的资源。根本原因是：浏览器按设备像素比（dpr）匹配 2x，但实际渲染宽度受 viewport 缩放、CSS 布局、响应式容器影响，和 dpr 并不严格对齐。
真正可控的是「图片在页面中最终占据的 CSS 像素宽度」——也就是 sizes 要告诉浏览器的部分。没配 sizes，浏览器只能按 100vw 猜，一猜就错。
实操建议：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 永远配
sizes，哪怕只是sizes="100vw"，也比不写强 - 避免纯
2x/3x写法；优先用width描述符（如800w），它和sizes协同工作更可靠 - 把
sizes值写成真实布局中的 CSS 宽度表达式，比如sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
宽高比不一致时，srcset + sizes 仍可能加载错图
当不同 srcset 项的原始图宽高比差异较大（比如一张是 4:3，另一张是 16:9），而 CSS 又强制了固定宽高比（如 aspect-ratio: 16/9 或 padding-top 布局），浏览器可能因内部渲染流程提前选择尺寸，导致拉伸或裁剪。
立即学习“前端免费学习笔记（深入）”；
这不是 bug，是规范允许的行为：浏览器按「当前视口尺寸 + sizes 计算出的渲染宽度」选最接近的 w 项，不校验比例。
实操建议：
- 所有
srcset中的图必须保持相同宽高比，否则降级行为不可控 - 若需多比例支持（如横图/竖图切换），改用
picture+media，把比例差异移到source层级 - 用
object-fit: cover或contain显式控制裁剪/缩放，别依赖 srcset 自动适配
IE 和旧 Safari 不支持 srcset w 描述符，但 fallback 很简单
src 属性就是天然降级通道：所有浏览器都认，且在不支持 srcset 的环境里自动生效。关键是别让它变成「最小图」。
常见错误是把 src 设成 400w 图，然后 srcset 里放 800w/1200w —— IE 用户就永远卡在模糊小图上。
实操建议：
-
src应设为「在多数中等屏设备上足够清晰」的尺寸，比如 800w 或 1024w（不是最小，也不是最大） - 不依赖 JS 补丁（如 picturefill），现代项目已无需兼容 IE11 以下
- 用
img[loading="lazy"]配合srcset，老浏览器忽略loading但不影响src加载
CDN 或构建工具动态生成 srcset 时容易漏掉关键参数
很多团队用 Webpack loader 或 Cloudflare Image Resizing 自动生成 srcset，但默认只输出 2x 或固定几档宽度，没对齐实际 sizes 计算出的渲染宽度，导致「明明有 1200w 图，浏览器却选了 800w」。
根源在于：生成逻辑没接入 layout 上下文，只按预设步长切图，和真实渲染宽度脱节。
实操建议：
- 如果用
sizes="(max-width: 768px) 100vw, 50vw"，那么srcset至少应包含对应 768px、1200px、1920px 视口下的目标宽度图（如768w,1200w,1920w） - 避免「生成 400/800/1600」这种固定倍数链，改用基于典型断点的宽度列表
- 用
chrome://net-internals/#images查看实际加载了哪张图，验证是否匹配预期
最常被忽略的一点：sizes 的值必须和 CSS 实际生效的宽度一致。哪怕只差 1px，浏览器也可能跨档选择——它不四舍五入，而是找绝对差值最小的 w 项。所以调试时别只看设计稿，要真正在 devtools 里测 getBoundingClientRect().width。
