column-count实现的是列优先的伪瀑布流，DOM顺序与视觉顺序不一致，仅适用于纯展示场景；真瀑布流需JS（如Masonry）动态找最短列；小屏应切为Grid布局以保障体验与语义正确性。
用 column-count 实现基础瀑布流，但内容顺序是“从上到下、再换列”
原生 CSS 多列布局（columns）确实能快速生成视觉上的多栏瀑布效果，但它按**列优先**分块：第一列填满高度后才进第二列，导致 DOM 顺序和视觉顺序不一致——比如第 1、4、7 条目会出现在第一列，而非按自然流“谁短谁先落”。这在需点击跳转、SEO 或屏幕阅读器场景中容易出问题。
适用场景：纯展示型图文卡片墙（如相册预览），且不要求语义顺序或交互精准定位。
-
column-count: 3+column-gap: 1rem是最简配置 - 必须给容器设
height或max-height，否则列高无限，只显示一列 - 子项不能用
break-inside: avoid（部分浏览器不支持），否则出现空白列 - 无法单独控制某一项的跨列行为，
column-span: all只对块级元素有效且兼容性有限（Chrome/Firefox 支持，Safari 需-webkit-column-span）
JavaScript 辅助实现真瀑布流：Masonry 布局的核心逻辑
所谓“真瀑布流”，是指每个新元素插入时，自动找到当前最短列的底部位置进行追加。CSS 本身不提供列高感知能力，必须靠 JS 计算。
主流做法不是手写循环找最小高度，而是复用成熟方案：
立即学习“Java免费学习笔记（深入）”；
- 用
Masonry库（来自vanilla-masonry或css-masonrypolyfill）：轻量、无依赖，API 简洁，例如new Masonry(container, { itemSelector: '.item' }) - 若已用 React，推荐
react-virtualized-auto-sizer+masonic，它结合虚拟滚动，长列表性能更稳 - 避免用 jQuery 插件（如
isotope），体积大、维护停更、与现代构建工具集成差 - 注意：所有 JS 方案都要求子项有明确高度（不能是
height: auto且内部含异步图片），否则首次布局错乱；建议图片加loading="lazy"并监听load后调用layout()
Firefox / Safari 对 column-fill: balance 的处理差异
CSS 多列默认填充策略是 column-fill: auto（按文档流顺序填满一列再下一列），而 balance 才试图均分内容——但实际表现不一致：
- Chrome 和 Edge 完全支持
column-fill: balance，多列高度基本齐平 - Firefox 仅在容器有固定
height时生效，否则回退为auto - Safari 直到 v17.4 才完整支持，旧版本忽略该声明，始终按
auto渲染 - 即使开启
balance，也无法解决“第 5 个元素卡在第二列顶部、下方大片留白”的问题——因为它是基于文本流断行计算的，不是基于块级元素高度重排
响应式切换：何时该放弃瀑布流改用 Grid
小屏设备上，3–4 列瀑布流挤在一起，卡片过窄，图片变形，操作热区太小。此时硬撑瀑布流反而损害体验。
- 用媒体查询在
max-width: 768px下切回display: grid+grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)) - Grid 不模拟瀑布，但能保证每行元素等宽、顺序严格、可设置
gap、支持aspect-ratio控制卡片比例 - 若仍需“视觉瀑布感”，可在 Grid 中对奇数项加
margin-bottom: 1rem，制造错落节奏，比强行 JS 计算更轻量可靠 - 别在移动端还跑 Masonry —— 滚动性能敏感，且手指滑动惯性易触发多次重排
