代码评审里冒出一行 display: grid-lanes，旁边没写兜底。以前瀑布流多半靠量高度、排进最短那一列，或者用现成的布局库硬算。语法本身进了 CSS Grid 的 Level 3。兼容说明打开一看，离「全员默认可开」还差一截。
这套布局在干什么
MDN《Grid lanes layout》 把机制讲清楚了。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 编辑草案里的 Grid Lanes 模型。草案还在改，属性名、容差一类细节别当终身不变的契约抄进业务配置。页面上也能看到 fit-tolerance 这类控制「多空才算并列」的旋钮，默认语义偏「差一点点就当差不多」。调太大或调成无限，阅读顺序又容易跳来跳去。
兼容表现在怎么读
MDN 页面顶上标着 Limited availability，并标明 Experimental：不是 Baseline，不少常用浏览器还接不上。上生产前要自己再打开兼容表核对。
对照 MDN 的 browser-compat-data（查询键 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 做增强的页面？兼容表之外，还有哪些实际踩坑想记一笔？