纯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 渲染模型的客观限制。