loading="lazy"仅对html源码中真实存在、不在首屏内、有合法src、未被overflow:hidden裁剪的img生效；必须搭配width/height、decoding="async"及合理sizes使用，且不适用于内。
原生 loading="lazy" 是 HTML 模板里最优先采用的懒加载方式，它零 JS、无运行时开销、浏览器原生调度，只要模板能直接写入该属性，就比任何 JS 方案快且稳。
哪些图片必须加 loading="lazy" 才真正起效
只对满足以下全部条件的 <img> 标签生效：
- 标签在 HTML 源码中真实存在（服务端渲染/静态 HTML 输出时已写入），不是客户端 JS 动态插入的
- 图片不在初始视口内——浏览器按设备 DPR、viewport 宽高、滚动偏移实时判定，不是按 HTML 顺序数第几张
-
src值为合法 HTTP(S) URL（不支持data:、blob:或 CSSbackground-image） - 没被父容器
overflow: hidden裁剪导致不可见（IntersectionObserver 也受此限制）
常见误用：CMS 富文本编辑器过滤了 loading 属性，或模板引擎未开放该字段变量，结果 HTML 里根本没这个属性——加了等于没加。
loading="lazy" 和 srcset/sizes 怎么配才不拉错图
二者必须同时存在，且 sizes 必须合理，否则懒加载触发时浏览器无法预估宽度，可能从 srcset 中选错资源（比如移动端加载了 2x 大图）。
正确写法示例：
@@##@@
- 不要省略
sizes，哪怕只是写sizes="100vw" - 避免在
srcset里混用不同 DPR 图但没配sizes，懒加载阶段 DPR 判断可能滞后 -
<picture></picture>和<source></source>不支持loading属性，必须写在最外层<img src="photo-small.jpg" srcset="photo-small.jpg 400w, photo-medium.jpg 800w, photo-large.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" alt="描述" loading="lazy">上
为什么 IntersectionObserver 不能简单“补位”原生 lazy
它本质是降级方案，不是增强。在支持 loading="lazy" 的浏览器里硬上 JS 实现，反而引入额外解析、执行、内存开销。
- 初始化时机错位：若 JS 在
DOMContentLoaded后才注册IntersectionObserver，首屏已滚过，第一批图片会“闪现加载” - 重复监听风险：没做
img.complete检查，缓存中已加载完成的图片可能被清空src再赋值，触发重请求 - rootMargin 设太小（如
"0px"）会导致滚动快时图片进入视口才触发，用户看到空白；设太大（如"500px"）又提前加载，浪费带宽 - 服务端模板若已输出
loading="lazy"，再跑一遍 JS 懒加载逻辑，属于冗余叠加
真正要动手写 JS 懒加载，只发生在两个明确场景：老浏览器兜底（IE / Safari loading="lazy" 写进模板，比调任何库都快、都干净。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
