columns 是为纯文本流式分栏设计的，不适用于卡片布局等复杂场景；强行使用会导致断行错乱、元素被切开、响应式异常等问题，且 column-span: all 仅对直接子块级元素生效。
columns 属性在现代浏览器里基本够用，但别指望它像 CSS Grid 那样精准控制
直接说结论：columns 是为纯文本流式分栏设计的，比如新闻正文、博客长段落。它不适用于需要对齐卡片、固定高度容器或复杂交互的布局。强行用它做“多列卡片墙”，八成会遇到断行错乱、子元素被切开、响应式行为反直觉的问题。
常见错误现象：column-count: 3 写了，但内容只占一列；或者图片/按钮被硬生生从中间劈成两半出现在不同列；又或者在 Safari 里列宽忽大忽小。
-
columns是column-width和column-count的简写，两者互斥——设了column-width，浏览器会自动算列数；设了column-count，列宽就随容器宽度弹性变化 - 子元素默认不会跨列（
break-inside: avoid是隐式生效的），但如果你手动加了break-inside: auto或删了它，块级元素就可能被截断 - Firefox 对
columns支持最稳；Safari 在 flex/grid 容器里套columns时容易失效；Chrome 89+ 开始支持column-span: all，但仅限于直接子元素且必须是块级
想让标题横跨所有列？得用 column-span: all，而且只能作用于直接子元素
这是最容易卡住的点：你写了 h2 { column-span: all; }，结果没反应。大概率是因为这个 h2 不是 columns 容器的**直接子元素**——比如它被包在 <div class="wrapper"> 里了。
<p>使用场景很具体：长文章中插入一个章节标题，希望它独占一行、横贯全部列宽，下面内容继续分栏。</p>
<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<ul>
<li>必须满足三个条件：该元素是分栏容器的直接子元素 + 是块级元素 + 没有设置浮动或绝对定位</li>
<li>
<code>column-span: all 不触发新的 BFC，所以它不会影响后续内容的分栏逻辑
column-gap 和 gap 的区别：前者只管列间距，后者在 Grid/Flex 里才真正起作用
很多人以为 gap 能统一控制所有布局的间隙，但在 columns 场景下，gap 完全无效。必须用 column-gap，否则列与列之间紧贴着，文字挤成一团。
性能影响不大，但兼容性要注意：IE 完全不支持 column-gap，老 Android WebView 也不认；而 gap 在 Flex 布局中，Android 5.0+ 才稳定支持。
-
column-gap: 2rem是标准写法；column-gap: normal表示约 1em，但实际渲染因字体而异 - 不要混用：
gap设了 1rem，column-gap又设 2rem，后者生效，前者被无视 - 如果同时用了
columns和display: grid，注意：grid 容器内部的columns会被降级处理，某些浏览器会静默忽略
内容被切断、图片错位、打印预览异常？先关掉 break-inside 和 column-break
这是最常被忽略的调试入口。默认情况下，columns 会尽量避免在块级元素中间断开，但一旦你显式设置了 break-inside: auto，或者用了 column-break-before/after，就等于把控制权交给了浏览器的碎片化引擎——而它的判断经常和人意相反。
典型表现：打印 PDF 时某张图跑到下一页顶部、移动端横屏时卡片突然分成两截、React 动态渲染后列高严重不均。
- 检查所有直接子元素是否意外带了
break-inside；特别是第三方 UI 组件（如 antd 的Card）可能自带该样式 - 避免使用
column-break-before: always—— 它在多数浏览器里支持度差，且极易导致空白列 - 如果内容必须保持完整（比如一个带表单的卡片），直接放弃
columns，改用display: grid配合grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))
真要用 columns，就得接受它是个“文本流优化工具”，不是通用布局方案。那些看似细微的断行规则、浏览器碎片化策略、以及 print 媒体查询下的行为差异，才是实际落地时最耗时间的地方。
