纯CSS的column-count仅能实现多栏流而非真瀑布流，因无法动态匹配列高；真瀑布流需JS计算最短列插入或CSS Grid配合grid-auto-flow:dense与预设宽高控制。
纯 CSS 的 column-count 能快速搭出“形似”瀑布流，但图片高度不一、加载异步、列高不均时，它会截断元素或留白严重——这不是真瀑布流，只是多栏流。要让图片“自动塞进最短列”，必须靠 JavaScript 动态计算列高并插入，或者用现代 CSS grid + auto-flow: dense 配合显式行高控制（有限制）。
用 column-count 实现简易多栏流（适合静态、宽高可控内容）
这个方案只改 CSS，零 JS，但有硬伤：浏览器按文档流顺序切片分栏，不关心每列实际高度；break-inside: avoid 只能防止单个 .item 被跨列截断，无法避免某列明显更短。
-
.container必须设固定宽度或max-width，否则在小屏下column-count: 3可能撑破布局 -
img要设width: 100%+height: auto，否则等比失效，图片被拉伸或压缩 - 图片未加载完成时占位高度为 0，会导致后续元素错位——必须配合
aspect-ratio或服务端预传宽高来预留空间 - 响应式切换列数需 JS 监听
resize并动态改style.columnCount，CSS 媒体查询对column-count支持不一致
用 JavaScript 手动实现“最短列优先”插入（兼容性好、逻辑透明）
核心是维护一个列高数组，每次插入新图片前找出当前最短列的索引，把该图片 appendChild 进去，并更新对应列高。关键不在“怎么算”，而在“什么时候算”。
- 不能等所有图片
load完再排——用户会看到空白容器；应监听每个img.onload，加载完一张就立即计算插入 - 列容器必须是独立的 DOM 元素（如
div.col-0,div.col-1），不能靠绝对定位模拟——否则语义和可访问性崩坏 - 图片原始尺寸未知时，先用
new Image()预加载获取width/height，再按目标列宽等比缩放算出渲染高度，避免回流 - 滚动加载新图时，别重复初始化列高数组；应在已有列中继续找最短列，而不是重置为 0
用 display: grid 搭配 grid-auto-flow: dense（现代浏览器首选）
CSS Grid 本身不原生支持“最短列优先”，但通过 grid-template-rows 配合 grid-row-end 手动指定结束行，可逼近效果；更实用的是结合 JS 控制 grid-row 行号，或用 grid-auto-flow: dense 让空缺被自动填充——前提是所有项都带明确的 grid-row 起始位置。
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
-
grid-template-columns: repeat(3, 1fr)固定三列，但列宽会随内容挤压；加minmax(300px, 1fr)更稳 - 每张图需设
grid-row: span X（X 为根据原始比例换算出的行数），否则全挤在第一行——这一步仍需 JS 计算 -
grid-auto-flow: dense仅在有空缺格子时才启用填空逻辑，若所有项都指定了grid-row-start，它就不起作用 - Safari 对
grid-row: span的动态更新有渲染延迟，建议用requestAnimationFrame批量写入
图片加载与懒加载必须同步处理
瀑布流最常崩在图片加载阶段：占位高度为 0 → 插入后突然撑开 → 下方所有列重排 → 页面跳动。这不是布局问题，是资源加载时序问题。
- 服务端返回数据时，务必携带每张图的
width和height，前端用aspect-ratio: w / h预留空间 - 不用
loading="lazy"原生懒加载——它和瀑布流 JS 插入逻辑冲突，容易导致图片反复加载或漏加载 - 自定义懒加载应基于容器
getBoundingClientRect()判断是否进入视口，且触发后立刻img.decode()确保解码完成再插入 DOM - 加载失败的图片要降级显示占位色块，并维持原有高度，避免列高统计错乱
真正稳定的瀑布流，不是选一种 CSS 写法，而是把图片尺寸预知、加载时序、列高状态管理、插入时机这四件事串成闭环。其中最容易被跳过的，是“在图片 load 完成回调里更新列高并插入”，而不是等所有图片 ready 后统一排——后者在真实网络环境下几乎必然导致页面抖动或白屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
