src是必填兜底项，srcset是可选增强项；只写srcset不写src会导致IE11等老浏览器空白；src需指向可用基础图，srcset按密度或宽度提供多档图，sizes须精准匹配布局。
img 标签的 src 和 srcset 怎么配才不丢图
浏览器加载图片时，src 是必填兜底项，srcset 是可选增强项。如果只写 srcset 不写 src，老浏览器（如 IE11）或禁用 JS 的环境会直接不显示图片——不是模糊，是空白。
-
src必须指向一张可用的、尺寸适中的基础图（比如 800px 宽的 WebP 或 JPEG） -
srcset里按像素密度或宽度提供多档图，格式统一用 WebP（现代浏览器支持好），再用type属性声明 MIME 类型 -
sizes要写具体，不能只写"100vw"就完事；根据实际布局算出图片在视口中的预期宽度（例如"(max-width: 768px) 100vw, 50vw"）
<img
src="photo-800.jpg"
srcset="photo-400.jpg 400w,
photo-800.jpg 800w,
photo-1200.webp 1200w"
sizes="(max-width: 480px) 100vw,
(max-width: 960px) 50vw,
33vw"
alt="示例照片">WebP 不支持时怎么 fallback 到 JPEG/PNG
picture 元素才是真正的降级控制中枢，img 自身没有格式 fallback 能力。靠 source 的 type 属性触发浏览器自主选择，不依赖 JS。
- 每个
source必须有srcset（不能只写src），且type值要精确匹配 MIME 类型（"image/webp"，不是"webp"） -
img标签必须放在picture最后，作为所有source都不匹配时的最终 fallback - 注意：Safari 14+ 才开始稳定支持
type="image/webp"，旧版 Safari 会跳过 WebPsource直接走img
<picture> <source type="image/webp" srcset="photo.webp"> <source type="image/avif" srcset="photo.avif"> <img src="photo.jpg" alt="示例照片"> </picture>
JS 禁用或图片加载失败时怎么补救
img 的 onerror 只捕获加载失败，不捕获格式不支持；而且它只在 DOM 渲染阶段生效，无法覆盖 picture 的原生格式协商逻辑。
- 不要用
onerror替换src来“兜底 WebP”，因为此时浏览器已决定不用这张图，再改src也不会重试 - 真正可控的方式是：服务端根据
Accept请求头返回不同格式（比如识别到image/webp不在 Accept 列表就发 JPEG），前端保持最简img src="photo.jpg" - 如果必须前端判断，可用
document.createElement('img').canPlayType('image/webp')（注意：这是试探性检测，非 100% 准确），但更推荐用picture+type让浏览器自己选
CDN 或构建工具里容易漏掉的兼容点
很多自动化方案默认只生成 WebP，却忽略两个关键事实：
立即学习“前端免费学习笔记（深入）”；
iOS 13.4 之前的 Safari 不支持 WebP 动画，也不支持带 alpha 的 WebP 在某些混合模式下渲染
Article To Html下载文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
Cloudflare、Cloudinary 等 CDN 的“自动格式转换”开关打开后，可能把
src原图也转成 WebP，导致老浏览器彻底白屏构建时生成多格式图，但 HTML 中仍保留原始
src指向 JPEG，靠picture提供 WebP/AVIF 分支CDN 开启格式优化时，务必确认它是否保留了对
Accept头的尊重；否则需手动加Vary: Accept响应头，避免缓存污染不要相信“用户都用新浏览器”的假设：微信内置浏览器（X5 内核）、部分国产安卓浏览器仍卡在 Chromium 60–70 之间，WebP 支持不稳定
真正难的不是写出降级语法，而是搞清每张图在哪个设备、哪个网络、哪个缓存层级上会被怎么解析——这些细节一漏，降级就变成单点失效。
