<picture>标签本身不支持loading="lazy"，必须将该属性写在内部<img>标签上才能生效；<source>元素不继承该属性，响应式选图仍由<img>触发时依据srcset和sizes决定。
picture 标签本身不支持 loading="lazy"，但能配合懒加载省流量
直接给 <picture> 加 loading="lazy" 是无效的——这个属性只作用于 <img> 和 <iframe> 元素，<picture> 只是容器，浏览器不会识别它的 loading 属性。真正起懒加载作用的是内部的 <img> 标签。所以省流量的关键不是“怎么配 <picture>”，而是“怎么让里面的 <img> 延迟加载，同时又不破坏响应式逻辑”。
必须把 loading="lazy" 写在 <img> 上，且保留 src
常见错误是只写 <img > 或删掉 src，指望靠 JS 后续赋值。这会导致两个问题：一是 <picture> 无法 fallback（没有 src 就没默认图），二是部分浏览器会直接忽略 loading="lazy" 并报 404；三是 SSR 渲染时可能丢失关键资源。
-
<img>必须有src（哪怕只是小尺寸占位图或 base64 空图），否则<picture>的语义和降级机制就失效 -
loading="lazy"必须加在<img>上，不是<source>上——<source>不继承该属性 - 所有
<source>的srcset和media仍照常工作，浏览器会在<img>触发加载时，根据当前视口条件选择最合适的<source>
正确写法示例：
<picture> <source media="(min-width: 1200px)" srcset="large.webp 2x, large@2x.webp 2x"> <source media="(min-width: 768px)" srcset="medium.webp"> <img src="small.jpg" alt="描述" loading="lazy" width="300" height="200"> </picture>
响应式 + 懒加载要防“错载大图”，得靠 sizes + srcset 配合
只加 loading="lazy" 不等于省流量——如果 <img> 的 src 是大图，而 sizes 没设对，浏览器可能在移动端也拉取了桌面尺寸的图。因为懒加载触发时，浏览器才开始解析 <source> 和 sizes，此时若 sizes 缺失或写死为 100vw，它就按全屏宽度选图，结果还是下载了远超需要的资源。
立即学习“前端免费学习笔记（深入）”；
- 务必为
<img>设置合理的sizes，例如sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" -
<source>的srcset应包含不同密度和宽度的图（如small.jpg 480w, medium.jpg 768w, large.jpg 1200w），而非仅靠media切换 - 优先用
.webp或.avif格式，它们比.jpg小 30%~50%，配合懒加载效果更明显
动态插入或 SSR 场景下，lazy 容易失效，需补检查
服务端渲染（SSR）页面或通过 JS 动态插入的 <picture>，可能出现图片已进入视口、但 loading="lazy" 还没生效的情况。这是因为浏览器解析 HTML 时，滚动位置还没稳定，或 observer 尚未注册完成。尤其在 Safari 15.4+ 中，若父容器用了 transform + overflow: hidden，会导致滚动根节点异常，loading="lazy" 彻底不触发。
- 首次渲染后，手动检查是否在视口内：
img.getBoundingClientRect().top < window.innerHeight，若成立，可主动触发一次img.src = img.src强制加载 - 避免在
<picture>外层容器上同时使用transform和overflow: hidden，改用clip-path或 CSS 容器查询替代 - 不依赖
onload控制显示——display: none的<img>依然会加载，这不是懒加载，只是“藏起来再显示”
真正省流量的核心，是让浏览器在正确时机、用正确尺寸、从正确格式中选一张图——<picture> 提供选择能力，loading="lazy" 控制时机，sizes + srcset 决定选哪张。三者缺一不可，且必须落在 <img> 这个承载体上。
