纯CSS瀑布流不能用float实现等高列，因其过时、易错且破坏可访问性；推荐column-count（内容需为块级流）或CSS Grid（适合交互卡片），强需求则用Masonry库。
纯 CSS 瀑布流无法用 float 实现真正等高列分布，强行用 float + JS 动态算高不仅过时、易出错，还会破坏可访问性和响应式行为。
为什么 float + JS 算高是危险组合
这种方案本质是模拟多列布局：JS 遍历每个元素，按当前各列最低高度插入，再更新该列高度。但问题很实在：
-
float本身已废弃多年，不支持 flex 或 grid 的对齐、换行、基线控制能力 - JS 必须监听
window.resize和 DOM 变化，漏掉任一触发点就会错位（比如图片懒加载完成） - 计算列高依赖元素真实渲染尺寸，但
getBoundingClientRect()在display: none或未渲染区域中返回0 - 无障碍阅读器会按 HTML 顺序读取，而 JS 插入顺序打乱了 DOM 流，导致语义错乱
现代替代方案：用 column-count 实现真 CSS 瀑布流
原生支持、零 JS、自动断行、响应式友好——前提是内容为纯块级流式结构（如文章段落、卡片列表）：
.masonry {
column-count: 3;
column-gap: 1rem;
}
.masonry > * {
break-inside: avoid; /* 防止单个卡片被截断 */
margin-bottom: 1rem;
}注意点：
立即学习“前端免费学习笔记（深入）”；
-
column-count是固定列数，响应式需配合媒体查询切换，例如@media (max-width: 768px) { column-count: 1; } -
break-inside: avoid在 Safari 旧版本中需加-webkit-column-break-inside: avoid - 不支持子元素设置
height: 100%或position: absolute定位，会脱离列流
需要交互/复杂卡片？用 CSS grid + grid-auto-flow: dense 模拟
这不是严格意义的瀑布流（不按高度最优填充），但视觉效果接近，且完全可控：
.grid-masonry {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
grid-auto-flow: dense;
gap: 1rem;
}
.grid-masonry > *:nth-child(odd) { grid-row-end: span 2; } /* 手动控制高度差异 */
适用场景：
- 卡片高度差异不大（如带图标题卡）
- 允许手动标注某些项跨行（用
grid-row-end） - 需支持 hover 动画、焦点管理、服务端渲染
坑点：grid-auto-flow: dense 可能重排已有元素位置，若依赖 DOM 顺序做逻辑（如分页锚点），需额外处理。
必须用 JS？选 Masonry 库而非手写算法
如果业务强依赖“绝对精准高度排序”（如电商商品瀑布流、Pinterest 风格），别自己写高度队列和重排逻辑。直接用维护良好的 Masonry 库：
- 它内置了
imagesLoaded钩子，等图片加载完再布局 - 提供
layout、appended、reloadItems等明确 API 控制时机 - 支持
percentPosition: true避免因父容器缩放导致的偏移累积误差 - 最新版已放弃
float，底层用position: absolute+ transform 定位，兼容性更好
初始化示例：
const elem = document.querySelector('.grid');
const msnry = new Masonry(elem, {
itemSelector: '.grid-item',
columnWidth: '.grid-sizer',
percentPosition: true
});注意：务必在容器有明确宽度（非 max-content）且子元素不设 margin 冲突的前提下使用，否则列宽计算会漂移。
真正难的不是让卡片“看起来像瀑布”，而是保证它在图片加载中、屏幕缩放时、键盘导航下、打印预览里都稳定。越早放弃 float + 手动高度队列，越少掉进重绘、语义、可访问性的连环坑里。
