<picture> 是 PNG 降级的首选方案，因其支持按顺序尝试多个 <source> 并自动跳过不支持格式，最终回退到 <img> 中的 PNG；而 <img> 单独使用无降级能力。
为什么 <picture> 是 PNG 降级的首选方案
直接用 <img src="xxx.png"> 无法实现降级——浏览器要么加载 PNG，要么报错，没有“退而求其次”的机制。真正可控的降级必须依赖 <picture> 的源选择逻辑，它让浏览器按顺序尝试多个 <source>，遇到第一个能解析且满足条件的就停止。
关键点在于：浏览器对不支持的格式（比如旧版 IE 不认 WebP）会跳过对应 <source>，继续检查下一个；而 <img> 作为 fallback 元素，只要前面所有 <source> 都没被选中，它就一定会被加载。
-
<source>的type属性必须精确匹配 MIME 类型，例如type="image/webp"，写成"webp"或"image/png"无效 - IE11 及更早版本完全不支持
<picture>，此时只会渲染内部的<img>，所以把 PNG 放在<img>里才是真正的兜底 - 不要依赖
media查询做格式降级——那是为响应式尺寸设计的，和格式兼容性无关
如何组织 <source> 顺序避免加载错误格式
顺序决定成败：浏览器从上到下逐个检查 <source>，一旦某个满足 type 且资源可获取，就立即使用它，后面的全被忽略。所以要把最现代、压缩率最高的格式放在最前，兼容性最广的放最后（但不是最末尾——<img> 才是最终 fallback）。
典型结构如下：
立即学习“前端免费学习笔记（深入）”；
<picture> <source srcset="logo.webp" type="image/webp"> <source srcset="logo.avif" type="image/avif"> <img src="logo.png" alt="Logo"> </picture>
- AVIF 虽然更优，但 Safari 16.4+ 才稳定支持，放 WebP 后面更稳妥
- 不能把
<img src="logo.jpg">放在最后——JPG 不支持透明通道，PNG 降级目标通常是保留 alpha，所以 fallback 必须是 PNG -
srcset在这里只是单图引用，不需要写2x或媒体查询；如需响应式，再叠加media属性
旧版 IE（≤11）下 PNG 仍不显示？检查是否漏了 <meta http-equiv="X-UA-Compatible" content="IE=edge">
即使用了 <picture> + <img>，IE9–11 有时仍空白，常见原因是文档模式被强制锁定在 IE7/8 兼容模式，导致连 <img> 都不渲染。这不是 PNG 本身的问题，而是 IE 的解析上下文失效。
- 必须在
<head>最顶部加入<meta http-equiv="X-UA-Compatible" content="IE=edge">，否则 IE 自动降级 - 如果项目用 ASP.NET 或某些 CMS，可能全局注入了旧版兼容头，要优先覆盖
- 仅靠
<picture>polyfill（如 picturefill）不能解决这个问题——polyfill 只补 DOM 行为，不修复文档模式
要不要加 JavaScript 检测来主动替换？通常没必要
有人会写脚本检测 document.createElement('picture').canPlayType 或用 Image 加载 WebP 再 onload 切换，这种做法在多数场景反而引入新问题：
- 首屏图像会闪一下（先占位，再 JS 替换），影响 LCP
- JS 错误或阻塞时，图片彻底不出现
- 搜索引擎爬虫可能不执行 JS，导致索引不到主图
-
<picture>原生支持已覆盖 Chrome 38+、Firefox 38+、Safari 9.1+、Edge 13+，覆盖率达 98% 以上（2024 年数据）
真正需要 JS 介入的，只有极少数定制场景：比如需根据用户网络类型（navigator.connection.effectiveType）动态选图，或服务端未提供 AVIF/WebP，需客户端实时转码（不现实，仅理论）。
格式降级这件事，浏览器原生机制已经足够可靠；花力气优化 <source> 顺序和 fallback 图片质量，比写一堆检测逻辑更实在。
