srcset本身不提供降级能力，仅做资源选择；真正兜底的是src属性，浏览器在srcset所有候选不可用时仍会加载src指向的图，因此src必须指向稳定可用的兼容性资源。
srcset 本身不提供“降级”能力，它只做资源选择；真正兜底的是 src 属性——浏览器在 srcset 所有候选都不可用（格式不支持、路径 404、解析失败）时，仍会加载 src 指向的图。别指望 srcset 自动 fallback 到另一张图，那得靠 onerror。
srcset + sizes 必须配对使用，否则多数浏览器当没写
Chrome 和 Safari 对 srcset 的行为差异很大：不写 sizes 时，Chrome 默认按 100vw 计算所需宽度，Safari 可能直接忽略整个 srcset。结果就是你写了 photo@2x.jpg 2x，但浏览器始终加载最大图，或干脆退回到 src。
-
sizes值必须和 CSS 实际渲染宽度一致，比如容器被max-width: 600px限制，就别写sizes="(max-width: 768px) 100vw" - 每个
srcset项的宽度描述符（如320w）必须对应原图真实像素宽，不能写估算值 - 基础
src属性不可省略——它是 IE11、老 Android WebView 等不支持srcset的唯一入口
srcset 中的 x 描述符和 w 描述符不能混用
用 2x 是告诉浏览器“这张图适配 2 倍屏”，用 320w 是告诉浏览器“这张图原始宽 320 像素”。两者触发逻辑不同，混在同一个 srcset 里会导致部分浏览器解析失败或选错资源。
- 优先用
w+sizes：适配响应式布局，兼容性更好，且能配合 LCP 优化 - 只在固定 DPR 场景（如 App 内嵌 WebView）用
x，例如icon@2x.png 2x, icon@1x.png 1x - 不要写
photo.jpg 1x, photo-2x.jpg 2x, photo-320w.jpg 320w这种混合形式
srcset 资源 404 时不会自动 fallback 到 src，但浏览器仍会加载 src
这是最容易误解的一点：srcset 中某张图返回 404，浏览器不会报错，也不会跳到下一张；它只是跳过那个候选，继续尝试别的，最后无论如何都会走到 src。所以 src 必须指向一个稳定可用的图，比如主站同域下的 /img/fallback.jpg 或 CDN 上的 1px GIF。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 别把
src设为空、"#"或未部署的占位路径，否则用户看到的就是破损图标 - 如果想在
src加载也失败时再补救，必须加onerror，且要防循环：onerror="if (!this.src.includes('fallback')) this.src='/img/fallback.png'; this.onerror=null" -
srcset不解决格式兼容问题：Safari 16.3 以下不支持 AVIF，就算你写了photo.avif 2x，浏览器也会静默跳过，最终加载src——所以格式降级必须用
DevTools 验证 srcset 是否生效，得禁用缓存再刷
浏览器缓存会掩盖 srcset 选图逻辑是否正确。你以为写了 sizes="(max-width: 600px) 320px" 就该加载小图，但实际可能因为缓存一直走大图，导致误判。
- 打开 Chrome DevTools → Network 面板 → 勾选
Disable cache→ 强制刷新页面 - 右键图片 →
Copy→Copy response，粘贴进文本编辑器看实际返回尺寸，确认是否匹配预期 - 检查响应头中的
Content-Type：如果是 WebP/AVIF，必须是image/webp或image/avif，否则浏览器拒绝解码，静默 fallback
真正麻烦的不是写错 srcset，而是以为它能兜底——它不能。所有“降级”意图，最终都要落到 src 是否可靠、onerror 是否防住双重失败这三个点上。漏掉任何一个，弱网或旧设备下就是白屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
