DevTools Network面板不能仅凭请求出现判断loading="lazy"是否生效，需结合Disable cache硬刷新后滚动前无请求、滚动近视口时才触发请求，以及Elements面板Break on attribute modifications断点验证src变更；Lighthouse仅检测属性存在，不校验实际行为，易误判。
DevTools Network 面板不能只看“有没有请求”
loading="lazy"是否生效，不能只刷新页面后盯着 Network 面板等图片出现——因为浏览器可能在首次 layout 后批量预取（通常提前约 1250px），你看到的“早于滚动就发了请求”，不等于没懒加载，而是它本就属于预取范围。
真正有效的验证方式有两个信号，缺一不可：
- 勾选
Disable cache，硬刷新页面，滚动前 Network 里完全看不到该<img>的请求 - 滚动到图片即将进入视口时，请求才突然出现，且时间点明显滞后于 HTML 解析和 DOMContentLoaded
Elements 面板右键 Break on attribute modifications
这是最直接的证据：原生 lazy 加载时，浏览器会在合适时机自动把 src 属性从空值或占位值（如 data:image/svg+xml,%3Csvg%3E）替换成真实 URL。这个动作会触发 DOM 属性变更。
操作步骤：
立即学习“前端免费学习笔记（深入）”；
- 在 Elements 面板中找到目标
<img>节点 - 右键 → Break on attribute modifications
- 滚动页面，让该图接近视口
- 如果断点被触发，且修改的是
src，说明原生 lazy 正在接管；如果始终没断点，大概率没生效
为什么 Lighthouse “Offscreen images” 建议不可信
Lighthouse 只扫描 HTML 中是否存在 loading="lazy" 属性，完全不校验行为是否真实发生。它会把写了属性但因缺宽高、父容器用了 transform、或 JS 动态插入导致退化为 eager 的图片，统统算作“已优化”。
常见误判场景：
-
<img src="x.jpg" loading="lazy">没写width/height→ Safari 直接降级为 eager，Lighthouse 却打勾 ✅ - 图片在
<div style="overflow: hidden">里 → Chrome 可能跳过懒加载检测，Lighthouse 仍认为 OK - React/Vue 渲染的列表图 → 不属于初始 HTML，
loading="lazy"被忽略，但 Lighthouse 看不到 JS 运行时结构
首屏关键图必须显式设 loading="eager" 再验证
别跳过这步——Safari（尤其 iOS 16.3 及更早）对未声明 loading 的图片行为不一致，可能直接跳过加载，导致 Banner 白屏。验证 lazy 是否工作前，先确认首屏图是 loading="eager" 且配了完全一致的 <link rel="preload" as="image" href="xxx">。
否则，你测的可能不是 lazy 失效，而是 Safari 根本没发起请求。
复杂点在于：lazy 是浏览器内部调度的黑盒行为，没有日志、不暴露阈值、无法 hook。你只能通过 DOM 变更和网络时序反推，而这两者又极易被缓存、预加载、服务端渲染干扰。真要 100% 确认，就得关缓存 + 断点 + 滚动慢速逼近。
