HTML瀑布流失效的根本原因是图片缺乏可预测的宽高比。必须显式设置width/height或aspect-ratio，配合srcset/sizes、禁用首屏lazy加载、避免column-count截断、监听img.load而非仅IntersectionObserver，并启用grid-auto-flow:dense。
HTML 瀑布流本身不会“影响”图片布局，但图片布局不当会直接破坏瀑布流——不是布局错，是根本排不起来。
图片没设宽高或 aspect-ratio，瀑布流就失效
浏览器渲染 <img alt="HTML瀑布流会影响图片布局吗_图片布局对HTML瀑布流限制【入门】" > 时，若未声明 width/height 属性、也未用 CSS 设置 aspect-ratio，其初始尺寸为 0×0 或由内容撑开。CSS Grid Masonry 或 column-count 都依赖子元素有可预测高度来分列；一旦高度为 0，所有图片会被压进第一列顶部，后续列空着，视觉上变成单列+大片留白。
- 必须给每张图提供明确的宽高比：用
<img style="max-width:90%" style="max-width:90%" alt="HTML瀑布流会影响图片布局吗_图片布局对HTML瀑布流限制【入门】" >，或img { aspect-ratio: 3/4; } -
srcset+sizes要配好，否则响应式场景下aspect-ratio仍可能被覆盖 - 慎用
loading="lazy"在首屏瀑布流中——它延迟加载，导致占位失效，grid 轨道线按 0 高度生成，后续图片一加载就跳动
用 column-count 做瀑布流，图片会被截断或错位
column-count 是纯 CSS 最简方案，但它把容器切成固定列数后，按文档流顺序切块填入，不感知单个图片高度。结果就是：一张高图被硬生生从中间劈开，上下两截分在不同列；或者因某列已满，整张图被挤到下一列顶部，造成列高严重不均。
- 仅适用于静态、高度相近、且允许截断的图片集（比如小图标网格）
- 动态加载场景下，
column-count完全无法响应新图插入，必须配合 JS 重置列数或强制重排 - 用
ResizeObserver替代window.addEventListener('resize')监听容器变化，避免侧边栏展开等非窗口 resize 引发的误重排
JS 手写瀑布流时 getBoundingClientRect() 拿到的是 0
很多手写方案在图片还没加载完成就调用 getBoundingClientRect()，返回 height: 0。于是所有图片都被塞进“最短列”——其实就是第一列，整个瀑布流退化成左对齐单列。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
立即学习“前端免费学习笔记（深入）”；
- 必须监听
img.onload或img.addEventListener('load')，确保图片解码完成后再取尺寸 - 懒加载场景下，不要等 IntersectionObserver 触发才设
src，而应在设src后立刻监听load和error，失败时 fallback 到占位图高度 - 避免在 React/Vue 等框架中把整个瀑布流列表封装成一个组件并频繁 re-render——每次更新都触发全量 grid 轨道线重计算，性能断崖下跌
grid-auto-flow: dense 不加，瀑布流就不是“流”
CSS Grid 实现瀑布流时，grid-auto-flow: dense 是关键开关。不加它，Grid 会严格按顺序填入，遇到前面某个格子太高、后面留出空隙，也不会把短图塞进去补空——结果是列底参差、大量白边，完全失去瀑布感。
- 必须配对使用：
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))+grid-auto-flow: dense - 禁用
img { vertical-align: middle }或任何改变基线的行为，否则 Grid 行高判断失准，dense 填充错位 - Safari 对
grid-auto-flow: dense+masonry支持仍不稳定，需降级为column-count或 JS 方案
真正难的不是让图片“看起来像瀑布”，而是让它们在各种加载时机、缩放行为、屏幕切换下，始终稳定占据正确位置——这要求你把图片当作有确定尺寸的实体来对待，而不是等它自己“长出来”。
