picturefill.js是唯一靠谱选择，因IE9–11等旧环境原生不解析<picture>，仅渲染<img src>，而它严格模拟浏览器匹配逻辑（media→type→fallback），动态设置<img>资源，且经广泛验证持续维护。
旧浏览器不支持 <picture> 标签，必须用 picturefill.js 做 polyfill，且不能只靠它“自动修复”——它只补 DOM 解析和资源选择逻辑，不解决 <source> 顺序、srcset 写法或服务器 MIME 配置等根本问题。
为什么 picturefill.js 是唯一靠谱选择
IE9–11、Android 4.4 WebView、Safari ≤ 9 等环境原生不解析 <picture>，会直接跳过所有 <source>，只渲染 <img> 的 src（若没写则空白）。picturefill.js 是目前唯一被广泛验证、持续维护、且严格遵循规范的 polyfill：它监听 DOM 加载，手动遍历 <picture>，模拟浏览器的匹配逻辑（media → type → fallback），并动态设置 <img> 的 src 或 srcset。其他方案如手写 JS 模拟，极易漏掉 sizes 计算、DPR 判断或 type MIME 检测。
- 必须用
picturefill.min.js（UMD 版本），不能用 ES 模块版——IE 不支持import - 加载时机很关键：需在
<picture>DOM 就绪后执行，推荐放在</body>前，或用document.addEventListener('DOMContentLoaded', ...) - 不兼容
loading="lazy"：polyfill 期间无法触发原生懒加载，需额外监听scroll或用IntersectionObserver补
<source> 写法错误会让 picturefill.js 完全失效
picturefill.js 只模拟标准行为，不修正错误语法。以下任一情况都会导致它退化为只加载 <img src>：
-
<source>缺srcset：即使写了media或type，没有srcset就无资源可选 -
media值漏括号：max-width: 768px是非法媒体查询，必须写成(max-width: 768px) -
type与服务器响应头不一致：比如写了type="image/webp"，但服务器返回Content-Type: image/jpeg，picturefill.js会跳过该<source> -
<img>没写src：IE 下若<img>无src，页面直接空白；picturefill.js不会帮你 fallback 到srcset
如何避免 polyfill 引入后反而更慢
picturefill.js 本身体积小（~5KB gzip），但滥用会导致性能倒退：
立即学习“前端免费学习笔记（深入）”；
- 不要全局加载：只在有
<picture>的页面引入，或用if ('HTMLPictureElement' in window) {...}检测后按需加载 -
sizes必须真实反映 CSS 渲染宽度：若 CSS 设了width: 300px，但sizes写成"100vw"，picturefill.js会预估错尺寸，加载过大图 - 禁用
srcset中的x描述符：IE 不支持window.devicePixelRatio精确检测，picturefill.js对2x的处理是降级为1x，不如直接用w+sizes - 服务端注意：CDN 或图片服务若对
Accept: image/webp响应不一致，type匹配会失败，此时应删掉type改用media控制
现代项目里要不要用 picturefill.js
如果目标用户仍有 IE11 或 Android 4.x 流量（比如政企内网、IoT 设备管理页），就必须用；否则，2026 年多数场景可直接弃用：Chrome 38+、Firefox 33+、Edge 16+、Safari 9.1+ 已原生支持 <picture>，且 CanIUse 数据显示全球 IE11 使用率已低于 0.3%。真正容易被忽略的是：哪怕用了 polyfill，<picture> 的语义价值（如可访问性、SEO）在旧浏览器中依然丢失——屏幕阅读器不会把 <source> 当作替代内容读出，alt 仍只来自 <img>。
