ie11及更早版本不解析，仅渲染内部，故兼容关键在于确保该兜底图片可被所有浏览器正确加载；需用html5shiv解决标签识别、css设picture{display:block}修正渲染、picturefill模拟响应式切换。
IE11 及更早版本不解析 <picture></picture>，整个标签块会被跳过，只渲染内部的 <img src> —— 所以兼容性关键不是“让它支持”，而是确保这个兜底 <img> 能被所有浏览器正确加载并显示。
为什么 IE 里图片直接空白或错位
旧版 IE（尤其是 IE8–10）根本不会创建 <picture></picture> 和 <source></source> 的 DOM 节点，连样式都不继承。这不是 CSS 没生效，是浏览器压根没看见这些标签。
- 如果
<picture></picture>内部没写<img src="xxx.jpg">，整块区域就是空的 - 即使写了
<img>，若它的src是带查询参数的动态地址（如photo.jpg?format=webp），IE 可能请求失败，导致 fallback 失效 -
<img>上加了srcset或sizes？IE 会忽略它们，但若src缺失，照样空白
必须做的三件事：html5shiv + display:block + picturefill
仅引入 html5shiv 不够，它只解决标签识别，不解决渲染行为和运行时逻辑。
- 在
中先加载html5shiv-printshiv.min.js（注意要支持 IE8+ 的版本） - 紧跟着加一段内联 CSS：
picture, source { display: block; }—— 否则<picture></picture>默认是 inline，宽高、margin、浮动全失效 - 再加载
picturefill@4.3.2（v5+ 已放弃 IE 支持），它才是真正模拟<source></source>切换逻辑的运行时垫片 - 加载顺序不能错：html5shiv → CSS → picturefill；否则 IE9 下
onload回调可能丢失
WebP/AVIF 回退失效的常见硬伤
写了 <source type="image/webp"></source> 却还是加载 JPEG，大概率不是浏览器问题，而是链路断在服务端或写法上。
-
type必须是完整 MIME 类型：image/webp，不是webp或image.webp - 服务器返回的
Content-Type响应头必须严格匹配，Nginx 需配置types { image/webp webp; } -
<source></source>顺序不能乱：AVIF → WebP → JPEG，浏览器从上到下匹配，第一个type可解码且media满足就停 -
<img src>必须指向真实可访问的 JPEG/PNG，不能是 404 路径，也不能依赖后端根据Accept头动态返回
不引入 JS 时的纯 HTML 降级底线
构建流程禁 JS、或需极致可控时，别碰 polyfill，用“让旧浏览器自然忽略结构”的方式保底。
- 把关键图放在
<img src="fallback.jpg">，且该 URL 必须直出、无重定向、无鉴权 - 所有
<source></source>放在<img>前面，IE 跳过<picture></picture>后只会读到这个<img> - 不要在外层再包
<div> 做“二次 fallback”，IE 解析异常时 DOM 结构可能错乱 <li>避免用 <code>background-image做 WebP 回退 —— CSS 没有type协商机制，纯前端无解
最容易被忽略的是：<img> 的 src 不是“可选配置”，而是整个 <picture></picture> 在 IE 和旧 WebView 中唯一的图像入口；漏掉它，或者指向不可用资源，就等于主动放弃兼容性。
