flex space-between最后一行错位？四种解法彻底讲透

先说我自己的亲身经历。之前做某个商城活动页，商品列表用的就是flex + justify-content: space-between，一行四个卡片。数据接口返回的数量是动态的，有时候 7 个，有时候 9 个，结果每次刷新都能看到最后一行要么孤零零一个卡片贴在左边，要么两个卡片被拉到整行两端、中间空出一道能开车的缝。调到最后才发现，问题的根源根本不是数据，而是justify-content: space-between在最后一行数量不足时，会把行内剩余空间平均塞进元素之间的间隙里——它根本不关心这一行是不是"满编"。

这篇文章就把这个问题彻底讲透：先从 flex 的排版机制拆为什么会出现错位，再给出占位元素、CSS Grid、gap + flex-start改良、JavaScript 动态补齐四种解法，每种都配可直接抄的代码和适用场景。内容适合刚接触 flexbox 的初中级前端，也适合被这个 bug 折磨过、想搞清楚原理再动手的老手。

1. 问题现象与根因分析

1.1 复现这个问题的标准姿势

先说怎么稳定复现。假设容器是这样的：

.card-list { display: flex; flex-wrap: wrap; justify-content: space-between; gap: 20px; } .card { width: calc(25% - 15px); }

一行四个卡片。当卡片总数是 8、12、16 这种 4 的整数倍时，一切正常，每一行四个卡片均匀分布，左边贴左、右边贴右。可一旦总数变成 7、9、10、11，最后一行就出问题了：

• 剩 3 个卡片时，三个卡片被强行拉开，左右两个贴着容器边缘，中间的间距比其他行大出一截；
• 剩 2 个卡片时，两个卡片一个在最左、一个在最右，中间像裂开一样；
• 剩 1 个卡片时，它孤零零留在左边，上面几行都是满的，视觉上像排版出了大窟窿。

这个现象在实际页面里非常常见：电商的商品列表、后台的卡片看板、图片瀑布流、标签云，凡是用 flex 做"自动换行 + 两端对齐"的地方，都会踩到。

有意思的是，你把同样的布局改成text-align: justify的文字排版，会发现一模一样的规律——最后一行不满时不会两端对齐。这两者的底层逻辑其实是相通的，都是"只处理当前行的水平分布，不关心这一行有没有占满"。

1.2 根因：flex 根本不认识"列"

要理解错位，就得先理解 flex 的换行机制。flex 容器的主轴上，子元素按照flex-basis决定的宽度一个个排列，排不下了就根据flex-wrap: wrap换到下一行。这个"换行"的判断标准只有一条：当前行剩余空间够不够放下一个元素。至于这一行打算放几个、是不是跟上一行同样数量，flex 完全没有概念。

justify-content: space-between的作用，是把当前行所有元素在主轴方向上的剩余空间，平均分配到元素与元素之间。这句话拆开看有两个关键点：

• 它只对"当前行"生效，所以每一行是独立计算的；
• 它分配的是"剩余空间"，不是"固定列之间的间隔"。

当一行有 4 个元素时，剩余空间可能只有几十像素，分到 3 个间隙里，每个间隙看起来是均匀的。但当最后一行只有 2 个元素时，这一行的剩余空间可能达到几百像素，只分到 1 个间隙里，于是这个间隙被撑得巨大。两三个元素看着像"错位"了，本质上它们没有错位，只是被平均分配逻辑放到了一个不该出现的间距里。

再说细一点，即使最后一行只剩 1 个元素，space-between会让它顶到行的起始边（也就是左边）。因为元素之间没有第二个元素，也就没有间隙可以分配，它的位置不受justify-content影响。于是这一行呈现的效果和上面几行完全对不上。

理解了这条根因，后面看所有解决方案都会很清晰：既然问题出在"最后一行没有占满，剩余空间被乱分"，那思路无非两条——要么把最后一行用隐形元素补齐，让它看起来是满的；要么换一个真正知道"每行该放几个"的布局模型。下面四种方案分别对应这两条路。

2. 方案一：占位元素补齐最后一行

2.1 最简单的单人占位：::after 伪元素

如果你的列数固定、而且最后一行只会缺一个元素，用伪元素补位是最省事的。思路是：在容器末尾加一个看不见的元素，让这一行在 flex 眼里是满的。

