loading="lazy"只对初始HTML中存在、不在首屏、具明确宽高且父容器无transform/overflow:hidden等干扰样式的图片生效；动态插入（如Vue v-for、React map）、错放于<source>、缺宽高或首屏图均导致退化为eager加载。
loading="lazy"只对静态![HTML模板与性能优化策略下的组件懒加载方案]()
和
模板里写了loading="lazy"却没效果，大概率是因为图片不在初始 HTML 中——Vue 的 v-for、React 的 map()、或 JS 拼接字符串后 innerHTML 插入的 <img>，浏览器一律视为“非初始元素”，原生懒加载直接跳过。它只监听 window 滚动 + IntersectionObserver，而动态插入的节点若已处于视口内，Firefox 可能短暂白屏，Chrome 则干脆忽略该属性。
常见误用场景：
- CMS 富文本字段渲染后追加的
<img>，模板虽写了loading="lazy"，但服务端输出时被过滤或未透出 -
<picture>套了<source>，却把loading="lazy"错写在<source>上——该属性只作用于最内层的<img src> - 父容器用了
overflow: hidden或transform，导致 IntersectionObserver 无法正确判定可视性
首屏图加 loading="lazy" 是负优化，preload 才是正解
banner、logo、商品主图这类首屏关键资源，加了 loading="lazy" 不会延迟加载，反而可能干扰 SSR 渲染流程或被旧爬虫误判为非关键内容。浏览器对首屏内 <img> 会直接忽略该属性，但部分 SSR 框架（如 Nuxt）在 hydration 阶段可能因属性存在而跳过预加载逻辑。
正确做法是删掉 loading="lazy"，改用 <link rel="preload"> 显式声明：
立即学习“前端免费学习笔记（深入）”；
-
href必须和对应<img>的src完全一致（含查询参数），否则算两个资源，重复下载 - 必须带
as="image"，否则浏览器当普通脚本/样式处理，不提升优先级 - 不要给已加
loading="lazy"的图再preload——冲突触发重请求
srcset + sizes 不配齐，loading="lazy" 就是摆设
只写 srcset 不写 sizes，浏览器根本不知道这张图在页面里占多宽，懒加载触发时只能按设备 DPR 瞎猜，移动端很可能拉取 2x 大图。更糟的是，sizes 值写错（比如写成 "100vw" 但实际只占 300px），会导致资源错配且无法回退。
必须同时满足：
-
sizes反映真实占位宽度，响应式可写"(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" -
srcset中的w描述符（如800w）必须等于原图真实像素宽 -
<img>必须有width/height属性或 CSS 尺寸（aspect-ratio在 iOS Safari 15.4 前不兼容） - CDN 参数化 URL（如
photo.jpg?w=480）要确保和srcset中路径一致
需要控制组件/区块加载？IntersectionObserver 是唯一靠谱路径
HTML 本身不支持“组件级懒加载”，loading="lazy" 仅限 <img> 和 <iframe>。想实现广告位、评论区、长列表项的按需加载，必须用 IntersectionObserver 手动接管。
关键避坑点：
- 必须检查
img.complete，否则缓存中已加载完成的图会被重复赋值src，触发重请求 -
rootMargin别设太小（如"0px"），快速滚动时用户看到空白；也别太大（如"500px"），提前加载浪费带宽 - 动态插入的元素（如 AJAX 返回后
appendChild）需显式调用observer.observe()，不能只 observe 一次父容器 - 加载完成后务必调用
observer.unobserve(img)，否则持续监听已加载节点，内存泄漏风险
真正麻烦的不是怎么写，而是尺寸、时机、缓存状态这三者的耦合——漏掉任意一环，懒加载就变成卡顿源。
