二维布局需求出现时应优先用 display: grid，因其天然支持行列控制、跨行跨列、网格模板和区域声明；一维线性排列则用 flex 更轻量高效。
什么时候该用 display: grid 而不是 display: flex
二维布局需求出现时，grid 是更自然的选择。比如需要同时控制行和列的对齐、跨行跨列、固定轨道尺寸或响应式网格模板，flex 就得靠嵌套多层容器来模拟，代码变深、可维护性下降。
常见场景包括：仪表盘卡片布局、图片画廊（每行 3 列 + 响应式断点）、表单字段与标签对齐（左列标签/右列输入框）、带侧边栏的主内容区（grid-template-areas 直观声明区域）。
-
grid的grid-template-columns和grid-template-rows能一次性定义行列结构；flex只能沿主轴排列，交叉轴对齐能力有限 - 跨行跨列必须用
grid-row/grid-column；flex没有等效机制 - 当子元素顺序需与 DOM 顺序解耦（如用
grid-area重排），grid支持；flex的order只影响一维顺序
什么时候 flex 更合适
一维线性排列是 flex 的核心优势。它在内容流中动态分配空间、处理不等高项目、对齐单行/单列内容时更轻量、语义更清晰。
典型用例：导航栏菜单项水平居中、按钮组右对齐、卡片内头像+文字垂直居中、表单提交按钮与取消按钮并排且右侧对齐。
立即学习“前端免费学习笔记（深入）”；
-
flex的flex-grow/flex-shrink对内容长度不确定的场景适应性更强（比如文本长度不一的标签） - 对齐行为更“流动”：例如
align-items: center垂直居中无需知道父容器高度，而grid中若未设height或min-height，可能无效果 - 旧版浏览器兼容性更好：IE10+ 支持
flex（需前缀），但grid在 IE 中仅支持过时的旧语法，实际不可靠
别混用，但可以嵌套
把 grid 当布局骨架，把 flex 当组件内对齐工具，是成熟项目的常见模式。强行让某一种承担全部职责，反而增加复杂度。
例如一个 grid 容器划分出 header / sidebar / main 区域，其中 header 内部用 flex 排列 logo、搜索框、用户头像；main 里的每张卡片又用 flex 实现图标+文字垂直居中。
- 避免在
grid容器上再设flex—— 属性会冲突，display只能有一个值 - 不要为“看起来像网格”而硬套
flex：比如用flex-wrap+flex-basis模拟三列，不如直接用grid-template-columns: repeat(3, 1fr) - 注意
flex的min-width: auto默认行为，在小屏下可能导致溢出；grid的minmax(0, 1fr)可显式允许收缩，这点容易被忽略
性能与可调试性差异
两者在现代浏览器中渲染性能差异极小，真正影响体验的是开发时的理解成本和调试效率。
grid 的开发者工具支持更直观：Firefox 和 Chrome 都能在检查器中叠加网格线，鼠标悬停显示轨道名、区域名；flex 则主要靠计算主轴剩余空间，调试时需反复切换查看 computed 样式。
- 使用
grid时，忘记设置grid-template-areas或grid-template-columns会导致所有子项堆叠在左上角，错误不报错但布局完全失效 -
flex的常见陷阱是父容器没设height却依赖align-items: center垂直居中，结果毫无反应——因为交叉轴尺寸为 0 - 响应式切换时，
grid可通过@container或媒体查询重写整个模板；flex往往要调整多个flex相关属性，易漏项
.dashboard {
display: grid;
grid-template-areas:
"header header"
"sidebar main";
grid-template-columns: 240px 1fr;
height: 100vh;
}
<p>.header { grid-area: header; }
.sidebar { grid-area: sidebar; }
.main { grid-area: main; }</p><p>/<em> 内部仍可用 flex </em>/
.header {
display: flex;
justify-content: space-between;
align-items: center;
padding: 0 1rem;
}真正难的不是语法，是判断「这个区域到底需不需要二维控制」。多数人一开始会低估 grid 的适用范围，或者高估 flex 的伸缩能力——多看几眼设计稿里的行列关系，比查文档更快找到答案。
