loading="lazy"仅对初始HTML中存在且不在首屏的<img>生效；动态插入、<source>、overflow: hidden/transform父容器等场景均失效。
loading="lazy"为什么写了却没效果
浏览器只对初始 HTML 中已存在、且不在首屏视口内的 <img> 应用懒加载。动态插入的图片（比如 Vue 的 v-for、React 的 map() 渲染）、父容器带 overflow: hidden 或 transform、<source> 标签上加 loading="lazy"，全都不生效。
常见静默失效场景：
-
<picture>里给<source>写了loading="lazy"—— 该属性只认<img>，<source>直接忽略 - 用
position: absolute; top: -9999px占位 —— 浏览器判定“已渲染但不可见”，跳过懒加载逻辑 - 只写
srcset没配sizes—— 浏览器无法推算图的实际占位宽度，可能拉错尺寸，甚至放弃懒加载判断 - 首屏关键图（如 banner、logo）误加
loading="lazy"—— 可能被延迟，导致白屏或 LCP 崩溃
srcset + sizes 怎么配才不拉错图
浏览器选图逻辑很机械：先按 sizes 算出图在页面中「实际渲染宽度」，再从 srcset 里挑最接近且不小于该宽度的源。配错 sizes，就等于告诉浏览器一个假尺寸。
必须对齐真实 CSS 布局：
立即学习“前端免费学习笔记（深入）”；
- 如果 .hero-img 在桌面端固定宽 720px，
sizes就得写"(max-width: 767px) 100vw, 720px"，不能写成"100vw" - 有 padding 的容器要手动减：视口 390px、左右各 20px，有效宽度 ≈350px，
sizes得是"(max-width: 767px) 350px, 720px" -
srcset中的w描述符必须等于原图真实像素宽（如banner-1200w.jpg必须真为 1200px 宽），否则切换会错乱 - 单位别混用：
sizes里不能同时出现vw和px，更不能塞rem
picture 元素里 WebP/AVIF 回退为什么总失败
<picture> 是顺序匹配：浏览器从上到下解析 <source>，遇到第一个 media 匹配且 type 受支持的就停，后面全跳过。Safari 13 不支持 WebP，如果你把 <source type="image/jpeg"> 放前面，它永远卡在这条，根本看不到下面的 WebP。
正确顺序和写法：
- 现代格式必须前置：
<source type="image/avif">→<source type="image/webp">→<source type="image/jpeg"> - 同一
<source>内别混用w和x描述符，部分 Android 浏览器会整条忽略 - 只保留真实触发的断点，比如 CSS 里没写
@media (min-width: 1440px)，那<source media="(min-width: 1440px)">就是冗余，纯增体积 -
<img>作为兜底必须存在，且src要指向兼容性最强的格式（如 JPEG）
自定义懒加载用 IntersectionObserver 容易卡顿的原因
自己写懒加载不是为了炫技，而是要解决原生 loading="lazy" 不支持的场景（比如提前 200px 加载、淡入动画、错误回退）。但一不留神就会拖慢滚动体验。
核心守则只有两条：
- 初始
<img src="placeholder.svg" width="300" height="200">—— 宽高必须设，否则加载时布局抖动，LCP 直接恶化 - Observer 回调里只干两件事：
el.src = el.dataset.src和observer.unobserve(el)；别在里面塞 AJAX、DOM 操作、重绘逻辑 - 监听前先过滤已在视口内的元素：
document.querySelectorAll('img[data-src]:not(.loaded)')，避免刚进页面就批量触发 - 别忘了预加载首屏关键图：
<link rel="preload" as="image" href="hero.jpg">，和懒加载不是互斥，而是分工
真正难的从来不是代码怎么写，而是搞清每张图到底该「什么时候加载」和「加载哪一张」——这两个问题没理清，再多属性、再花哨的 Observer 都只是往错误方向加速。
