picture渐进加载的核心逻辑是手动控制资源加载时机：它本身仅为资源选择器，需结合data-srcset/data-src与IntersectionObserver动态赋值，并调用img.decode()确保渲染，避免浏览器自动并发请求导致带宽浪费。
什么是 picture 渐进加载的核心逻辑
picture 本身不直接提供“渐进加载”能力，它只是根据媒体条件选择最合适的 source 或回退到 img。真正实现渐进加载（比如先展示低质量占位图，再替换为高清图）得靠 srcset + sizes 配合 JavaScript 控制加载时机，或用 loading="lazy" 做基础延迟，但那不算真正渐进。关键点在于：必须手动控制图片资源的加载顺序和触发时机，picture 只负责声明“有哪些可选资源”。
用 picture + data-srcset 手动触发加载
这是最可控、兼容性好、不依赖第三方库的做法。把真实资源地址存在 data- 属性里，等占位图就绪或进入视口后再赋值给 srcset 和 src。
- 占位图用内联 SVG 或极小尺寸 Base64，确保无网络请求也能渲染骨架
- 所有
source的srcset和img的src全部清空，改用data-srcset、data-src存真实地址 - 用
IntersectionObserver监听进入视口，然后遍历该picture下的每个source和img，把data-*值复制过去并触发加载 - 注意：赋值后需显式调用
img.decode()（尤其 WebP/AVIF）避免渲染卡顿
<picture> <source media="(min-width: 1024px)" data-srcset="hero-large.webp 1x, hero-large@2x.webp 2x"> <source media="(min-width: 768px)" data-srcset="hero-medium.webp 1x, hero-medium@2x.webp 2x"> <img alt="Hero" width="300" height="200"> </picture>
为什么不能只靠 srcset + sizes 实现渐进
浏览器对 srcset 的解析是声明式且一次性触发的——只要 picture 插入 DOM，所有匹配的 source 就会并发发起请求（即使你还没滚动到它）。这会导致：
- 提前加载大量非可视区域图片，浪费带宽
- 无法控制“先加载模糊图，再替换清晰图”的两阶段流程
- 没有加载状态反馈（如 loading spinner），用户感知差
-
img的complete事件在srcset切换后不可靠，难以精准监听完成
所以必须剥离自动加载行为，用 JS 掌控生命周期。
立即学习“前端免费学习笔记（深入）”；
容易忽略的兼容性和细节
-
picture 在 IE 中完全不支持，哪怕加了 polyfill（如 respimage），其 data-srcset 行为也和现代浏览器不一致；若需支持 IE，得降级为单 img + JS 切换 src
- Safari 对
decode() 的 Promise reject 处理较严格，建议包裹 try/catch
- 如果页面有 SSR，服务端渲染时不要输出真实
srcset，否则爬虫和首屏会提前加载；保持占位结构即可
-
img 的 width/height 属性必须保留，否则 CSS aspect-ratio 不生效，导致布局偏移（CLS）
picture 在 IE 中完全不支持，哪怕加了 polyfill（如 respimage），其 data-srcset 行为也和现代浏览器不一致；若需支持 IE，得降级为单 img + JS 切换 src
decode() 的 Promise reject 处理较严格，建议包裹 try/catch
srcset，否则爬虫和首屏会提前加载；保持占位结构即可img 的 width/height 属性必须保留，否则 CSS aspect-ratio 不生效，导致布局偏移（CLS）渐进加载真正的复杂点不在 picture 标签怎么写，而在于何时触发、如何防重复、怎么处理 decode 失败、以及 SSR/CSR 一致性。这些没法靠 HTML 属性自动搞定。