.card-list { display: flex; flex-wrap: wrap; justify-content: space-between; gap: 20px; } .card { width: calc(25% - 15px); } .card-list::after { content: ""; width: calc(25% - 15px); height: 0; visibility: hidden; }

::after本质是一个伪元素，它和真实子元素一样参与 flex 布局。设置了和卡片相同的宽度之后，最后一行如果是 3 个真实卡片加 1 个伪元素，刚好凑成 4 个，space-between就会把这一行的间距分配到 3 个间隙里，看起来跟上面几行完全一致。

注意几个细节。第一，伪元素要给height: 0，否则它会把最后一行的行高撑高。第二，要用visibility: hidden而不是display: none——display: none的元素完全不参与布局，补位就失效了。第三，如果你用的是margin而不是gap来做间距，伪元素也必须设置相同的margin，否则宽度算对了但间距对不上。

这个方案的局限也很明显：伪元素只有::before和::after两个，最多补两个位置。如果最后一行可能缺 2 个以上的元素，单靠伪元素就搞不定了。另外你仔细想一下，伪元素其实永远存在，哪怕你的数据恰好是完整的行数，这个"幽灵元素"也会独自落到新的一行。因为它的高度是 0，视觉上通常看不到，但在有gap的容器里，它会额外产生一条空行间距，导致容器底部多出 20 像素左右的空白。这是我实际踩过的坑，后面在避坑部分细说。

2.2 缺多个位置时：DOM 占位节点

当数据量不固定、最后一行可能缺 1 到 3 个元素时，就得靠真实 DOM 节点来占位了。实现方式有两种：一是在后端模板直接输出占位节点，二是前端拿到数据后根据总数补齐。

假设列表是 Vue 或者 React 渲染的，模板里可以根据数据长度计算需要几个占位：

<div class="card-list"> <div class="card" v-for="item in list" :key="item.id">{{ item.name }}</div> <div class="card placeholder" v-for="n in placeholderCount" :key="'ph-' + n"></div> </div>

对应的placeholderCount用计算属性算出来：

computed: { placeholderCount() { const cols = 4; const rest = this.list.length % cols; return rest === 0 ? 0 : cols - rest; } }

占位节点在本节开始时用的样式display: none是不行的，必须让它占位但不能看见：

.card.placeholder { visibility: hidden; height: 0; pointer-events: none; }

给height: 0之后，这一行的align-items默认stretch也无法把它拉伸撑高，所以行高不会变形；真实卡片的高度有多少，行高就有多少，视觉上完全正常。另外visibility: hidden还有一个好处，就是它不会进入无障碍树，对屏幕阅读器友好，不会读出一堆空白节点。

这个方案的优点是不依赖浏览器对现代 CSS 特性的支持，IE 老环境也能跑。缺点是要在模板和脚本里维护一份"占位逻辑"，尤其列数变化时（比如响应式从 4 列变 3 列）计算逻辑得跟着改，很容易漏。

2.3 占位方案的边界条件

用占位元素这个思路，有两个边界条件必须心里有数。

第一个就是前面提到的"行恰好满编"的情况。如果数据总数是 4 的整数倍，此时按公式算出来placeholderCount = 0，模板里不会渲染任何占位节点，一切正常。但如果你图省事，不管三七二十一固定塞几个占位节点在末尾，那每个完整列表底下都会多出一条空行——在有gap的情况下表现为底部多出一段间距。所以占位节点必须是条件渲染的，不能在结构中写死。

第二个边界条件是：列数变化时，占位的数量也要跟着变。桌面端一行 4 个，平板一行 3 个，手机一行 2 个，同一个列表数据量是 7，7 % 4 = 3需要补 1 个占位，但7 % 2 = 1需要补 1 个占位，7 % 3 = 1需要补 2 个占位。如果你的项目里写死了一个列数，响应式断点一调，老问题就回来了。

综合来看，占位方案适合"列数固定、数据由 JS 控制渲染、没有历史包袱"的项目。但凡列数可能变化，我更推荐你直接看下面的 Grid 方案。

3. 方案二：改用 CSS Grid 一劳永逸

3.1 Grid 为什么不会错位

如果你问我现在做这种多列卡片网格，首选什么，我会毫不犹豫回答：CSS Grid。理由很直接——Grid 本身就建立在"行"和"列"的二维网格模型上，它天生知道每一行应该有几个格子。

