必须在html中声明img的width和height属性，以向浏览器提供固有宽高比线索，配合css的aspect-ratio或max-width:100%才能提前预留空间，否则加载时仍会触发重排抖动。
为什么只写 width: 100% 或 aspect-ratio 还是会抖
因为浏览器在 HTML 解析阶段看不到尺寸线索，就按 0×0 占位；等图片加载完、解码完、CSS 计算完，才重排一次——下方文字/按钮全被往下顶。哪怕用了 aspect-ratio: 16/9，Safari 15.4 之前、Firefox 89 之前都不支持，fallback 失效时照样抖。
关键不是“怎么让图片好看”，而是“怎么让浏览器提前知道它该占多大地方”。aspect-ratio 是 CSS 层的补救，但源头必须在 HTML 层声明 width 和 height 属性（不是 style）。
<img> 的 width 和 height 属性到底该怎么写
它们的作用不是固定像素宽高，而是告诉浏览器“这张图的固有宽高比是多少”。浏览器用这个比例 + CSS 的 max-width: 100% 自动算出响应式高度，从而预留准确空间。
- 必须写成 HTML 属性：
<img src="x.jpg" style="max-width:90%" style="max-width:90%">，不是style="width: 800px; height: 600px" - 数值不需精确匹配最终显示尺寸，但比例要准（比如 800×600、4×3、16×9 都行）
- 搭配 CSS 使用才真正响应：
img { max-width: 100%; height: auto; } - 如果原始图是 1200×800，但你在移动端只打算显示 300px 宽，仍应写
width="1200" height="800"，而非width="300" height="200"—— 后者会破坏 intrinsic ratio，导致 Safari 下 fallback 失效
Tailwind 用户特别注意：w-full h-64 不等于防抖
Tailwind 的 h-64 是固定高度类，和图片本身比例无关。若图片是竖构图（比如 400×800），放进 h-64 w-full 容器后触发 object-cover，实际渲染区域可能被裁切，但容器高度没变——看似稳了，实则隐藏了两个问题：
- 图片加载前，浏览器仍按 0×0 占位（因为你没写 HTML
width/height），CLS 已计入 - 不同断点下，
h-64在小屏可能太矮、大屏又太高，文字层或按钮位置浮动，反而放大偏移风险 - 正确做法是：保留
width/height属性 + Tailwind 的aspect-[16/9]（现代浏览器）或手动加min-h-48 sm:min-h-64 lg:min-h-80，且每个值都要对应该断点下内容可读的最小安全高度
动态插入图片时，DOM 里不能留空
React/Vue hydration、广告脚本注入、评论模块懒加载……只要 JS 往 DOM 里塞新 <img>，而父容器初始是空的，就会立刻引发 CLS。Lighthouse 常把这类问题归到 ，其实根子在 JS 插入点。
- 不要等图片加载完再挂节点，先挂一个带
min-height的骨架容器：<div class="min-h-48 bg-gray-100"></div> - 第三方 iframe（如广告）必须包裹在
aspect-ratio容器里，或用 padding-top hack 兼容旧版 - 用
replaceWith()替换骨架，别用innerHTML =—— 后者会清空整个容器再重绘，容易触发两次 layout - SSR/SSG 输出的 HTML 源码里，就得包含带
width/height的<img>或至少是占位容器，hydration 才不会“突然长大”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
