纯 css grid 无法实现真正可用的 pinterest 瀑布流，因布局模型不支持列高动态平衡；grid-template-rows: masonry 仅在 chrome 117+/firefox 119+/safari 17.4+ 支持，且需显式定义 grid-template-columns、禁用手动定位、卡片为直接子元素，并配合 aspect-ratio 或 padding-top 防错位；grid-auto-flow: row + minmax() 仅生成等高卡片墙，非真实瀑布流；js 动态分配至最短列才是可靠方案，需监听图片加载与 resizeobserver 更新高度；column-fill: balance 在 grid 中无效。
纯 CSS Grid 无法实现真正可用的 Pinterest 瀑布流——这不是写法问题，而是布局模型本身不支持列高动态平衡。
grid-template-rows: masonry 能用吗？
能，但有硬性前提：Chrome 117+、Firefox 119+、Safari 17.4+ 才支持 grid-template-rows: masonry。它不是“加一行就生效”的开关，必须同时满足：
-
grid-template-columns必须显式定义，例如repeat(3, 1fr)或300px 300px 300px；auto-fill和auto-fit会直接禁用 Masonry 行为 - 完全禁用任何手动定位：不能出现
grid-row-start、grid-column等声明，否则退化为普通 Grid - 所有卡片必须是容器的直接子元素；嵌套
display: flex或display: grid子容器会干扰列高测量 - 图片加载异步时初始渲染常错位——需配合
aspect-ratio占位，或 fallback 到padding-top百分比方案
为什么 grid-auto-flow: row + minmax() 只是假瀑布流
常见错误写法：grid-template-columns: repeat(auto-fill, minmax(250px, 1fr))); grid-auto-flow: row;。结果只是等高卡片墙，不是错落的瀑布流：
- 每行高度由该行最高项决定，后续项不会“下沉”到更短列底部
-
grid-auto-rows: min-content对列内高度无影响，它控制的是“行轨道”，不是“列堆叠高度” - 视觉上仍是行列对齐模型，无法模拟 Pinterest 的动态落点逻辑
JS 动态分配卡片到最短列才是可靠方案
放弃让 Grid 直接托管所有卡片，改用 Grid 控制列容器 + JS 管理卡片插入逻辑：
- 父容器设
display: grid，用grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))自动分列 - 每列是一个
<div class="column">，Grid 只负责宽度和间距，不干预内部内容流 <li>每次插入新卡片前，遍历所有 <code>.column的offsetHeight，找到最小值对应列再appendChild - 必须监听图片加载：
img.addEventListener('load', updateColumnHeights)，否则高度塌陷会连锁崩坏 - 用
ResizeObserver替代window.resize，响应字体加载、缩放、侧边栏折叠等内部尺寸变化 - 写了也毫无反应，子项仍按 DOM 顺序从左到右排列
- 它和 Grid 完全无关，混淆使用只会浪费调试时间
别碰 column-fill: balance
column-fill: balance 是多列布局（columns）的属性，在 display: grid 下压根不进计算逻辑：
真正容易被忽略的是：Masonry 模式下 gap 在 Masonry 轴向上（即列内垂直方向）不生效，列间 gap 正常，但卡片间距得靠 margin-bottom 模拟；而 JS 方案里，图片加载完成前的 offsetHeight 常为 0，必须用 getBoundingClientRect() 或延迟重算兜底。
