loading="lazy"必须搭配width/height或CSS尺寸、srcset+sizes，且禁用于首屏图，否则会拖慢首屏、引发CLS或白屏；它不支持<picture>内<source>和background-image。
原生 loading="lazy" 是最省事的方案，但它不是加了就完事——不配好 srcset、不设 width/height、乱用在首屏图上，反而会拖慢首屏、触发布局抖动（CLS），甚至让图片白屏。
loading="lazy" 必须搭配 width/height 或 CSS 尺寸
浏览器需要预知图片占位空间，否则无法安全延迟加载。没尺寸时，Chrome 和 Safari 可能跳过懒加载逻辑，直接请求；更糟的是，图片加载后突然撑开页面，造成 CLS（累计布局偏移），影响 SEO 和用户体验。
-
width和height属性必须存在，且值要合理（比如<img src="a.jpg" width="600" height="400">） - 用 CSS 设置尺寸也行（
img { width: 100%; height: auto; }），但需确保父容器有明确宽高，否则仍可能误判 - 响应式场景下，
aspect-ratio: 4/3是现代替代方案，但 iOS Safari 15.4 之前不支持，兼容性不如传统宽高属性
srcset + sizes 和 loading="lazy" 要一起写
只加 loading="lazy" 不解决响应式问题：如果图片在移动端本该加载小图，但懒加载触发时视口宽度已变化，而 sizes 没参与计算，浏览器可能拉取大图。
- 正确写法是三者共存：
<img src="photo.jpg" srcset="photo-sm.jpg 480w, photo-md.jpg 768w, photo-lg.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" loading="lazy" alt=""> -
src必须保留，作为所有浏览器的 fallback（尤其 Safari 15.4 之前忽略loading，但至少还能按src加载） - CDN 或图片服务若对 URL 做参数化处理（如
image.jpg?w=480），要确认其与srcset中的路径一致，否则 lazy 触发后可能加载错尺寸资源
哪些 img 标签不该加 loading="lazy"
加了等于负优化。浏览器对“首屏内”图片会直接忽略 loading="lazy"，但部分旧版爬虫或 SSR 渲染流程中，它可能被当成非关键资源跳过抓取或延迟渲染。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 首屏 Banner、Logo、商品主图、登录页验证码图 —— 应显式写
loading="eager"或干脆不写 -
<picture>里的<source>标签不支持loading，只有最内层的<img>才认这个属性 - CSS
background-image完全不受控，loading="lazy"对它无效，这类图必须用IntersectionObserver手动控制 - 通过
innerHTML或框架（React/Vue）动态插入的<img>，若插入时已在视口内，部分 Firefox 版本仍会懒加载，导致短暂白屏
服务端渲染（SSR）中 loading="lazy" 的坑
SSR 输出的 HTML 里带 loading="lazy" 没问题，但容易忽略两点：一是首屏图被误标 lazy，二是构建工具自动 strip 掉未知属性。
- Next.js / Nuxt 等框架默认不会过滤
loading，但某些 HTML 压缩插件（如html-minifier-terser）若配置为ignoreCustomAttributes: []，会删掉loading—— 需显式加入白名单 - 若用
getServerSideProps渲染首屏图片，别在服务端逻辑里统一加loading="lazy"，应根据是否在首屏做判断（例如通过isAboveFold标记） - 微信内置浏览器（X5 内核）旧版本（如 Android 8.x 上的微信 8.0.22）会静默忽略该属性，且无 JS 回退，此时只能靠
IntersectionObserver补漏
真正难的不是加个属性，而是判断哪张图该懒、哪张不该懒，以及如何让 lazy 在 SSR、CDN、爬虫、老 WebView 之间保持行为一致。尺寸、srcset、服务端逻辑这三环缺一不可。
