loading="lazy"是浏览器原生懒加载方案，仅对img和iframe生效，需满足非首屏、可推断尺寸等条件；失效主因是缺宽高或布局限制；应与IntersectionObserver按需配合使用。
loading="lazy" 是浏览器原生支持的最轻量、最安全的图片延迟加载方案，它不需要任何 JavaScript，也不依赖监听滚动或 IntersectionObserver，只要加一个属性就能生效——但它的行为和兼容性有明确边界，不能盲目依赖。
什么时候 loading="lazy" 会失效？
这个属性只对 <img> 和 <iframe> 生效，且必须满足以下条件之一才会真正延迟加载：
- 元素不在首屏内（即
getBoundingClientRect().top > window.innerHeight） - 元素未设置
width和height，或其尺寸无法被浏览器在解析 HTML 阶段推断（比如用%、vw或 JS 动态设置） - 父容器设置了
overflow: hidden或transform，导致浏览器无法准确判断可视区域（部分旧版 Chromium 行为异常） - 页面启用了
document.write()或存在严重阻塞渲染的同步脚本，可能打断懒加载初始化时机
常见失效现象：loading="lazy" 写了，但所有图片仍随页面一起发出请求——大概率是图片缺少显式宽高，或被包裹在 flex/grid 容器中未设 min-height。
loading="eager" 和 loading="lazy" 的实际加载时机差异
两者不是“立即 vs 滚动触发”，而是“解析时加载”和“布局后按需加载”的区别：
-
loading="eager"：HTML 解析到该标签时，立刻发起src请求（即使它在视口外） -
loading="lazy"：浏览器完成首次 layout 后，再批量检查哪些图片在当前视口或即将进入（通常提前约 1250px），再发起请求 - 没有设置
loading属性时，浏览器行为因 UA 而异：Chrome 默认等同eager，Firefox 早期版本默认lazy，Safari 直到 iOS 16.4 / macOS 13.3 才完整支持
所以，如果你的页面首屏有关键图（如 banner、头图），务必显式写 loading="eager"，否则 Safari 可能把它也懒掉。
与 IntersectionObserver 方案对比：别混用，也别替换
loading="lazy" 是声明式、零成本的基线优化；IntersectionObserver 是命令式、可定制的增强手段。它们不是替代关系：
- 不要给已设
loading="lazy"的<img>再套一层 JS 懒加载逻辑——会导致重复请求或竞态（比如 JS 先把src设为真实地址，浏览器又自己发一次） - 需要提前加载（如滚动前 300px 就加载）、加载失败 fallback、LQIP 占位、响应式
srcset控制等高级能力时，loading="lazy"不够用，必须上 IntersectionObserver - 服务端渲染（SSR）场景下，
loading="lazy"依然有效，而 JS 方案需等 hydration 完成才启动，存在首屏闪动风险
简单判断：只要求“非首屏图不抢带宽”，就只用 loading="lazy"；一旦要控制加载节奏、错误状态或占位体验，就得切到 IntersectionObserver。
兼容性兜底和渐进增强建议
截至 2026 年 5 月，loading="lazy" 在 Chrome 76+、Firefox 75+、Edge 79+、Safari 15.4+ 均稳定支持，但仍有约 3% 的用户使用旧版 Safari 或 WebView。稳妥做法是：
- 所有
<img>必须带width和height（推荐使用 CSS aspect-ratio 替代内联属性，更灵活） - 首屏关键图显式写
loading="eager"，其余图统一写loading="lazy" - 对不支持的 UA，用
@supports not (loading: lazy) { ... }加载轻量 JS 回退逻辑（仅需 1KB 左右的 IntersectionObserver 封装） - 避免在
<picture>外层容器上写loading——它只作用于直接子<img>，<source>不识别该属性
最容易被忽略的一点：loading="lazy" 对 background-image 完全无效，CSS 图片必须走 JS 方案或内联为 <img>。
