loading="lazy"失效因浏览器预判、父容器干扰或属性缺失；需配width/height防CLS、decoding="async"防卡顿、srcset/sizes选合适资源，并注意框架透传与兼容性兜底。
loading="lazy"加了但图片还是首屏全加载，为什么？
不是所有写了 loading="lazy" 的图片都会延迟加载——浏览器会根据“是否可能很快进入视口”做预判，尤其在 4G/光纤等快网络下，它可能提前触发加载（Chrome 默认提前约 1250px）。更关键的是：如果图片离首屏太近（比如第二屏顶部），或父容器用了 transform、visibility: hidden，浏览器可能直接跳过懒加载逻辑，静默回退到 eager。
常见失效场景包括：
-
<img>缺少width和height属性，Safari 15.4+ 会拒绝懒加载 - 图片被包裹在
<picture>中，却只给<source>加loading="lazy"（必须加在最外层<img>上） - 父级设置了
overflow: hidden或transform: translateZ(0)，干扰 Intersection Observer 检测 - 页面在 iframe 内嵌环境中运行，多数浏览器完全忽略该属性
哪些图片必须配 width/height + decoding="async" 才安全？
单写 loading="lazy" 是半残废状态。没有尺寸，浏览器无法预留空间，加载时重排会引发 CLS（布局偏移）；不解码异步化，大图解码仍可能卡主线程。
必须组合使用的三项是：
立即学习“前端免费学习笔记（深入）”；
-
width和height：建议用 HTML 属性而非 CSS，避免 SSR 渲染时无占位 -
decoding="async"：对 >1MB 的 PNG/JPEG 尤其有效，但注意它和loading="lazy"组合收益有限，优先优化格式（WebP/AVIF）和 CDN 缓存 -
srcset+sizes：确保懒加载触发时，浏览器能基于当前视口宽度选最合适的资源，否则可能拉取远超需要的大图
正确写法示例：
<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 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
Vue/React 动态渲染时，loading="lazy" 为什么没生效？
框架默认会过滤非标准 HTML 属性。Vue 2 不识别 loading，React 16+ 支持但要求小写命名，且不能驼峰（loadingLazy 无效）。
实操要点：
- Vue 2：必须用
v-bind:{"loading":"lazy"}强制透传，否则编译后消失 - Vue 3 / React：可直接写
loading="lazy"，但需确认服务端渲染（SSR）时模板未被 CMS 富文本过滤器删掉该属性 - 动态插入的
<img>：若插入时已在视口内，旧版 Firefox 可能仍懒加载，导致闪白；建议插入后手动检查并立即触发加载
兼容性兜底不能只靠“不支持就自动降级”
原生 loading="lazy" 在 Safari 15.0–15.3 存在滚动抖动 bug，iOS 微信 X5 内核、企业微信内置浏览器完全不识别，IE 和 Edge ≤18 直接忽略——这些情况不会报错，但也不加载，用户看到的就是空白或 fallback 占位图。
真正可用的兜底策略是：
- 用
IntersectionObserver手动监听，配合data-src+src切换，可控性强、可设rootMargin提前加载（如"100px"） - 不要只检测
"loading" in HTMLImageElement.prototype，有些 polyfill（如 lazysizes）会 patch 这个判断，但实际行为仍受限于IntersectionObserver支持 - 对背景图、伪元素、
<canvas>贴图等非<img src>场景，JS 方案是唯一选择
复杂点在于：原生 lazy 没有加载失败回调，onerror 仍得自己监听；也没有 WebP fallback 自动降级能力，<picture> 里每个 <source> 都得单独处理——这些细节，加了 loading="lazy" 也不会自动帮你补上。
