loading="lazy" 能用但非万能，仅对首屏外、有明确宽高、标准文档流中的 <img> 和 <iframe> 有效；首屏图、无尺寸、父容器含 transform 或 overflow: hidden 时会静默退化为 eager。
loading="lazy" 能用，但不是加了就生效——它只对明确在首屏外、有可推断尺寸、且处于标准文档流中的 <img> 和 <iframe> 有效。首屏图、无宽高、父容器用了 transform 或 overflow: hidden，都会让它静默退化为 eager。
哪些图片加了 loading="lazy" 也白搭
浏览器会直接跳过懒加载逻辑，而不是报错或警告，所以你看到“全图都加载了”，往往是因为：
-
<img>没写width和height属性（Safari 15.4+ 会直接拒绝懒加载） - 图片离首屏太近（比如第二屏顶部），Chrome 默认提前约 1250px 预取，它认为“马上要进来了”，就提前加载
- 父级用了
transform: translateZ(0)、opacity: 0或visibility: hidden，破坏 Intersection Observer 的检测基础 - 图片在
<iframe>内，或页面被嵌在第三方平台（如微信 WebView、某些 CMS 预览页），多数浏览器完全忽略该属性 -
<picture>包裹时，把loading="lazy"错加在<source>上（必须加在最外层<img>标签）
loading="lazy" 必须搭配的三项硬指标
单写一个属性是半残废状态，容易引发 CLS（布局偏移）或主线程卡顿：
-
width和height：建议用 HTML 属性而非 CSS，避免 SSR 渲染时无占位；若用 CSS，需确保能被浏览器在解析阶段推断（如aspect-ratio: 4/3在 Safari 15.4+ 可接受） -
decoding="async"：对 >1MB 的 PNG/JPEG 尤其关键，让解码走后台线程，否则大图仍可能阻塞渲染 -
srcset+sizes：懒加载触发时，浏览器靠这个选资源；不配sizes，旧版 Safari 可能降级为 eager 加载
正确示例：
<img src="cat-small.jpg" srcset="cat-small.jpg 480w, cat-large.jpg 1024w" sizes="(max-width: 480px) 100vw, 50vw" width="800" height="600" loading="lazy" decoding="async" alt="cat">
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
Vue/React 里 loading="lazy" 不生效？不是框架问题，是写法错了
框架默认过滤非标准属性，但支持方式不同：
- Vue 2：不识别
loading，得用v-bind:loading="'lazy'"或写成:attrs="{ loading: 'lazy' }" - React 16+：支持小写
loading="lazy"，但不能驼峰（loadingLazy无效），也不能通过data-前缀透传 - SSR 场景下，如果客户端 JS 后续又覆盖了
src（比如从data-src赋值），浏览器只认最终生效的src，原生懒加载会被绕过
什么时候该放弃 loading="lazy"，改用 IntersectionObserver
原生方案轻量，但控制粒度太粗。遇到以下情况，就得上 JS：
- 需要提前 200px 加载（
rootMargin: "200px"），而不是等浏览器默认的 ~1250px - 要监听加载失败并 fallback 到占位图或错误提示（
onerror回调无法和懒加载时机联动） - 资源不是
<img>，比如背景图、伪元素、<video>、卡片容器模块 - 页面含大量动态插入的图片（如无限滚动列表），原生属性在插入时已脱离懒加载上下文
注意：别混用。已加 loading="lazy" 的 <img>，再用 JS 监听并手动赋 src，大概率触发重复请求或竞态。
真正容易被忽略的是：loading="lazy" 是浏览器调度的“尽力而为”行为，它不保证加载顺序、不提供重试、不响应网络状态变化。如果你的业务对加载确定性有要求（比如电商详情页的主图必须在用户滑到前完成），那就别依赖它——显式设 loading="eager"，或用 IntersectionObserver 自己控节奏。
