loading="lazy"仅适用于明确不在首屏内、有固定宽高且处于正常文档流中的图片；首屏关键图、无尺寸属性、父级用transform/visibility:hidden、在iframe内或浏览器不支持时均会失效。
loading="lazy" 是浏览器原生支持的图片延迟加载机制，无需 JavaScript 就能触发懒加载，但它的行为受容器可见性、滚动位置和浏览器实现影响，并非所有 <img> 都适合加——加了可能没效果，甚至导致图片不显示。
哪些图片适合加 loading="lazy"
它只对「默认不在首屏内」的图片有意义。浏览器会根据元素是否进入或即将进入视口来决定何时发起请求。
- 明确位于页面中下部、需滚动才能看到的
<img>（如文章配图、商品列表图） - 在折叠区域、Tab 页签内、模态框中初始隐藏的图片（前提是该容器本身可滚动或有布局流）
- 使用
display: none或visibility: hidden的图片无效——loading="lazy"依赖 layout 流，脱离文档流或不可见容器会跳过加载判断 - 首屏大 Banner、Logo、关键操作图标等必须立即加载的图片，不要加；加了反而可能因竞态或解析延迟导致白屏
loading="lazy" 不生效的常见原因
加了属性却还是立即加载，通常不是语法错，而是环境或结构问题：
- 图片本身已在视口内（比如页面高度小于一屏，或图片紧贴顶部）——浏览器认为“已可见”，直接加载
- 父容器设置了
overflow: hidden且未设高度，导致浏览器无法准确计算滚动边界 - 使用了
position: fixed或position: absolute且脱离正常文档流，部分浏览器（尤其是旧版 Safari）无法跟踪其位置 - 页面未声明
<meta name="viewport">，移动端 WebView 可能降级处理或忽略该属性 - Chrome 早期版本（loading="lazy" 在
<picture></picture>内部的支持不一致；建议直接写在最内层<img>上，而非包裹它的<source></source>
与 IntersectionObserver 的关键区别
原生 loading="lazy" 是声明式、轻量级的，但控制粒度远不如 JS 方案：
- 无法自定义阈值（比如提前 200px 加载），浏览器内部用的是固定偏移（通常约 1250px）
- 不支持加载失败回调、占位图切换、错误重试逻辑
- 无法监听加载状态（
onload/onerror仍可用，但不能和懒加载时机联动） - 在低性能设备或后台标签页中，加载可能被进一步延迟甚至暂停，而
IntersectionObserver至少能保证回调触发 - SSR 渲染时，服务端不会预判懒加载，所以首屏 HTML 中仍含完整
src；若想真正减少首屏请求数，需配合响应式srcset+sizes
最小可行写法与兼容性注意
最简有效写法就是直接加属性，但要注意几个硬性前提：
@@##@@
- 必须有
src（不能是空字符串或占位符 URL），否则 Chrome 会静默忽略loading属性 - 不支持 IE 和 Safari ≤ 15.4；Safari 15.4+ 才开始支持，且仅限
<img src="photo.jpg" loading="lazy" alt="描述">，不支持<iframe></iframe> - Firefox 自 75+ 支持，但默认启用；Chrome 自 76+ 默认开启，无需 flag
- 如果用了 WebP + fallback，确保
<picture></picture>内每个<source></source>都不带loading，只在<img>上加
真正容易被忽略的是：当图片通过 CSS background-image 引入时，loading="lazy" 完全无效——它只作用于 HTML 中的 <img> 和 <iframe></iframe> 元素。如果业务中大量使用背景图，那就得回到 IntersectionObserver 或 CSS @media + JS 切换方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
