column-count仅实现视觉近似瀑布流，非真Masonry布局；它按DOM顺序线性切分内容，不感知子元素高度、不找最短列，导致DOM与视觉顺序错位、卡片易截断、交互失准。
columns 属性不是为瀑布流设计的，强行用它做“卡片式瀑布流”会掉坑里——这不是兼容性问题，是语义和行为逻辑的根本错配。
为什么 column-count 看起来像瀑布流，实际却不可靠
浏览器把容器当作文本流处理：子元素按 DOM 顺序依次填入列中，填满一列再进下一列。这导致：
- 第 1 个卡片在左列顶部，第 2 个就在右列顶部，第 3 个又回到左列中部——时间倒序列表读起来是“跳着走”的
- 点击事件绑定按 DOM 序号取值，用户点右上角卡片，JS 却拿到第 5 个元素的数据
- 图片被截断，不是因为样式写错，而是没加
break-inside: avoid，或父容器用了overflow: hidden强制裁剪 - 安卓低端机（尤其 Android 9 及以下 WebView）对
-webkit-column-count有残留依赖，不加前缀可能回退成单列
column-count + break-inside: avoid 的最小可用配置
真要压着用，必须同时满足这四点，缺一不可：
- 容器设明确宽度，比如
width: 100%或max-width: 768px；不能是display: inline或inline-block - 子元素不能有
float、position: absolute或transform，否则脱离文档流，break-inside失效 - 必须写
break-inside: avoid（Firefox 还要加avoid-column） -
column-gap建议 ≤16px；过大时浏览器可能因列宽不足直接放弃多列，回退成单列滚动
示例关键 CSS：
立即学习“前端免费学习笔记（深入）”；
.masonry-container {
width: 100%;
column-count: 2;
column-gap: 12px;
}
.masonry-container > * {
break-inside: avoid;
break-inside: avoid-column; /* Firefox 兼容 */
margin-bottom: 12px;
}哪些场景下可以勉强用 columns，哪些绝对不行
能用的前提是：内容顺序不重要、交互极简、不依赖 DOM 位置做 JS 计算。
- ✅ 适合：图文混排的长文章摘要页、静态新闻卡片墙、后台日志预览（只读+无排序）
- ❌ 绝对不行：电商商品列表（需价格排序/筛选）、社交 Feed（时间倒序+点赞计数绑定 DOM）、带编辑/删除操作的卡片管理页
- ⚠️ 风险高：微信内嵌页（iOS 微信 8.0.44+ 已修复，但部分安卓版微信仍卡在旧 WebView）
真正需要稳定瀑布流，columns 不是捷径，是临时补丁。它的列高不均衡、DOM 顺序与视觉顺序分离、事件绑定错位，都是设计使然，不是 bug —— 你越想绕过这些，越容易在上线后花三倍时间 debug。