.card-list { display: grid; grid-template-columns: repeat(4, 1fr); gap: 20px; }

就这三行，搞定。子元素不需要设置任何宽度，1fr会把可用宽度平均分成 4 份，每个卡片占据一格。最后一行只有 3 个卡片时，它们老老实实落在前三格里，第四格是空的。Grid 不会把空着的格子里的空间分配到别的卡片之间，因为间隔是gap决定的，和格子里的内容无关。

用生活类比理解：flex 的space-between像几个合伙人按出资比例瓜分行内剩余利润，人少了每人分更多，于是间距变大；Grid 像电影院划好的座位，座位间距是固定的，最后排空着几个位置，也不会把前面观众的座位间距拉大。

这也是为什么 Grid 的视觉本来就比"flex + space-between"更稳定：它不追求每行两端贴边，而是保证列位置完全对齐。绝大多数卡片网格、后台面板、图标矩阵，用户真正想要的就是这种"每行固定列数、元素左对齐、间距一致"的效果，而不是每行头尾都撑满的两端对齐。

3.2 从 flex 迁移到 grid 的具体改法

迁移其实不复杂，但有几个细节不能忽略。

原来的写法：

.card-list { display: flex; flex-wrap: wrap; justify-content: space-between; gap: 20px; } .card { width: calc(25% - 15px); margin-bottom: 20px; /* 如果以前用 margin 控制行距 */ }

改成 Grid：

.card-list { display: grid; grid-template-columns: repeat(4, 1fr); gap: 20px; } .card { width: auto; margin: 0; }

注意三点。第一，卡片的width一定要去掉，交给 Grid 的列轨道控制，否则会出现卡片宽度撑破或者对不齐的问题。第二，原来用margin-bottom控制行距的，全部删掉，统一用容器上的gap。第三，如果原来卡片通过flex: 1或flex-grow实现自适应拉伸，迁移到 Grid 后这些属性也都不需要了，直接在grid-template-columns里用1fr控制。

还有一个常被忽略的点：Grid 容器上也可以写justify-content: space-between，但它的作用对象是"列轨道"，而不是"子元素"。翻译一下就是：如果你有三列，justify-content: space-between会把三列整体拉开，让第一列贴左、第三列贴右、中间空出多余空间。这通常不是你想要的，尤其是列数不固定的情况下，会产生更大的视觉灾难。所以从 flex 迁到 grid 时，顺手把justify-content去掉，别留着习惯性写法。

3.3 auto-fill、auto-fit 与响应式扩展

Grid 的另一个大杀器是可以用minmax结合auto-fill/auto-fit实现"不写媒体查询的响应式列数"。

.card-list { display: grid; grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); gap: 20px; }

这条规则的意思是：列宽最小 220 像素，能放几列就放几列，多余空间由1fr均分。容器宽、列数自动多，容器窄、列数自动少，完全不需要手动断点。

这里有个经典陷阱：auto-fill和auto-fit看起来都差不多，但行为有区别。auto-fill会保持创建好的轨道数量，哪怕某些轨道里没有元素，空轨道也占位；auto-fit会把空轨道折叠掉，让有内容的轨道占满整个容器宽度。举例子，容器能放 4 列，但内容只有 2 个元素：auto-fill下这 2 个元素分别占第 1 列和第 2 列，右边空着两个虚拟轨道；auto-fit下所有空轨道折叠，2 个元素会被拉伸到占满容器。对卡片列表来说，如果你希望一行不满时元素宽度不变、只是右边留白，用auto-fill；如果你希望元素自动变宽填满容器，用auto-fit。这两者之间的差异，我见过不少同事搞混。

回到最后一行的问题上：Grid 方案最大的价值是"从根上没有这个问题"。不需要占位元素、不需要 JS 计算、不需要考虑行数不满的情况。唯一需要取舍的场景是：你的布局本质不是网格，而是类似导航栏、按钮组这种一行元素的分布，那 Grid 就不太对味了，老老实实用 flex 的那个改良方案更合适。

4. 方案三：flex-start + gap，多数场景的更优解

4.1 直接改两行代码

如果你的项目已经用 flex 写了一大片布局，暂时不想迁移到 Grid，最简单的救命方案是放弃space-between，改用flex-start + gap：

