loading="lazy"仅在图片初始不在视口内、有真实src、明确宽高、父容器无transform/visibility:hidden等干扰样式且浏览器支持（Chrome 76+/Firefox 75+/Edge 79+/Safari 15.4+）时生效。
loading="lazy" 什么时候生效
只有当 img 在视口外且页面已滚动、或首次渲染时未进入可视区域，loading="lazy" 才会真正延迟加载。它不是“按需加载”，而是由浏览器根据滚动位置和资源优先级自动触发——比如页面顶部的图即使加了 loading="lazy"，也会立即加载；而底部几十屏外的图可能一直不加载，直到用户快滚到那里。
- 必须配合
src（不能只写data-src）才起作用，浏览器靠src发起请求 - 不支持
srcset+loading="lazy"的所有尺寸都延迟：浏览器只 lazy 加载主src或匹配当前 DPR/宽度的srcset项 - 在 Safari 中，
loading="lazy"对 iframe 也有效，但对img的兼容性从 Safari 15.4+ 才稳定（iOS 15.4+）
哪些场景下 loading="lazy" 会失效
最常见的失效不是代码写错，而是布局或 DOM 操作干扰了浏览器的懒加载判断：
- 父容器用了
overflow: hidden或transform，导致浏览器无法准确计算元素是否在视口内 -
img被 JS 动态插入但没设src，或插入后又立刻改src——部分浏览器会跳过懒加载逻辑 - 使用了
position: absolute且没有明确的包含块高度，浏览器可能误判其位置为“永远不可见” - 页面开启了
document.write或严重阻塞渲染的脚本，导致懒加载监听器注册失败
如何验证 lazy 是否真正工作
别只看 Network 面板里有没有请求，重点看请求时机和触发条件：
- 打开 Chrome DevTools → Network → 勾选 “Disable cache”，刷新页面，滚动前观察是否有图片请求；再缓慢向下滚动，看对应
img的请求是否在接近视口时才发出 - 在 Elements 面板中右键
img→ “Break on” → “Attribute modifications”，修改loading值可观察浏览器是否重新评估 - 用
getBoundingClientRect()手动检查某张图的top值，若为正且远大于window.innerHeight，却已发出请求，说明 lazy 被绕过了（常见于 SSR 渲染后 JS 注入了占位图）
loading="eager" 和不写 loading 的区别
显式写 loading="eager" 和完全不写 loading 属性，在行为上几乎一样：都立即加载。但有两点实际差异：
立即学习“前端免费学习笔记（深入）”；
- 不写
loading时，浏览器按默认策略（通常是 eager）处理；写loading="eager"是向其他开发者和自动化工具（如 Lighthouse）表明“此处有意不懒加载” - 某些 CMS 或构建工具会扫描
loading属性做优化，没写的图可能被错误地批量加上lazy，而显式声明eager可规避这类干扰 - 如果全局 CSS 里写了
img[loading="lazy"] { opacity: 0; transition: opacity .2s; }，那没写loading的图就不会受这个样式影响
decoding="async" 或低分辨率占位图来掩盖白屏感。 
