grid-auto-rows: minmax(100px, auto) 不能实现瀑布流，它仅设定隐式行轨道默认尺寸，不支持跨行填空；真正需 grid-auto-flow: dense 配合 JS 动态计算 grid-row-end: span 值。
grid-auto-rows: minmax(100px, auto) 不能直接实现瀑布流
很多人看到 minmax(100px, auto) 就以为能自动撑开行高、适配内容高度，从而“原生支持瀑布流”。事实是：它只控制**隐式行轨道的默认尺寸**，并不触发跨行逻辑，也不会让元素自动跨越多行去填空。浏览器仍按顺序逐行放置元素，结果就是一列堆到底，完全不是瀑布流效果。
真正起作用的是 grid-auto-flow: dense + grid-row-end: span X 的组合。而 X 必须由 JS 动态计算——因为 CSS 无法读取元素真实高度。
-
grid-auto-rows: minmax(100px, auto)在瀑布流中唯一合理用途是设一个**固定基准单位**（如10px），方便后续用 JS 计算span值：比如元素高 157px →span 16 - 设成
minmax(100px, auto)反而会让每行“试图自适应”，破坏跨行控制精度，导致错位或留白 - 移动端 WebView 或旧版 Safari 中，
minmax()对grid-auto-rows的支持仍不稳定，建议始终用固定值如10px
海量数据下必须跳过 DOM 遍历，改用预计算高度
渲染上千个卡片时，如果每次插入都调用 getBoundingClientRect() 或 offsetHeight，主线程会卡死。这不是优化问题，是根本不可行。
正确做法是在数据层就准备好高度信息，不依赖渲染后测量：
立即学习“前端免费学习笔记（深入）”；
- 服务端或构建时生成每个 item 的预估高度（例如根据文字行数 × 行高 + 内边距 + 图片比例），存为
data.heightPx - 前端用这个值直接算
span：比如基础行高设为10px，则grid-row-end: span calc(var(--item-height) / 10) - 图片加载完成后再微调：监听
img.onload，仅对当前img所在卡片重新设置--item-height变量，避免全量重排 - 无限滚动场景下，新一批数据到来时，只更新新增项的变量，不触碰已有 DOM
grid-auto-flow: dense 是瀑布流“填缝”的开关，但有副作用
grid-auto-flow: dense 允许小元素回填前面大元素留下的空隙，这是瀑布流视觉连贯性的关键。但它会打乱 DOM 顺序对应的视觉顺序——比如第 5 个元素可能出现在第 2 列顶部。
这在语义化要求高的场景（如无障碍阅读、SEO）中是隐患：
- 若需保持可访问性，必须配合
aria-order或虚拟滚动 + 逻辑顺序映射 - 不要在
display: contents包裹的容器里用dense，部分 Safari 版本会忽略该声明 - 测试时重点检查键盘 Tab 顺序是否与视觉一致；若不一致，宁可放弃
dense，改用 JS 模拟填缝逻辑
CSS 变量传递 span 值比内联 style 更稳定
给每个 item 写 style="grid-row-end: span 16" 看似直接，但在小程序或某些 Webview 中，频繁 setData 或 innerHTML 更新会导致样式丢失或闪烁。
用 CSS 变量 + calc() 是更鲁棒的选择：
- 容器定义：
.grid { grid-auto-rows: 10px; grid-auto-flow: row dense; } - 子项写法：
.item { grid-row-end: span calc(var(--item-rows, 1)); } - WXML/JSX 中绑定：
<div class="item" style="--item-rows: {{Math.ceil(item.height / 10)}}"> <li>好处：变量更新不触发重排，只重绘；支持 transition（虽然瀑布流一般不用动效）；兼容小程序 2.10.0+ 和 Chrome 110+ 等主流环境</li> <p>最易被忽略的一点：基础行高单位（如 <code>10px）必须和 JS 计算时用的除数严格一致。差 1 都可能导致最后一行错位——这种 bug 往往只在特定屏幕宽度下复现，排查成本极高。