.card-list { display: flex; flex-wrap: wrap; justify-content: flex-start; /* 从 space-between 改到这里 */ gap: 20px; } .card { width: calc(25% - 15px); }

改完之后，每一行所有卡片都从左侧开始排列，卡片之间的间距由gap固定为 20 像素，最后一行不满时，剩余空间直接留在右侧，不会再被分配到间隙里。

这个方案为什么会有效，是因为它绕开了"剩余空间平均分配"的逻辑：flex-start把所有元素堆在行的起始位置，gap负责处理元素之间的固定间隔，剩余空间留在行尾，不参与任何分配。从视觉上看，它和 Grid 版的效果几乎一致，只是实现上仍然依赖元素宽度 + 容器宽度来换行。

这里我多说一句：很多人纠结"space-between 首尾贴边更好看"，但放到真实页面里，两边留出和间隙相同的距离，其实比贴边更协调。电商平台仔细看那些商品列表，几乎没有用space-between让每行头尾贴边的——因为屏幕边缘还需要留白。所以flex-start + gap不仅能解决错位，还顺手把页面呼吸感做出来了。

4.2 宽度计算公式怎么来的

用这个方案最让人困惑的是：为什么gap: 20px时，卡片宽度是calc(25% - 15px)，而不是calc(25% - 20px)？

推导一下。假设一行 4 个卡片，卡片之间总共有 3 个间隙，每个间隙是 20 像素，这 3 个间隙占掉总宽度 60 像素。剩下的宽度要平均分给 4 个卡片，所以每个卡片占(100% - 60px) / 4。拆开算就是100% / 4 - 60px / 4，等于25% - 15px。

验证也很简单：4 个卡片宽度加起来是100% - 60px，加上 3 个 20 像素的间隙，合计正好100%。不多不少。

所以通用的公式是：如果一行要放 N 列、gap为 G，那么每个元素宽度就是calc(100% / N - (N - 1) * G / N)。比如 3 列、gap: 16px，宽度就是calc(33.333% - 10.667px)；2 列、gap: 12px，宽度就是calc(50% - 6px)。记公式容易忘，我自己的习惯是干脆记推导逻辑：先算间隙总共占了多少，剩下的再平均分给 N 列。

还有个容易踩的坑：如果卡片内部有padding或者border，别忘了box-sizing: border-box要设置上，否则宽度算对了，实际渲染出来还是会多出一截。这种问题浏览器控制台往往不报错，但视觉效果就是最后一行时不时超出容器宽度，排查起来很费时间。

4.3 旧浏览器兼容：负 margin 方案

gap在 flex 布局里的支持其实已经非常好了，2021 年之后的主流浏览器都没问题。但如果你手上维护的项目还要兼容特别老的浏览器（或者公司内部定制的老旧内核浏览器），gap可能不支持，这时候可以用经典的"负 margin + 元素 margin"方案。

原理是把间距分散到每个元素自己的 margin 上，再用容器的负 margin 把边缘的间距"吃"回来：

.card-list { display: flex; flex-wrap: wrap; justify-content: flex-start; margin: -10px; /* 补偿边缘 */ } .card { width: calc(25% - 20px); margin: 10px; }

每个卡片四周都有 10 像素的 margin，两两相邻的 margin 叠加成 20 像素的间距，效果等同gap: 20px。容器的margin: -10px是为了让第一个卡片和最后一个卡片的边缘 margin 不把布局撑大，从而和父容器边缘对齐。宽度公式相应变成：calc(25% - 20px)，因为每个卡片左右各 10 像素 margin，要从总宽度里扣掉 20 像素。

这套方案在十年前是响应式卡片布局的标配，Flexbox 的 gap 普及之后已经不太推荐新写，但维护老项目时看到了要知道它是怎么工作的，别把负 margin 当成 bug 顺手删掉。

5. 方案四：JavaScript 动态补齐占位

5.1 核心计算逻辑

前面两种"改 CSS 就能解决"的方案已经覆盖了绝大多数场景。但有一种情况绕不开 JS：列表数据是异步加载的，渲染完成后才能知道总数；同时页面的列数又会随断点变化。这时候可以在数据渲染完成后，用脚本动态往容器末尾追加占位节点，把最后一行填满。

核心逻辑非常简单：

function getPlaceholderCount(total, columns) { const rest = total % columns; return rest === 0 ? 0 : columns - rest; }

