loading="lazy" 在现代浏览器中基本可靠，但 safari 15.4 前完全不支持，ios 14 及以下无效，且无 js 回退机制；仅对初始不在视口且未被请求的 img 生效，需配合 width/height、srcset/sizes 使用，否则易失效或触发 cls。
loading="lazy" 在现代浏览器中是否可靠
直接说结论：loading="lazy" 在 Chrome 81+、Edge 89+、Firefox 75+ 和 Safari 15.4+ 中已稳定支持，但 Safari 15.4 之前完全不识别该属性（会静默忽略），且在 iOS Safari 中直到 15.4 才开始支持 img（iframe 更晚）。如果你的用户有较老的 iOS 设备（比如 iOS 14 及以下），这个属性不会起任何作用。
它不是 polyfill 友好的属性——没有 JS 回退机制，浏览器不认识就当不存在。所以不能把它当作唯一懒加载手段，尤其面向移动端混合环境时。
哪些 img 场景下设置 loading="lazy" 会失效
loading="lazy" 只对「不在视口内、且未被显式请求过」的图片生效；一旦图片满足任一以下条件，浏览器会立即加载，忽略 lazy：
- 图片位于当前视口内（或距离视口很近，通常约 1250px 内，具体阈值由浏览器决定）
- 父容器设置了
overflow: hidden且图片初始不可见，但部分浏览器（如旧版 Firefox）可能无法正确判断其位置，导致不加载或误加载 - 图片是响应式写法但
sizes或srcset缺失，浏览器可能因无法预估宽高而提前加载 - 图片在
document.write()或 innerHTML 动态插入后立即设loading="lazy"，但 DOM 尚未完成布局计算，部分浏览器会跳过懒加载逻辑
与 IntersectionObserver 手动懒加载的关键区别
loading="lazy" 是声明式、由浏览器原生控制的，无需 JS，但粒度粗、不可配置、无加载状态反馈；IntersectionObserver 是命令式、可编程的，能精确控制阈值、占位行为、错误重试和加载中样式。
典型差异点：
-
loading="lazy"不提供加载失败回调，图片挂了就是空白；IntersectionObserver+img.onerror可降级 fallback -
loading="lazy"无法指定“提前多少像素开始加载”，浏览器自行决定；rootMargin在IntersectionObserver中可设"200px"等明确值 -
loading="lazy"对 CSS 背景图、picture内的source无效；必须作用于img标签本身 - 服务端渲染（SSR）页面中，
loading="lazy"在 HTML 初始输出时即生效，而IntersectionObserver必须等 JS 执行后才启动
实际使用时必须配合的 HTML 结构要点
单独加 loading="lazy" 不够，浏览器需要足够信息来安全延迟加载。务必确保：
- 为
img显式设置width和height属性（非 CSS），否则可能触发 CLS（累积布局偏移） - 如果是响应式图片，
srcset和sizes都要写全，例如：<img src="small.jpg" srcset="small.jpg 480w, large.jpg 1024w" sizes="(max-width: 480px) 100vw, 50vw" loading="lazy"> - 避免在
img上同时用loading="lazy"和 JS 的data-src+ 懒加载库（如 lazysizes），二者冲突，可能导致图片加载两次或不加载 - 测试时注意：Chrome DevTools 的 Network 面板需勾选 “Disable cache”，否则已缓存图片会掩盖 lazy 是否生效
最易被忽略的一点：如果图片父容器用了 display: contents 或 transform，某些浏览器可能无法正确计算其几何位置，导致 loading="lazy" 行为异常——这种场景建议改用 IntersectionObserver 控制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
