grid-template-rows: masonry是唯一真正原生的瀑布流方案，需chrome 132+/firefox 130+支持，必须配合显式grid-template-columns且禁用手动定位，safari 18仍未支持，须用js特性检测加降级。
能，但仅限 Chrome 132+ 和部分新版 Firefox/Edge；Safari 和旧版浏览器仍需 JS 回退。
grid-template-rows: masonry 是唯一真正原生的方案
它不是“模拟”，而是浏览器渲染引擎内置的调度逻辑：自动识别列高、按“最短列优先”插入新项，不依赖 order、grid-row-end 或 DOM 移动。行为与 JavaScript 实现的 Masonry 库一致，只是交由底层处理。
- 必须配合
grid-template-columns使用，不能只设grid-auto-flow: column - 列方向默认是“行优先”（即先填满第一行再换第二行），但
masonry模式下是“列优先”——这才是瀑布流本质 -
gap正常生效，break-inside: avoid可防止卡片被截断，语义和可访问性都优于 JS 方案 - 不支持
grid-auto-rows，行轨道完全由内容驱动；也不能和grid-row-start/end混用，否则降级为普通 grid
grid-auto-flow: column + 固定行高是常见误用
很多人以为只要加 grid-auto-flow: column 就算瀑布流，其实只是列序排列，所有列仍会被拉齐到同一高度——因为 Grid 的行高是全局统一计算的，没有“每列独立累积高度”的能力。
- 设
grid-auto-rows: 1px后靠grid-row-end: span N手动撑高，本质是用 JS 算出 N，再写进样式；这不是原生瀑布流，只是用 Grid 做容器骨架 -
grid-auto-flow: dense只解决空隙填充，不解决列高异步增长问题；它无法让第 5 个元素跳过前两列直接插进第三列底部 - 响应式列数变化时，旧的
span值立刻失效，必须重新计算，容易造成布局抖动或错位
兼容性落地必须做渐进增强
Chrome 132 默认开启 masonry，Firefox 130+ 也已稳定支持，但 Safari 18 仍未跟进，大量安卓 WebView 仍卡在 Chromium 119 之前版本。
- 不要用
@supports (grid-template-rows: masonry)做唯一判断——某些旧版 Chrome 会假阳性返回 true，但实际不工作 - 推荐用 JS 特性检测：
const supportsMasonry = CSS.supports('grid-template-rows', 'masonry');，再结合 UA 判断 WebView 版本 - 降级方案别硬切 column-count：它对 hover 动画、拖拽、焦点管理都不友好；更稳妥的是用 Grid + JS 动态分配
order，复用同一套 DOM 结构 - 图片加载延迟会导致 JS 首次计算高度不准，务必监听
img.onload或用ResizeObserver二次校准
真正麻烦的不是写法，而是“高度不可知”——字体加载、图片异步、第三方组件嵌套都会让初始高度失真。哪怕 masonry 原生支持了，服务端渲染（SSR）首屏仍可能错乱，这点很容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
