loading="lazy"仅对满足三条件的标签生效：普通内容图、非iframe/Shadow DOM内、有明确src；Safari 15.4前需IntersectionObserver降级；必须预留宽高防布局抖动。
图片懒加载不是“加个属性就完事”，关键在 loading="lazy" 的实际生效条件和 fallback 方案是否可靠——它在 Safari 15.4+ 之前完全不支持，且对背景图、picture 内嵌源无效。
哪些图片能直接用 loading="lazy" 安全生效
只有满足全部三个条件的 <img alt="如何用图片懒加载技术减少首屏带宽占用提升交互速度" > 标签才真正触发原生懒加载：
- 必须是普通内容图（非 CSS
background-image） - 不能在
iframe或 Shadow DOM 内部 - 必须有明确的
src（不能只靠srcset或data-src）
常见误用：<img srcset="..." sizes="..." alt="如何用图片懒加载技术减少首屏带宽占用提升交互速度" > 却没写 src，此时浏览器会立即下载第一个 srcset 项，loading="lazy" 形同虚设。
Chrome/Firefox 支持但 Safari 需要 polyfill 的真实场景
Safari 直到 15.4 才支持 loading="lazy"，而国内大量 iOS 用户仍卡在 15.0–15.3。此时必须降级：
- 检测
'loading' in HTMLImageElement.prototype判断原生支持 - 不支持时，用
IntersectionObserver监听进入视口事件 - 务必把
data-src转为src后再触发加载，避免重复解析
示例关键逻辑：
if (!('loading' in HTMLImageElement.prototype)) {
const io = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
io.unobserve(img);
}
});
});
document.querySelectorAll('img[data-src]').forEach(img => io.observe(img));
}
loading="lazy" 和自定义 lazyload 的性能差异点
原生方案优势明显，但有几个硬约束容易被忽略：
- 原生懒加载**不保证加载时机**：它可能在元素距视口还有 200px 时就开始请求，无法控制预加载距离
- 不支持“加载失败后自动重试”或“加载中占位图”逻辑，这些必须自己补
- 对 WebP/AVIF 等现代格式无特殊优化，仍走常规解码流程
如果你需要精确控制加载阈值（比如提前 500px 加载），或统一处理错误状态，IntersectionObserver + 手动 src 赋值仍是更可控的选择。
最常被跳过的一步：懒加载后图片尺寸未预留，导致布局抖动（layout shift）。无论用哪种方式，width/height 属性或 aspect-ratio 必须存在，否则 CLS 指标会直接变红。
