# 瀑布流写成 Grid Lanes 了，兼容表这会儿还敢上生产吗？

**URL:** <https://www.shiqidu.com/t/topic/1897>\
**Category:** 开发调优\
**Tags:** 前端开发, CSS, 浏览器\
**Created:** [2026 年11 月 2 日 08:17 UTC](https://www.shiqidu.com/t/topic/1897 "2026-11-02T08:17:22Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年11 月 2 日 08:17 UTC](https://www.shiqidu.com/t/topic/1897/1 "2026-11-02T08:17:22Z")

</div>

代码评审里冒出一行 `display: grid-lanes`，旁边没写兜底。以前瀑布流多半靠量高度、排进最短那一列，或者用现成的布局库硬算。语法本身进了 CSS Grid 的 Level 3。兼容说明打开一看，离「全员默认可开」还差一截。

## 这套布局在干什么

[MDN《Grid lanes layout》](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Grid_layout/Grid_lanes) 把机制讲清楚了。CSS Grid Level 3 里的 grid lanes，通过 `display: grid-lanes` 或 `inline-grid-lanes` 打开。一个轴仍是严格网格，另一个轴按「当前最空的那条车道」往里堆。条目高低不一也能挤紧，口头常叫 masonry / 瀑布流。

常见写法是列方向走网格、行方向堆叠，再配 `grid-template-columns`。子项可以用 `span` 跨轨，也可以用线定位。MDN 举例里，定了位置的项会先落位，其余再按车道算法填空。行方向当网格、横向往外长也行，那时改用 `grid-template-rows`。

规范侧对应 [CSS Grid Layout Module Level 3](https://drafts.csswg.org/css-grid-3/) 编辑草案里的 Grid Lanes 模型。草案还在改，属性名、容差一类细节别当终身不变的契约抄进业务配置。页面上也能看到 `fit-tolerance` 这类控制「多空才算并列」的旋钮，默认语义偏「差一点点就当差不多」。调太大或调成无限，阅读顺序又容易跳来跳去。

## 兼容表现在怎么读

MDN 页面顶上标着 **Limited availability** ，并标明 **Experimental** ：不是 Baseline，不少常用浏览器还接不上。上生产前要自己再打开兼容表核对。

对照 [MDN 的 browser-compat-data](https://bcd.developer.mozilla.org/bcd/api/v0/current/css.properties.display.grid-lanes.json)（查询键 `css.properties.display.grid-lanes`）：`status.experimental` 为 true。Safari、iOS Safari、iOS WebView 从 **26.4** 起记为支持（表里的 release\_date 是 2026-03-24）。Chrome、Edge、Firefox、Opera 以及对应的 Android 端在这份数据里仍是未标稳定支持。版本号会动，发版前再刷新一次 MDN 表，比背截图靠谱。

不支持的环境里，这行 `display` 会被丢掉。草案自己也谈 graceful degradation：只认普通 Grid 的引擎上，同一套 `grid-template-columns` 往往还能排出多列，只是堆叠轴不会按「最空车道」填缝，空隙会多一些。真要保瀑布流观感，得另留测量布局，或者接受「先多列、后渐进增强」。

Chrome 那边另有过 masonry 相关提案争论，跟现在的 `grid-lanes` 命名不是同一条故事线。业务选型里知道有过分歧就够，不必跟着标准站队吵。

## 上生产前先过这几道

- 目标用户里 Safari 26.4+ 占比多少，能不能接受「少数浏览器好看、其余退回多列 Grid」。
- `@supports (display: grid-lanes)` 能不能盖住增强样式。默认样式读不读得了、点不点得了。
- 有明确阅读顺序的内容（文章流、步骤、表单）慎用乱序感强的堆叠。MDN / 草案都提醒过：自动放置和跨轨混用时，视觉顺序可能跟 DOM 顺序拧巴，焦点和朗读会跟着别扭。
- 子项高度变化剧烈、又大量 `span` 时，先在真机拉一把，别只看设计稿的整齐示意。
- 图片墙、卡片墙这类「条目彼此独立、顺序不敏感」的页面，更适合做第一批试点。导航、结账步骤这种强顺序界面，就算语法支持也先别硬上。

`grid-lanes` 解决的是「一轴网格、一轴填缝」这件布局事，不等于某一类 JS 方案从此没用。列表要虚拟滚动、要精确锚点、要跟业务手势绑死的，照旧得看交互。团队里若已有稳定的测量布局，也可以先把 `grid-lanes` 当渐进层：支持就少算一轮高度，不支持就走老路径。两套并存一阵子很常见。

写法上可以很克制：容器先按普通 Grid 给出可接受的多列，再在 `@supports (display: grid-lanes)` 里把 `display` 换成 `grid-lanes`。这样不支持的浏览器不会空白，支持的浏览器才吃到填缝。实验室里用预览版或打开实验开关试可以，跟「默认全开给所有用户」是两件事，别混着对外承诺。

你们线上有没有已经用 `grid-lanes` 做增强的页面？兼容表之外，还有哪些实际踩坑想记一笔？