gap在旧版浏览器（如Safari 14.1前、IE）中不支持，负margin是兼容性兜底方案；需配合父容器负margin抵消外溢，并用:nth-child伪类清除每行末项多余间距。
flex布局里gap不生效，为什么还用负margin？
因为gap在旧版浏览器（如 Safari 14.1 之前、IE 完全不支持）中不可用，而项目常需兼容 iOS 14 或微信内置浏览器等场景。负 margin 是绕过 gap 兼容性问题的成熟兜底方案，不是“过时技巧”，而是有明确 fallback 需求的工程选择。
常见错误现象：gap: 12px 写了但子项紧贴、间距消失；检查浏览器版本后发现是 Safari 14 或更低；此时不能只改写 CSS，得同步补负 margin 逻辑。
- 父容器设
display: flex+flex-wrap: wrap - 子项加
margin-right和margin-bottom（值 = 期望间距） - 父容器加等量负
margin-right和margin-bottom抵消首行/首列外溢 - 最后一行子项的
margin-bottom会多出空白，需用伪类或 JS 清除（见下一条）
最后一行子项底部多出多余间距怎么清？
负 margin 方案下，每行末尾子项的 margin-bottom 没有被后续元素抵消，导致容器底部空出一格。这不是 bug，是负 margin 布局固有副作用。
最轻量解法是用 CSS 伪类精准定位：对每行最后一个子项取消 margin-bottom。前提是子项能被 CSS 选中——即必须知道每行几个元素。
立即学习“前端免费学习笔记（深入）”；
- 若每行固定 3 列，用
:nth-child(3n)+margin-bottom: 0 - 若响应式断点变化列数（如 4→2→1），需配合媒体查询重置伪类规则
- 避免用
:last-child，它只匹配整个列表最后一个，不是每行最后一个 - JS 动态计算并打 class 是备选，但增加运行时开销，仅当列数完全不规则时考虑
flex-wrap + 负margin 的性能和渲染风险
这套组合没有重排（reflow）风险，但存在两个容易被忽略的渲染细节：
- 父容器负 margin 可能导致内容被裁切，尤其配合
overflow: hidden时，需确保父容器有足够内边距或用clip-path替代 - 子项的
margin在 flex 主轴方向（row 时为margin-right）可能干扰justify-content: space-between的计算，二者不要混用 - 当子项宽高含百分比或
flex-grow时，负 margin 不影响伸缩逻辑，但视觉上可能让“等宽”错觉失效——建议子项用固定宽度或flex: 0 0 calc(...)显式控制
现代项目还该用这套方案吗？
如果目标浏览器明确支持 gap（Chrome 84+、Firefox 63+、Safari 14.1+、Edge 88+），且无需兼容微信 X5 内核（仍广泛使用旧 Safari WebKit），那直接用 gap 更干净。但只要有一个真实用户场景卡在 Safari 14 或 iOS 14.4，负 margin 就不是“要不要用”，而是“怎么安全接入”。
真正容易被忽略的是：负 margin 方案和 gap 并非二选一，可以用 @supports (gap: 0) 做渐进增强，把负 margin 当作降级后备——而不是全量回退。
