当只需在一维方向（行或列）内对齐、间距、排序或伸缩元素时，应选 display: flex；它轻量直接，适用于导航栏、表单控件、卡片内垂直居中等单轴布局，而 display: grid 专用于需同时控制行列、跨格定位及区域重组的二维场景。
什么时候该用 display: flex 而不是 display: grid
当你只关心一行或一列内元素的对齐、间距、顺序或伸缩行为时，display: flex 是更轻量、更直接的选择。比如导航栏菜单项水平铺开、卡片内按钮垂直居中、表单控件左右对齐——这些都属于一维空间调度。
常见错误现象：justify-content 和 align-items 在 display: grid 容器里也能用，但它们只影响整个网格容器的“内容对齐”，而不是单个网格项的位置；误以为设了这两个属性就能像 Flex 一样控制子项，结果发现子项根本不移动。
- Flex 容器默认不定义轨道，子项按内容流自动排列；Grid 容器必须先声明
grid-template-columns或grid-template-rows，否则所有子项会叠在左上角 - Flex 的
flex-wrap: wrap可让子项换行，但换行后每行仍是独立主轴，无法强制列对齐（比如第二行第一个项和第一行第一个项不对齐） - 移动端小屏下，用
flex-direction: column切换布局方向比 Grid 重写grid-template-areas更快
什么时候必须用 display: grid
当你需要同时约束行和列、让元素跨行跨列、或提前规划出固定结构（比如页眉/侧边栏/主内容/页脚的二维位置），display: grid 不是“可选”，而是唯一合理解。
典型场景：仪表盘卡片网格、图片画廊（不同尺寸图卡需错落排布）、带固定侧边栏的响应式文章页、复杂表单分区域对齐（label 和 input 必须严格对齐到同一列）。
立即学习“前端免费学习笔记（深入）”；
-
grid-template-areas配合媒体查询切换布局结构，比 Flex 多层嵌套更易读、更易维护 - Grid 的
gap是原生行列间距，而 Flex 的gap直到 2021 年才被广泛支持，旧版 Safari 需用margin模拟，容易漏掉最后一项 - Grid 的
auto-fit+minmax()能实现真正响应式的等宽列（如grid-template-columns: repeat(auto-fit, minmax(250px, 1fr))），Flex 用flex-basis模拟时需额外处理换行边界
为什么不能只学一个？
实际项目里，90% 的响应式页面是 Grid 和 Flex 混合使用的：用 Grid 搭骨架，用 Flex 填细节。
比如一个新闻首页，用 Grid 划分 header / sidebar / main / footer 四个区域；但在 main 区域内部，用 Flex 排列每篇文章的标题、摘要、标签；在 sidebar 里，又用 Flex 对齐图标和文字。
- 不要把 Grid 当成 Flex 的“升级版”——它解决的是不同维度的问题；就像锤子和螺丝刀，不是谁更好，而是拧螺丝时锤子没用
- 过度使用 Grid 会导致容器嵌套过深、CSS 冗余（比如给每个卡片都写
grid-column），反而降低可维护性 - Flex 的
order属性能改变渲染顺序而不改 HTML，这对无障碍和 SEO 很关键；Grid 的grid-area也能做到，但语义不如order明确
兼容性与上线前必须检查的点
现在（2026 年）绝大多数项目已无需为 IE 兼容妥协，但仍有三个容易被忽略的兼容细节：
- 旧版 Safari（≤14.1）不支持
gap在 Flex 容器中生效，但支持 Grid 的gap；如果用了display: flex+gap，得加margin回退 - Android WebView ≤75 对
grid-template-areas的字符串换行支持不稳定，建议写成单行（如"header header" "nav main" "footer footer"） - 某些邮件客户端（如 Outlook Desktop）完全不解析 Flex/Grid，纯 HTML 表格仍是唯一可靠方案——别在邮件模板里尝试任何现代布局
真正难的从来不是语法本身，而是判断某个布局问题到底是一维还是二维的。多看真实 DOM 结构，少凭直觉猜——把草图画出来，标出哪些线必须对齐、哪些块要跨区域，答案自然就清晰了。
