移动端卡片布局该用 Grid 还是 Flex？先看结论
做固定列数的卡片网格（比如 2 列或 3 列），display: grid 更稳、更直；做内容高度不一且需自动换行的简单横排（比如底部导航、按钮组），display: flex 更轻、更省计算。别硬套 Flex 做多列——它不是为这个设计的。
为什么 Flex 在卡片网格中容易错行
Flexbox 是一维模型，所谓“两列”其实是靠每个子项设 flex: 0 0 50% 或 width: calc(50% - 8px) 挤出来的。但实际宽度受 padding、border、字体渲染差异影响，尤其在小屏上：
-
box-sizing: border-box没加，内边距直接撑破 50% 宽度 - Safari 对
calc(50% - 4.5px)这类小数像素四舍五入不稳定，偶发第三项被挤到下一行 - 父容器有
padding，而子项没用margin补偿，总宽超 100% - 内容高度不一致时，
flex-wrap: wrap只保证“换行”，不保证“对齐列底边”，视觉上像错位
Grid 做卡片网格的实操要点
用 Grid 不等于无脑写 repeat(auto-fit, minmax(...))——那在低端安卓机上 Layout 耗时能翻倍。真正适合移动端的写法是收敛约束：
- 列数固定优先：
grid-template-columns: repeat(2, 1fr)（2 列）或repeat(3, 1fr)（3 列） - 响应式只在关键断点切列数，例如
@media (min-width: 768px) { grid-template-columns: repeat(3, 1fr); } - 必须加
gap，别用margin模拟间距——gap不影响子项盒模型计算 - 防塌陷加
grid-auto-rows: minmax(100px, auto)，避免空内容卡片高度为 0 - 绝对不要混用
fr和固定像素列（如1fr 200px），小屏下极易触发横向滚动
性能差异在哪？不是“能不能用”，而是“怎么控”
现代 iOS Safari（16.4+）和 Android Chrome（110+）对 display: grid 渲染已 GPU 加速，滚动不掉帧。但 Layout 计算仍在主线程，二维约束求解比 Flex 高 15–30%：
立即学习“前端免费学习笔记（深入）”；
-
repeat(auto-fit, minmax(120px, 1fr))：每次 resize 都重算所有列宽，Layout 耗时从 ~4.8ms 升至 ~9.7ms（Pixel 4a 实测） - 嵌套 Grid（外层 grid + 每个卡片内再 grid）：Layout 时间翻倍，Chrome DevTools 显示 Layout 树深度激增
- 大量
grid-area命名区域（>10 个）：CSSOM 解析开销线性增长 - 若必须用复杂 Grid，加
contain: layout可压至 ~5.5ms，但前提是子项不跨格、不依赖外部尺寸
真正容易被忽略的是：Grid 的“自由度”越低，性能越稳。写死列数、禁用 auto-fit、少用命名区域，不是退化，而是面向移动端的真实取舍。
