纯css瀑布流（如column-count）无法感知图片实际高度，未加载时高度为0，导致内容被强行折行截断；grid+aspect-ratio方案最稳，但需每张img预设宽高比，否则dense填充失效。
能解决，但不是“开箱即用”——HTML瀑布流本身不处理图片尺寸不确定性，必须配合预设宽高比、加载监听或占位策略，否则必然出现塌陷、跳动、错位。
为什么纯 CSS 瀑布流（column-count）常导致图片截断
column-count 把内容当作文本流切分，不感知子元素高度； 在未加载完成前 height 为 0 或由行高撑开，浏览器强行折行后，图片可能被硬生生“劈成两半”显示在不同列。
- 尤其在响应式场景下，列数随宽度变化，但图片实际渲染高度始终滞后于布局计算
- 没有
break-inside: avoid支持的旧浏览器（如 Safari ≤15.2）会无视该声明，截断更频繁 - 即使加了
display: block，也无法阻止 column 布局对图片“按文本流切”的本质逻辑
grid + aspect-ratio 是目前最稳的纯 CSS 方案，但有硬性前提
它能避免 JS 计算、无重排抖动，但前提是每张 <img> 必须携带可推导的宽高比，否则 grid-auto-rows 无法预估轨道高度，dense 填充就失效。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 服务端返回 HTML 时，务必写入
width和height属性，或至少data-width/data-height，供 JS 注入style="aspect-ratio: w/h;" - 不要依赖
sizes+srcset自动推导——浏览器不会在布局阶段解析它们 - Safari 15.4+ 才完整支持
aspect-ratio与grid-auto-flow: dense协同；低于此版本需降级为伪元素 padding-bottom 占位
JS 实现（如 Masonry）为何仍容易错位
不是算法问题，而是时机问题：绝大多数实现监听的是 load 事件，但图片加载完成 ≠ 渲染完成 —— 尤其在 loading="lazy" 或网络波动时，getBoundingClientRect() 取到的仍是 0 高度。
- 正确做法是：设
src后立刻监听load和error，并在回调里调用 layout 更新，而非等 IntersectionObserver 触发后再设src - 组件化框架中，避免把整个瀑布流列表封装成一个强响应式组件；新增图片应只触发局部 re-render，否则 grid lines 全量重算，性能雪崩
- DOM 节点少于 50 个时，其实没必要上 Masonry —— 直接用
grid+aspect-ratio更轻量、更可靠
最易被忽略的一点：瀑布流布局对图片的“控制权”仅限于排列逻辑，它既不加载图片，也不决定宽高。所有错位问题，根源都在图片尺寸未在布局前确定 —— 这不是 CSS 的缺陷，而是 Web 渲染模型的客观限制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
