columns 属性无法实现真正的瀑布流，因其按 dom 顺序线性切分内容，导致视觉与逻辑顺序错位、交互异常、可访问性缺陷；仅适用于无交互纯文字场景，卡片类内容应避免使用。
columns 属性不能实现真正的瀑布流（Masonry），它只是把内容当作文本流线性切分，DOM 顺序和视觉顺序不一致——这不是写法问题，是浏览器规范行为本身决定的。
为什么 column-count 看起来像瀑布流却不能当瀑布流用
浏览器按 DOM 顺序从上到下、从左到右“填格子”，不是找最短列插入。结果就是：
- 第 1 个卡片在左列顶部，第 2 个直接跳去右列顶部，第 3 个又回到左列中部
- 点击右上角卡片，JS 拿到的是第 2 个元素，但用户以为点的是第 1 个
- 图片被截断，不是因为你忘了加
break-inside: avoid，而是因为没设display: block，img 默认是 inline 元素，会被硬切 - 屏幕阅读器读序错乱，键盘 Tab 顺序跳着走
column-count 能跑通的最低配置（缺一不可）
仅适用于纯文字摘要、词典条目等无交互、无图片、高度可预估的场景。卡片类内容强烈不推荐。
- 容器必须设
column-gap（不能依赖默认值；iOS Safari 默认1em，容易挤爆） - 每个子项必须写
break-inside: avoid（Safari 15.4+ 才稳定支持；旧版需加-webkit-column-break-inside: avoid） - 容器必须有
max-height或height（否则列高无限拉长，只显示一列） - 子项不能有
float、position: absolute、transform，否则脱离文档流，break-inside失效
移动端适配最容易翻车的三个点
这些不是边缘 case，而是上线后高频报障点：
- 横屏旋转时，
column-count不会自动重算列数——得监听resize事件手动切换，或改用column-width+min-width组合（但列数不可控） - 图片异步加载完成前高度为 0，导致列高预估错误、后续卡片错位；建议用
aspect-ratio或padding-top占位，确保初始宽高比稳定 - 懒加载失效：基于
window.scrollY的方案在多列容器里完全不可用；必须用IntersectionObserver监听每个卡片自身，且rootMargin别设太大负值（iOS Safari 对负 margin 处理不稳定）
真正需要稳定瀑布流时，别硬扛 columns
截至 2026 年 9 月，grid-template-rows: masonry 仅 Chrome/Edge ≥116 支持，Firefox 和 Safari 仍完全不支持。这意味着约 35% 的真实用户看到的是等高网格而非瀑布流。更稳妥的做法是引入轻量 JS 库（如 vanilla-masonry），配合 Tailwind 样式分离——复杂点在于 layout 触发时机（比如图片加载完、字体加载完、动态内容插入后），而不是 CSS 写几行。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
