一维布局用 flex，二维布局用 grid，真实项目中应组合使用：grid 定页面骨架，flex 调区块内细节。二者各司其职，强行二选一反而降低可维护性与兼容性。
一维排列就用 display: flex，别硬套 grid
只要元素只在行或列一个方向上排布，display: flex 就是更直接、更轻量的解法。比如导航栏横向对齐、表单字段垂直堆叠、按钮组右对齐，两行 CSS 就能搞定：justify-content: space-between + align-items: center。
常见错误现象：.nav 用 display: grid 实现水平菜单，结果写一堆 grid-template-columns: 1fr auto 1fr，还因为 Safari 老版本不支持 gap 导致间距错位；或者给纯竖排侧边栏加 grid，却只设 grid-template-rows: 1fr，属性冗余且难调试。
- 响应式换行卡片列表：用
flex-wrap: wrap+flex-basis: 280px比grid-auto-flow: dense更语义清晰、性能更好 - 移动端横转竖：改
flex-direction: column即可，不用删掉display: flex重写整套规则 - IE11 兜底需求下，
flex是唯一稳定选择——grid在 IE11 中仅支持旧语法，且gap、auto-fit等关键特性完全不可用
二维结构必须用 display: grid，别靠嵌套 flex 硬凑
一旦布局同时涉及“第几行第几列”“跨几行几列”“固定区域划分”，比如页头+侧边栏+主内容+页脚，或商品卡片需等宽列+自动列数+每行高度一致，display: grid 就是唯一干净解法。
典型翻车场景：外层用 grid 分三栏，其中一栏里再套 grid 排按钮组，父级 gap 和子级 gap 叠加错位，调试时根本找不到源头。
立即学习“前端免费学习笔记（深入）”；
-
grid-template-areas可视化定义区域，HTML 结构不用为视觉顺序妥协，例如："header header" "sidebar main" "footer footer" -
minmax(250px, 1fr)+auto-fit一行搞定响应式卡片列数，无需堆砌媒体查询 - 避免三层及以上
grid嵌套；超过两层就该拆成grid定骨架 +flex调细节
真实项目基本都是 grid 定骨架 + flex 调细节
90% 的合理布局是组合态：grid 控制页面级容器划分，flex 处理每个区块内部的对齐与伸缩。强行二选一，等于拿螺丝刀拧螺母——不是工具不行，是用错了地方。
仪表盘场景：.dashboard 用 grid 划分「图表区」「指标卡区」「筛选栏」；每个「指标卡」内部用 flex 垂直居中图标+文字+数值。
- 响应式图库：
.gallery用grid实现等宽列+自动列数；每张图片卡片用flex居中标题和操作按钮 - 侧边栏菜单垂直排列 →
flex-direction: column - 主内容区分左右栏，每栏内文字图片上下堆叠 → 外层
grid分栏，内层各用flex排内容
容易被忽略的兼容性与嵌套复杂度约束
兼容性和嵌套深度不是理论问题，而是上线后真会出错的点。Safari 14.0 之前 grid-gap 有偏移 bug，iOS 14.5+ 才稳定支持 flex-gap；而 grid 的 minmax()、auto-fit 在 IE11 中完全不可用，只能退回媒体查询 + 固定列数方案。
嵌套也一样：flex 嵌套两层很常见，逻辑隔离清晰；grid 嵌套超过两层就容易失控，每个子容器都得重新定义 grid-template-areas，父子间无继承关系。
别在同一个元素上反复切换 display：PC 端用 grid 做三栏，移动端想堆叠？直接在 @media 里把 display: grid 改成 display: flex，容易引发 Safari 渲染抖动，某些旧版 Android WebView 还会忽略媒体查询里的 grid 声明。
