column-width 比 column-count 更适合移动端响应式多栏布局，需搭配 column-gap、块级容器包裹、break-inside 避免分栏断裂，并通过图片占位和懒加载优化防抖动。
column-count 在移动端能快速起效，但必须配合 column-width 才算真正响应式；纯靠 column-count: 3 会卡死列数，小屏下卡片被压缩变形，这不是“多栏瀑布流”，只是“三列硬切”。
用 column-width 替代 column-count 实现自适应列数
移动端屏幕宽度变化大，固定列数（如 column-count: 3）会导致：小屏时单列过窄、文字换行混乱、图片被强行缩放；大屏又可能留白。正确做法是放弃列数控制，改用最小列宽驱动：
-
column-width: 280px是安全起点——兼顾 iPhone 竖屏（375px 宽）和安卓中屏，确保至少一列不被挤碎 - 搭配
column-gap: 12px，避免小屏间隙占比过大 - 不要同时写
column-count和column-width，后者优先级更高，前者会被忽略 - 容器需设
width: 100%或max-width: 100%，否则在某些 WebView 中column-width不触发重算
break-inside: avoid 在移动端的兼容补丁必须写全
裸 break-inside 支持极差，常见现象是长图被截成两段、出现在不同列。根本原因是：浏览器把
- 每个卡片必须用块级容器包裹，如
-
.item { break-inside: avoid; -webkit-column-break-inside: avoid; page-break-inside: avoid; }—— 三者缺一不可 - 别给
.item设height或min-height，否则加载前高度为 0，break-inside失效，先错位后跳变 - 若内容含文字描述，用
line-clamp控制行数，避免高度剧烈波动影响列平衡
图片加载导致的重排抖动必须防住
移动端网络慢、图片懒加载普遍，column-count/-width 依赖最终渲染高度做分栏。未加载完成时，
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 给
loading="lazy"同时，必须配width和height属性（哪怕只是原始尺寸），让浏览器预留空间 - 更稳妥方案：用
aspect-ratio: 4/3+height: 0+padding-bottom: 75%占位（注意 Safari 15.4+ 才支持aspect-ratio） - 监听
img.onload后不立即重排，而是标记该.item已就绪；等所有图片加载完或超时（如 3s），再触发一次container.style.columnGap = container.style.columnGap强制重绘 - 避免在
scroll或resize里调用任何重排逻辑——移动端这些事件高频触发，直接卡顿
真瀑布流（最短列优先）在移动端 JS 方案要精简
如果你的业务强依赖“哪列短塞哪列”（比如电商商品瀑布流、评论区动态插入），column-width 的顺序填充分配就不够用了。此时 JS 方案不能照搬桌面端逻辑。
- 别用
getBoundingClientRect().height，它在 iOS WKWebView 中偶发返回 0；改用offsetHeight（含 padding/border） - 列高数组缓存必须按屏幕宽度分桶，比如
cache[320] = [120, 98, 142]，resize时只在宽度变化 ≥ 2px 才重建，避免频繁计算 - 动态插入新项时，用
requestIdleCallback延迟布局，防止主线程阻塞导致滚动卡顿 - 优先选
vanilla-masonry而非masonry-layout：前者体积小（imagesLoaded 检测，适合移动端资源敏感场景
真正难的不是实现“多栏”，而是让每张图在不同网络、不同设备、不同加载时机下都稳稳落在该落的位置。列数可以算，但图片的高度永远在加载完成那一刻才真正确定。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
