chrome 116+ 支持 grid-template-rows: masonry 实现真瀑布流，但 safari 和 firefox 完全不识别该值，会静默忽略并退化为单列布局，且 @supports 检测始终返回 false，fallback 需用 @supports not 语法配合 column-count 或 js 方案。
Chrome 116+ 可用 grid-template-rows: masonry 实现真瀑布流，但 Safari、Firefox 完全不支持，且必须满足全部硬性条件，否则静默退化为单列布局。
为什么 grid-template-rows: masonry 在非 Chrome 中无效
这不是兼容性“差”的问题，而是语法未被解析：Safari 和 Firefox 遇到 grid-template-rows: masonry 会直接忽略整条声明，回退到默认的 grid-auto-flow: row 行为——结果是所有子项从上到下堆成一列，视觉上完全错乱。
更关键的是：@supports (grid-template-rows: masonry) 在这些浏览器中永远返回 false，因为它们压根不识别该值，无法用于 JS 或 CSS 检测切换。
可行的 fallback 方式只有：@supports not (grid-template-rows: masonry) 主动匹配旧环境，然后降级为 column-count 或 JS 方案。
grid-template-rows: masonry 的生效前提
它不是开关，而是一套严格契约。漏掉任一条件，布局就失效（不是报错，是静默变单列）：
-
grid-template-columns必须显式写出，不能是auto-fill或auto-fit—— 所以响应式列数得靠媒体查询切，例如：@media (min-width: 768px) { grid-template-columns: repeat(3, 1fr); } - 子项不能有任何
grid-row-start、grid-row-end、grid-column-start等显式定位属性 - 子项不能跨行（
grid-row: span 2）或跨列（grid-column: span 2） - 容器必须有明确的块方向尺寸，如
height或max-height；仅设min-height不够 - 子项内部不能有
contain: layout、float、position: absolute等触发新 BFC 的属性
移动端适配与列数切换的陷阱
很多人想用 minmax(280px, 1fr) 让列数自动响应，但这和 masonry 冲突。必须放弃 auto-fill/auto-fit，改用断点硬编码列数：
- 手机屏（≤480px）：
grid-template-columns: 1fr - 平板（481–768px）：
grid-template-columns: repeat(2, 1fr) - 桌面（≥769px）：
grid-template-columns: repeat(3, 1fr)
列数变化时，height 建议同步调整（比如从 70vh 改为 90vh），否则小屏下容易因高度不足导致内容截断或留白异常。另外，列数切换瞬间可能出现闪动——这是 masonry 引擎重排的固有延迟，无法靠 CSS 规避，只能靠 JS 节流或过渡动画弱化感知。
真正难的不是写对这行 CSS
是判断你是否真的需要 masonry：如果你的页面要支持 Safari 用户、需加载大量图片、内容高度不可预估、或要配合懒加载/虚拟滚动，那它大概率会在某次 resize 或图片 onload 后崩一次布局。此时，一个稳定的手动列高 map + appendChild 的 JS 方案，反而比调试十种 CSS fallback 更省时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
