Flex在100+动态列表中渲染更快，因其仅需维护一维主轴顺序与尺寸变化，避免Grid所需的二维网格线映射、轨道重算及gap重分配等高开销操作。
Flex布局在100+动态列表中渲染更快的底层原因
不是“Flex天生快”，而是它在处理大量动态插入/删除的列表项时，浏览器重排（reflow）和重绘（repaint）开销更低。Grid需要维护完整的二维网格线映射关系，而Flex只追踪一维主轴上的顺序和尺寸变化。
Grid在动态列表中触发更多layout thrashing的典型场景
当你用grid-template-columns: repeat(auto-fill, minmax(200px, 1fr))构建响应式卡片墙，并频繁appendChild或removeChild时，浏览器必须：
- 重新计算所有网格轨道（rows/columns）的尺寸和位置
- 更新每个
grid-area的坐标映射（即使没显式设置） - 同步更新
grid-gap引起的间隙重分配
这些操作在Chrome DevTools的Performance面板里会表现为高频率的Layout阶段耗时，尤其在低端设备上明显卡顿。
Flex实现同等效果时更轻量的写法
对纯横向滚动或垂直流式列表，用Flex替代Grid能规避大部分二维计算：
立即学习“前端免费学习笔记（深入）”；
.list {
display: flex;
flex-direction: column; /* 或 row */
flex-wrap: wrap; /* 需要换行时才启用 */
gap: 12px; /* Chrome 104+ 支持，无需 margin 模拟 */
}
.item {
flex: 0 0 auto; /* 禁止伸缩，保持原始尺寸 */
width: 200px; /* 固定宽度，避免 flex-basis 计算 */
}关键点：
-
flex-wrap: wrap比grid-template-columns更少依赖容器宽高测量 - 不设
flex-grow可彻底关闭弹性计算，仅做排列 -
gap在Flex中是独立布局属性，不参与轨道计算
容易被忽略的兼容性陷阱
看似简单的gap在Flex中仍有坑：
- Firefox 63–100 对
flex-direction: column+gap支持不稳定，可能漏掉垂直间距 - Safari 14.1–16.4 在
flex-wrap: wrap下gap会错误地影响最后一行对齐 - 若需IE11兼容，
gap必须降级为margin，且需用:nth-child清除末尾边距
真正影响性能的从来不是语法本身，而是浏览器引擎如何把你的CSS声明翻译成渲染树节点——Grid的二维抽象层比Flex的一维流式模型多了至少一个数量级的状态维护成本。
