loading="lazy"加了没效果，主因是img缺宽高属性、父容器用transform/overflow:hidden干扰检测、或图片已在首屏内；需补width/height、验证network请求时机，并首屏图改用preload+decoding="async"。
图片加载延迟不是“等它自己快起来”的问题，而是资源调度失控的表现——多数情况根本不用等，只要改掉几个关键属性、补上两行代码就能解决。
loading="lazy" 为什么加了却没效果
加了 loading="lazy" 但图片还是全量加载，常见原因有三个：
-
img没设width和height（或 CSS 中的aspect-ratio），Safari 和部分 Chrome 版本会直接降级为eager - 父容器用了
transform+overflow: hidden，导致浏览器误判滚动根节点，IntersectionObserver 和原生 lazy 都失效 - 图片在 HTML 中已处于视口内（比如首屏 banner），浏览器认为“已经需要”，自动跳过懒加载逻辑
验证是否生效：打开 DevTools → Elements → 选中 img，看 Network 面板里它的请求是否在滚动后才发出。没发出，说明被提前加载；发得太早，说明没进懒加载队列。
首屏图片加载卡顿的硬解法
首屏大图（如 hero banner、登录头像）绝不能依赖 loading="lazy"，必须主动抢占带宽：
- 在
里加<link rel="preload" as="image" href="hero.avif">，href必须是最终要显示的 URL，不能是占位符 - 搭配
decoding="async"属性：<img src="hero.avif" decoding="async" style="max-width:90%" style="max-width:90%">，让浏览器用后台线程解码，不阻塞主线程渲染 - 避免用
background-image替代<img>做内容图——它绕过所有 loading 控制，且 SEO 不识别
data-src + IntersectionObserver 手动控制时的致命细节
手动实现比原生更灵活，但也更容易出错。核心就三点：
- 初始化时先过滤掉已在视口内的元素：
const inView = img.getBoundingClientRect().top ，否则刚进页面就批量触发，失去“懒”的意义 - 回调里只做两件事：
img.src = img.dataset.src;然后立刻observer.unobserve(img);——别在里面塞fetch、DOM 插入、动画类操作 - 加载失败必须兜底：
img.onerror = () => { img.src = 'fallback.jpg'; };，否则某些 WebView（如旧版微信内置浏览器）加载.webp失败会静默留白
rootMargin 别写死 "0px"，至少设 "200px" 提前触发，否则快速滚动时会看到明显空白。
srcset 和 sizes 混用 lazy 时的隐性陷阱
loading="lazy" 不改变 srcset 的资源选择逻辑，但它推迟了浏览器解析和发起请求的时机——这会导致一个严重后果：如果图片还没开始加载，用户就快速滚动过去，浏览器可能来不及根据 sizes 计算出合适的宽度描述符，结果拉了张 2MB 的桌面图来渲染小屏卡片。
安全做法是：
- 把
sizes写明确：sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" -
srcset中每个源的宽度描述符（如400w）必须和原图真实像素宽一致，否则切换错乱 - 对关键响应式区域（如商品列表），宁可用
<picture></picture>+<source></source>显式控制格式和尺寸，loading="lazy"只加在外层<img>上
真正容易被忽略的点是：懒加载不是开关，而是一次资源调度决策。你得清楚每张图“什么时候该出现”“出现时该是什么尺寸”“出不来时该怎么办”，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