比如一行 4 个，数据是 9 个，9 % 4 = 1，还差 3 个补满；数据是 10 个，10 % 4 = 2，还差 2 个；数据是 12 个，余数是 0，一个都不用补。

这个计算本身没有任何坑，真正麻烦的是"什么时机触发"以及"列数变了要重新算"。

5.2 完整代码与触发时机

假设 DOM 结构是这样的：

<div id="cardList" class="card-list"> <!-- 动态渲染的卡片会放在这里 --> </div>

完整脚本：

function syncPlaceholders() { const container = document.getElementById('cardList'); if (!container) return; // 1. 先清掉旧占位节点，避免重复添加 container.querySelectorAll('.card.placeholder') .forEach(el => el.remove()); // 2. 统计真实卡片数量 const realCards = container.querySelectorAll('.card:not(.placeholder)').length; // 3. 根据当前宽度判断列数 const columns = container.clientWidth >= 900 ? 4 : container.clientWidth >= 600 ? 3 : 2; // 4. 需要补几个 const rest = realCards % columns; const need = rest === 0 ? 0 : columns - rest; // 5. 追加占位节点 for (let i = 0; i < need; i++) { const ph = document.createElement('div'); ph.className = 'card placeholder'; ph.setAttribute('aria-hidden', 'true'); container.appendChild(ph); } } // 数据渲染完成后调用一次 syncPlaceholders();

注意几个关键点。第一，追加占位之前必须先把旧占位节点移除，否则接口每次刷新数据，占位节点也会跟着累加，最后一行会多出几个"幽灵卡片"。第二，占位节点的类名要能被统一识别（比如.placeholder），避免和数据卡片混在一起。第三，aria-hidden="true"加上，占位节点本来就不该被辅助技术读到。

如果框架是 React 或者 Vue，其实不用手动操作 DOM，直接在渲染列表时把need当成数据的一部分算好就行，模板里节点数量和类名由框架统一管理，比手动createElement更干净。手动方案主要适合老页面里的原生 JS 操作。

5.3 响应式切换列数时的重算

列数不是固定值时，问题就来了：窗口宽度跨过断点，列数从 4 变成 3，占位数量需要重新计算。这个时候要监听窗口变化。

最省事的写法：

window.addEventListener('resize', () => { syncPlaceholders(); });

但resize事件在拖拽窗口过程中触发频率极高，每次都去操作 DOM 加删节点，性能很差还会引起布局抖动。两个优化方向：一个是防抖，把syncPlaceholders包在定时器里，比如 150 毫秒内只执行一次；另一个是用ResizeObserver监听容器尺寸变化，配合requestAnimationFrame控制执行时机。

const observer = new ResizeObserver(() => { syncPlaceholders(); }); observer.observe(document.getElementById('cardList'));

ResizeObserver比resize监听好在：它监听的是容器本身而不是窗口，容器尺寸变化（不管是窗口变化还是布局变化引起的）都会触发；而且回调的触发时机和布局生命周期绑定得更准确，不容易错位执行。

还有一个细节：如果列数是根据clientWidth判断的，记得把滚动条宽度的影响考虑进去。不同浏览器滚动条占的宽度不一样，用container.clientWidth而不是window.innerWidth作为判断依据，结果更准确。因为这反映的是容器真实可容纳的宽度，而window.innerWidth包含了滚动条和侧边栏，很容易让断点判断失真。

JS 方案是"最终兜底"，不是首选。能靠 CSS 解决的布局问题，尽量不要靠 JS 在渲染后打补丁。但这个方案的价值在于它适配的边界足够广：数据完全动态、列数完全动态、容器宽度从 200 像素到 2000 像素，它都能算出当前该补几个。

6. 选型建议与避坑实录

6.1 四种方案怎么选

把四个方案摆在一起，按场景对号入座：

我的优先级排序是这样的：新写的多列布局直接 Grid，一行到底的简单分布用flex + gap + flex-start，老 flex 项目急着修 bug 就改justify-content: flex-start加gap，只有列数动态且数据异步这种极端情况才上 JS。

还有一个判断维度：你到底是想要"两端对齐"还是"固定列对齐"。如果是菜单、导航、工具栏这种确实需要元素撑满一整行的排列，space-between完全没问题，不需要改造；只有当你明确想要"每行数量固定、列位置对齐"的网格效果时，才需要换方案。我见过不少同事为了修错位问题，把原本适合两端的布局也硬改成网格，结果视觉上反而更空。方案没有绝对好坏，先分清需求再动手。

6.2 我踩过的几个坑

最后把实际操作中遇到的典型问题整理成一份速查清单，这些都是文档里不容易写、但实战一定会碰到的细节。

第一个坑：占位元素用了display: none。display: none会把元素从渲染树里彻底移除，不占任何布局空间，补位直接失效。占位元素要显示隐藏，用visibility: hidden或者干脆用透明背景的普通元素，总之它必须参与 flex 布局。

第二个坑：占位元素造成了底部空白。前面说过，数据恰好是完整行数时，仍然固定的占位节点会自己形成一条空行，在有gap的容器里表现为底部多出 20 像素的间距。排查的时候第一反应往往是"哪个元素有 margin 漏了"，实际上就是占位符造成的。所以占位符必须是条件渲染的，数据满编时一个都别加。

第三个坑：给卡片设置了边框和 padding，却忘了box-sizing: border-box。calc(25% - 15px)这个宽度默认是 content-box 的宽度，一旦内部元素有 padding 或者 border，实际占用的空间就超过计算值，最后一排很容易掉下去换行。这个问题在浏览器里表现还不明显，因为差的几十像素会引发换行，然后在开发工具里看到"元素实际宽度和 CSS 声明不一致"。写这类布局组件时，建议在全局样式里统一设置box-sizing: border-box，一劳永逸。

第四个坑：图片没有固定宽高，加载前后卡片高度变化，占位数跟着错位。商品卡片通常有图片，图片未加载时高度为 0，加载后会撑开卡片。如果页面同时有懒加载和异步占位逻辑，图片加载完成的时间点不一致，会引发两次布局计算，占位数量可能在第一次计算时已经错了。解决方法是给图片容器设置固定的宽高比（比如aspect-ratio: 1或者直接给高度），让卡片在图片加载前后高度不变，渲染顺序稳定，占位计算才不会乱。

第五个坑：高度不一致导致的行高错位。有时候最后一行看上去"错位"，其实根本不是justify-content的问题，而是卡片高度差异太大，导致最后一行和其他行的纵向错开。Flex 默认align-items: stretch，会把同一行的元素拉伸到同一高度，但不同行之间的高度仍然可以不同。Grid 虽然列对齐了，行高也一样逐行独立。真正的解法是把卡片内容也做统一处理——固定图片高度、规范标题行数、让卡片内部用上下结构填充。这个属于布局之外的组件设计问题，但排查时容易被混淆，我一开始也走过弯路。

第六个坑：响应式断点改列数之后忘重算。代码写得再漂亮，如果窗口从 4 列拉到 2 列后占位数量不变，错位马上复发。不管你是用 CSS 占位还是 JS 占位，列数变化是这类问题的隐性地雷。Grid 方案因为列数由grid-template-columns统一管理，天然躲开了这个坑，这也是我再三推荐新项目用 Grid 的原因。

6.3 最后的经验总结（划重点）

做前端这几年，凡是遇到布局错位，我现在的排查第一步都是先问：这是不是"一维布局处理二维场景"导致的？Flex 本质上是一维的排版模型，它的核心设计目标是"在一行内分配空间"，而不是"保证二维网格对齐"。当你发现自己在用 placeholder、hack、::after去帮 flex 圆一个"网格"的场，这通常是一个信号：你可能选错了布局模型。

占位元素不是不能用，它确实是修复历史项目最快的手段，改个模板加个visibility: hidden的节点就完事。但如果你现在是在写新页面、换新组件，我强烈建议直接用 Grid。写三行display: grid; grid-template-columns: repeat(4, 1fr); gap: 20px;，配上minmax做响应式，你想让最后一行错位都难。

最后再分享一个实用习惯：我会在提交代码前专门做一次"边界数据测试"，把列表数据改成 1、N-1、N、N+1 四种情况分别看一眼效果。1检查单个元素的极端表现，N-1检查最后一行缺 1 个，N检查满编，N+1检查多出来的一个是否正常换行。这四个数字跑完，大部分space-between类布局问题都会现出原形，比上线后被用户截图吐槽要体面得多。