一维布局优先用flex，二维布局必须用grid；二者应协作而非互斥，外层grid框架内嵌flex子区域，需根据布局维度本质选择技术。
一维布局用 flex 更直接，别硬套 grid
处理单行或单列的对齐、分布、顺序调整（比如导航栏、按钮组、卡片列表），flex 的语义清晰、API 简洁。它天生为一维流式内容设计，justify-content、align-items、flex-wrap 几个属性就能覆盖绝大多数需求。
常见错误是看到“需要居中”就下意识写 display: grid，结果多出不必要的网格容器层级，还容易因 grid-template-columns 默认值导致意外换行或空白。
-
flex的flex-direction切换主轴方向成本低，row/column互换不改变结构逻辑 - 响应式中用
@media切换flex-direction比重写grid-template-areas更轻量 -
flex: 1自动撑满剩余空间的行为，在grid中需配合fr单位 + 显式轨道定义，多一层心智负担
二维结构必须用 grid，flex 强撑会失控
当布局同时涉及行和列的精确控制——比如仪表盘、图文混排的响应式文章、表单字段与标签对齐、带固定侧边栏+自适应主内容的页面框架——grid 是唯一合理选择。此时 flex 需要嵌套多层容器，每个子项还要手动设 width 或 flex-basis，维护性急剧下降。
典型翻车场景：用 flex 做三栏布局，中间栏加了 flex: 1，但右侧栏内容变长后把中间栏挤变形；或者用 flex-wrap 模拟网格，却无法让第 4 个子项自动落到第二行第一列。
立即学习“前端免费学习笔记（深入）”；
-
grid-template-areas让布局意图一目了然，比一堆flex嵌套更易读 -
grid-column/grid-row可跨格，flex完全不具备这种二维定位能力 - 媒体查询中修改
grid-template-columns即可整体切换布局形态，不用动 HTML 结构
flex 和 grid 不是互斥，而是协作关系
真实项目里，grid 常作为外层页面框架（如 header/main/aside 分区），而每个区域内再用 flex 处理内部元素排列（如 header 里的 logo + nav + search）。强行让一个技术承担全部职责，反而增加复杂度。
容易忽略的细节是：在 grid 容器内，其直接子项是网格项，不再受父级 flex 属性影响；反过来，flex 容器的子项也不会响应 grid 相关属性。嵌套时层级责任必须分清。
- 不要给
grid容器设flex相关属性（如justify-content），它们无效 -
grid项可以自己设display: flex，这是合法且常见的组合 - 避免在
flex容器里对子项用grid-column—— 浏览器直接忽略
移动端适配时，flex 的兼容性仍略胜一筹
虽然现代浏览器对 grid 支持已很完善，但在一些旧版 Android Webview（如 4.4.x）或 iOS 9 Safari 中，grid 的部分特性（如 gap、subgrid）存在 bug 或缺失。如果项目还需兼容这些环境，关键的一维交互区域（如 Tab 栏、轮播指示器）优先用 flex 更稳妥。
不过，只要目标环境明确支持 display: grid（Chrome 57+/Firefox 52+/Safari 10.1+），二维布局就该无条件选它。纠结“哪个更好”不如先问：“这个布局到底是几维的？”
真正难的不是选 flex 还是 grid，而是识别出哪些地方表面像一维、实际需要二维约束——比如一个“横向滚动的卡片组”，看似 flex 就够，但如果要求卡片高度严格对齐、换行后首行左对齐、末行右对齐，那就得上 grid 配合 auto-fit 和 minmax 了。
