srcset失效不会报错，浏览器静默回退到src；确认方法是禁用缓存后硬刷，查看Network中实际加载的图片URL是否匹配预期尺寸与sizes计算结果。
srcset 解析异常不会报 JS 错误，浏览器会静默 fallback 到 src，但你可能根本没意识到它失效了——比如本该加载 320w 的图，结果全端都走了 1200w 的大图，LCP 直接超标。
怎么确认srcset真没起作用
别猜，直接看 Network 面板实际加载的 URL：
- 用 Chrome DevTools 打开 Network → 勾选 Disable cache，硬刷新页面
- 找到对应图片请求，右键 → Copy → Copy response，粘贴进文本编辑器看尺寸是否匹配预期
- 如果返回的是最大尺寸图，且
sizes属性存在但值为(max-width: 768px) 100vw, 50vw，而实际容器被 CSS 限制在max-width: 600px，那浏览器算出的目标宽度就偏大，自然选错源 - 检查响应头是否有
Vary: Width或Vary: DPR—— CDN 如果没配这个，缓存可能把高 DPR 图返回给低 DPR 设备
srcset 中的 w 描述符写错是最常见原因
320w 不是“大概 320 像素宽”，而是指这张图文件的真实原始宽度必须正好是 320 像素。写错会导致浏览器内部计算的目标尺寸失准，进而跳过所有 srcset 项。
- 用
identify -format "%wx%h" photo-320.jpg（ImageMagick）或在线工具验证原图尺寸，不能靠文件名或 CMS 缩略图配置臆断 - 禁止混用
w和x：比如srcset="a.jpg 1x, b.jpg 2x, c.jpg 320w"是非法语法，整条srcset会被忽略 - 不支持
srcset的旧浏览器（如 IE11）会直接忽略它，所以src必须始终存在且指向一个可用的、已压缩的 JPG/PNG
sizes 写法不对，srcset 就等于白写
sizes 不是“建议浏览器怎么显示”，而是告诉预加载器“这张图在不同视口下会占用多少 CSS 像素宽”，它直接影响资源选择时机。写错会导致浏览器按默认 100vw 加载，浪费带宽还易超时。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 确保
sizes媒体查询与真实 CSS 布局一致：比如容器有margin: 0 auto; max-width: 600px;，就不能写sizes="(max-width: 768px) 100vw"，应改为sizes="(max-width: 600px) 100vw, 600px" - 避免用
calc()或自定义属性：CSS 变量、env()、clamp()在sizes中均不被支持 - 移动端若用了
transform: scale(0.5)，sizes计算仍基于原始布局宽度，不会自动缩放，此时需手动调整值
降级不是等失败才动手，而是从结构上兜底
真正健壮的方案，从来不是指望 srcset 单打独斗，而是分层控制：
-
src永远指向一张小尺寸、高压缩、CDN 缓存稳定的 JPG（如 400px 宽），它是所有 fallback 场景的最终载体 - 用
onerror监听最终加载失败：onerror="this.src='/img/placeholder-400.jpg'; this.onerror=null"，防止 fallback 图也挂掉导致死循环 - 对关键图（如商品主图），禁用
loading="lazy"；懒加载只用于非首屏，且必须配合data-srcset+ JS 主动替换，否则srcset在懒加载触发前就已失效 - 服务端渲染时，确保输出的 HTML 中
src和srcset路径都是静态、可直连的绝对 URL，不要依赖客户端 JS 拼接
最常被忽略的一点：你改了 srcset 和 sizes，但没清 CDN 缓存，浏览器拿到的还是旧 HTML —— 所以排错第一步永远是禁用缓存再测，而不是立刻重写逻辑。
