column-count只是伪瀑布流，因按文档流切分导致dom与视觉顺序不一致，引发无障碍、seo及交互问题；真瀑布流需用@supports包裹的grid-template-rows: masonry或grid-auto-flow: dense降级方案。
column-count 为什么看起来像瀑布流但实际不是
它只是把连续内容按列切分，DOM 顺序和视觉顺序不一致——比如第 1 列底部的卡片可能是 article[7]，导致屏幕阅读器乱序、tab 键焦点跳转、打印样式崩坏。它不计算列高，也不“找最短列插入”，纯靠浏览器流式截断。
常见翻车点：
-
img默认是inline，在 Chrome 下会留白；Safari 对column-gap渲染偏移 1px - 卡片用了
float或display: inline-block，直接脱离文档流，column-count失效 - 没加
break-inside: avoid（Firefox 还得补page-break-inside: avoid），卡片被硬生生劈成两半 - 容器没设
max-width，小屏下column-count: 3撑破布局
grid-template-rows: masonry 是真瀑布流，但别直接用
Chrome/Edge 116+ 支持，Firefox 和 Safari 仍无动静。写死它会导致其他浏览器完全不渲染或回退到单列——必须用 @supports 包一层：
container {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
}
@supports (grid-template-rows: masonry) {
container {
grid-template-rows: masonry;
}
}
关键限制：
- 不能和
grid-auto-flow: column混用，会冲突 -
img必须设width: 100%; height: auto;，否则高度塌陷破坏列对齐 - 容器不能设
overflow: hidden，否则跨行卡片被截断
grid + grid-auto-flow: dense 是当前最稳的降级方案
它不真正“找最短列”，但靠密度填充能模拟出接近效果，兼容性好，且 DOM 顺序与视觉一致。前提是：每张卡片得手动控制行跨度。
实操要点：
- 列数用
minmax(300px, 1fr)而非固定repeat(3, 1fr)，避免小屏挤变形 - 每张图需设
grid-row-end: span X，X 来自原始宽高比换算（比如 4:3 图 →span 2），否则全堆第一行 - 图片加载前高度为 0，必须预留空间：
aspect-ratio: 4/3或服务端传宽高属性再 JS 补算 - 别在 grid 容器上套
transform或filter，会干扰grid-auto-flow布局
JavaScript 方案里最容易被忽略的加载时机
不是等所有图片 load 完才排版，而是每张图加载完立刻重算并插入——否则用户看到的是空白容器或错位卡片。
关键细节：
-
img标签必须带width和height属性（哪怕只是占位值），否则getBoundingClientRect()返回0 - 动态加新卡片时，调用
layout.appended(newItems)，而不是layout.reloadItems()（后者性能差） - SSR 场景下，首屏要 fallback 成
display: grid布局，JS 执行后再切换为 Masonry - iOS Safari 中，如果卡片含
position: absolute子元素，点击可能失灵，需加-webkit-overflow-scrolling: touch并确保卡片有min-height: 1px
grid-template-rows: masonry 是终点，但今天还得靠 @supports + grid-auto-flow: dense + 图片预占位撑住底线。最麻烦的永远不是布局本身，而是图片异步加载带来的高度不确定性——这点，CSS 控不住，只能靠 JS 精准干预。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
