根本原因是grid无法预知图片加载后尺寸，按0高度分配导致重排；应使用aspect-ratio预留空间，配合width: 100%和height: auto确保不拉伸，兼容性不足时用padding-top伪元素fallback。

纯 CSS 瀑布流中图片失比例、拉伸或塌陷，根本原因不是没写 width: 100%，而是 grid 没法预知图片加载后的实际尺寸——它按 0 高度分配空间，等图一进来就撑开，布局重排。

为什么 img { max-width: 100%; height: auto; } 在瀑布流里经常失效

这不是样式写错了，而是它在 grid 容器里被“架空”了：

• grid 子项默认按内容高度计算行高，height: auto 在图片未加载时返回 0，grid 就给它分配极小甚至为 0 的行高
• 后续图片加载后突然撑高，导致列间错位、留白、滚动跳变
• 某些浏览器（如旧版 Safari）对 height: auto 在 grid 中的解析不一致，尤其当父容器无明确高度时
• 若外层用了 object-fit: cover 却没给容器设固定宽高，该属性直接不生效

用 aspect-ratio 预留空间，比 JS 算尺寸更稳

现代浏览器（Chrome 88+、Firefox 89+、Safari 15.4+）原生支持 aspect-ratio，它是解决塌陷最轻量、最可靠的方式：

• 给 直接加 aspect-ratio: 4/3（或你图片的真实比例），浏览器会按该比例预留空间，无需等待图片加载
• 配合 width: 100% 和 height: auto，图片加载后自然填满且不拉伸
• 若图片比例不统一，可在 HTML 中按需设置不同值：、
• 兼容性兜底：对不支持 aspect-ratio 的老浏览器（如 IE 或 Safari

兼容老浏览器：用 padding-top + position: absolute 模拟比例

这个方案不依赖新特性，但必须严格遵循结构和定位逻辑，否则照样塌陷：

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 把 包进一个容器（如
  ）
• 给容器设 padding-top: 75%（对应 4:3）、position: relative，并禁用 height
• 给 设 position: absolute; top: 0; left: 0; width: 100%; height: 100%; object-fit: cover;
• 关键点：不能给容器设 height，也不能让 img 外溢（所以必须 overflow: hidden）
• 注意：如果用了 srcset 或懒加载，确保 padding-top 值与最终渲染图比例一致，否则仍会错位

Grid 布局里别碰这些坑

即使你写了正确的图片样式，grid 层级的配置错误也会让所有努力白费：

• 漏掉 grid-auto-flow: dense：短图无法回填高图留下的空隙，出现明显纵向断层
• 误用 auto-fill 而非 auto-fit：在响应式场景下，auto-fill 会保留空列占位，导致小屏上列数异常
• 在 grid 容器上设 overflow: hidden：当某张图跨多行时，可能被截断（尤其用了 grid-row-end: span 2）
• 全局重置了 img { display: inline } 或影响基线的样式：grid 行高判断失准，尤其 Firefox 下容易错位
• 用 minmax(300px, 1fr) 却没控制最小列宽：小屏下强行维持 300px，导致单列溢出或横向滚动

真正难的不是写几行 CSS，而是在图片异步加载、比例不一、浏览器能力参差的现实条件下，让 grid “信得过”那个还没出现的高度。所以别赌图片加载时机，从一开始就用 aspect-ratio 或 padding-top 把空间钉死——这是所有稳定瀑布流的起点。