loading="lazy"并非加了就生效，需满足浏览器支持（Chrome 76+等）、明确宽高、图片不在首屏、父容器无transform/opacity等干扰样式，且必须写在而非内；否则会全量加载或白屏。
loading="lazy" 是当前最直接有效的逐张加载方案，但加了不等于生效——它依赖浏览器原生支持（Chrome 76+、Firefox 75+、Edge 79+、Safari 15.4+），且对使用方式极其敏感。老浏览器会自动忽略该属性，降级为正常加载；而现代浏览器若检测到风险（如缺尺寸、父容器异常），也会静默跳过懒加载逻辑。
为什么 loading="lazy" 加了却没逐张触发
常见现象是页面滚动时图片“一批涌出”或干脆全量加载，根本不是逐张按需。核心原因有三个：
- 图片没有明确的
width和height（内联或 CSS 均可），浏览器无法预留占位空间，为防布局抖动（CLS）直接放弃懒加载 -
img父容器用了transform+overflow: hidden（比如轮播图 wrapper），导致 Chrome 误判滚动根节点，所有子图永远收不到进入视口信号 - 图片本身在 HTML 中已位于首屏范围内（
getBoundingClientRect().top ），浏览器会无视 <code>loading="lazy"，立即发起请求
如何用 IntersectionObserver 手动控制逐张加载时机
当需要兼容 Safari 15.4 以下、或想提前 100–200px 加载（避免快速滚动时白屏），就得用 JS 主动接管。关键不是“监听 scroll”，而是用 IntersectionObserver 做精准判定：
- 真实地址必须存在
data-src，src设为空白图（如data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==）或低分辨率占位图 - 创建观察器时传入
{ rootMargin: "150px" }，让图片在距视口顶部还有 150px 时就开始加载 - 回调中只在
entry.isIntersecting === true时才赋值img.src = img.dataset.src，并立刻调用observer.unobserve(img) - 动态插入的图片（如 AJAX 渲染后追加），需在插入 DOM 后显式调用
observer.observe(img)，不能指望自动覆盖
srcset 和 sizes 必须和 loading="lazy" 共存
只加 loading="lazy" 不解决响应式问题：懒加载延迟可能错过浏览器对 sizes 的媒体查询计算时机，导致移动端仍拉取桌面尺寸大图。正确写法是三者同在：
<img src="photo.jpg"
srcset="photo-sm.jpg 480w, photo-md.jpg 768w, photo-lg.jpg 1200w"
sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"
loading="lazy"
style="max-width:90%" height="400"
alt="示例">
注意：src 是 fallback，必须保留；CDN 参数化 URL（如 photo.jpg?w=480）要与 srcset 中路径完全一致，否则 lazy 触发后可能加载错尺寸。
立即学习“前端免费学习笔记（深入）”；
哪些图绝对不该加 loading="lazy"
加错地方反而拖慢首屏、损害 SEO。判断标准只有一个：用户打开页面瞬间是否必须看到它。
- 首屏 Banner、Logo、商品主图、登录页验证码图 —— 应显式写
loading="eager"或不加该属性 - CSS
background-image——loading属性对其完全无效，必须用IntersectionObserver配合getComputedStyle或动态 class 切换 -
<picture></picture>内的<source></source>标签 —— 只有最外层<img alt="HTML怎么实现图片逐张加载_网页图片懒加载技巧【参考】" >支持loading，<source></source>上加了也白搭 - 通过
innerHTML或框架（React/Vue）插入且初始已在视口内的img—— 部分 Firefox 版本仍会懒加载，造成短暂白屏
真正难处理的是服务端渲染（SSR）场景：首屏图片若被 SSR 框架误标为 lazy，而 JS 尚未执行完，就可能触发延迟加载逻辑，导致关键图“闪现”后再加载。这种边界情况得靠构建时条件注入或运行时二次校验来兜底。
