原生CSS瀑布流可用grid-template-rows: masonry（Chrome/Edge 116+），降级用grid+minmax(auto-fit)；column-count因DOM与视觉顺序不一致，影响SEO、可访问性及打印；JS方案需处理图片加载、SSR和滚动增量更新；移动端须注意iOS触控事件失效问题。
用 CSS Grid 实现真正响应式的瀑布流卡片
原生 CSS 现在就能做瀑布流，不用 JS 库、不依赖 column-count 的伪方案——关键在于 grid-template-rows: masonry。但它目前只在 Chrome 116+ 和 Edge 116+ 支持，Firefox 和 Safari 还没跟上。
所以实际项目里得 fallback：用 display: grid + grid-template-columns 做等宽多列，靠卡片自身高度差异“模拟”瀑布效果（视觉上接近，但不是真正的 Masonry 布局）。
实操建议：
- 优先写
grid-template-rows: masonry，再用@supports包一层，降级到传统 grid 布局 - 列数别写死，用
minmax(300px, 1fr)配合auto-fit自适应容器宽度 - 卡片内部图片记得加
width: 100%; height: auto;，否则高度塌陷会破坏列对齐
为什么 column-count 不推荐用于生产环境
很多人搜“HTML 瀑布流”第一反应是 column-count + break-inside: avoid，但它有硬伤：卡片顺序是按文档流从上到下、再分栏填满，导致视觉顺序和 DOM 顺序不一致（比如第 1 列最后一张可能是 article[7]），SEO 和可访问性都受影响，键盘 tab 顺序也会错乱。
立即学习“前端免费学习笔记（深入）”；
典型错误现象：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用屏幕阅读器读取时，内容顺序跳着走
- 卡片内有按钮或表单，tab 键焦点路径混乱
- 打印样式（
@media print）下直接变成单列长条，无法控制分页
Vue/React 里用 JS 方案要注意什么
如果必须用 MasonryLayout 类库（比如 React 的 react-virtualized-masonry 或 Vue 的 v-masonry），核心矛盾其实是「动态高度 + 异步加载」带来的重排问题。
容易踩的坑：
- 图片懒加载完成前，JS 拿不到真实高度，导致卡片重叠或留白——必须监听
load事件后手动触发 layout 更新 - 服务端渲染（SSR）时，JS 还没执行，首屏显示为单列或错位，需配合
fallback样式（比如先设成grid布局） - 滚动加载新卡片时，不要每次全量重算所有项高度；用增量更新（如记录已渲染项的
offsetTop和高度）
移动端适配中被忽略的关键点
瀑布流在手机上最常出问题的不是布局，而是触控交互：iOS Safari 的 overflow: auto 容器里，卡片内点击区域可能失灵，尤其是带 position: absolute 子元素的卡片。
解决方式很具体：
- 给瀑布流容器加上
-webkit-overflow-scrolling: touch（仅 iOS 旧版需要） - 确保每张卡片都有明确的
min-height（哪怕只是min-height: 1px），防止 Safari 对高度为 0 的元素优化掉事件区域 - 避免在卡片根元素上同时用
will-change: transform和overflow: hidden，这在部分 Android Webview 里会导致点击穿透
真正的难点不在“怎么堆出来”，而在于高度动态、设备各异、交互路径不可见时，如何让每张卡片都稳稳接住用户的点击和滚动。别信“一套代码全端通”，每个平台的渲染管线和事件机制都得单独验。
