loading="lazy" 必须配合 width/height 或 aspect-ratio 使用，否则浏览器可能跳过懒加载、引发 cls 或加载错误；需与 srcset/sizes 共存以确保响应式正确；首屏图片应禁用 lazy；ssr 中需谨慎判断是否添加。
loading="lazy" 必须和 width/height 或 aspect-ratio 一起用
只写 loading="lazy" 但没设尺寸，浏览器大概率会跳过懒加载逻辑——Chrome 和 Safari 可能直接 eager 加载，Firefox 则可能因布局不确定而延迟触发或报错。更严重的是，图片加载后突然撑开页面，引发 CLS（累计布局偏移），影响 SEO 和用户点击意愿。
-
width和height属性必须存在，值要与实际宽高比一致（例如<img src="a.jpg" style="max-width:90%" style="max-width:90%">） - 用 CSS 设置也行（
img { width: 100%; height: auto; }），但父容器必须有明确宽度，否则无法推导占位空间 -
aspect-ratio: 4/3是现代替代方案，但 iOS Safari 15.4 之前不支持，老设备 fallback 还得靠传统宽高
srcset + sizes 和 loading="lazy" 不是“可选搭配”，而是必须共存
只加 loading="lazy" 不解决响应式问题：懒加载触发时若视口已滚动或 JS 尚未就绪，浏览器可能错过 sizes 的媒体查询判断时机，最终拉取远超需要的大图（比如移动端加载 1200w 版本）。
- 正确写法是三者同级：
<img src="fallback.jpg" srcset="sm.jpg 480w, md.jpg 768w, lg.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" loading="lazy"> -
src必须保留，作为 Safari 15.4 之前或降级场景的 fallback - CDN 参数化 URL（如
photo.jpg?w=480）要和srcset中路径完全一致，否则 lazy 触发后可能加载错尺寸
哪些 img 标签加了 loading="lazy" 反而坏事
不是所有 <img> 都适合懒加载。加错地方等于主动拖慢首屏、增加白屏风险、干扰爬虫抓取。
- 首屏内图片（Banner、Logo、商品主图、登录页验证码）——显式写
loading="eager"或干脆不写 -
<picture><source></source></picture>里的<source></source>标签不支持loading，只有最内层<img>生效 - CSS
background-image完全无视loading="lazy"，这类图必须用IntersectionObserver手动控制 - 通过 React/Vue 动态插入的
<img>，若插入时已在视口内，旧版 Firefox 可能仍懒加载，导致短暂白屏
服务端渲染（SSR）中 loading="lazy" 的坑
SSR 页面里，loading="lazy" 会直接输出到 HTML，看似省事，但容易在两个环节出问题：JS 加载前的首屏误判，以及 hydration 后的状态不一致。
- 若 SSR 框架（如 Next.js/Nuxt）默认对所有图片加
loading="lazy"，首屏图可能被当成非关键资源跳过预加载 - 某些 SSR 渲染流程中，爬虫或静态生成器可能忽略
loading属性，导致关键图未被抓取 - React/Vue hydration 后，若组件重新渲染并重置
src，可能触发二次加载或丢失 lazy 状态 - 稳妥做法：SSR 阶段只对明确非首屏的
<img>输出loading="lazy"，首屏图用loading="eager"显式声明
loading="lazy"，而是判断哪张图该加、在哪加、加了之后是否真被浏览器执行——它依赖尺寸、滚动上下文、渲染阶段、甚至 CDN 路径一致性。漏掉任意一环，都可能让“优化”变成负优化。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
