一维布局用flexbox，二维布局用grid；flex适合单向排列与响应式换行，grid适合行列交织的复杂结构；实际项目应按内容流向、结构耦合度及嵌套容忍度决策。
判断布局维度：一维还是二维
关键看你要控制的方向数量。如果只在行或列一个方向上排布元素，比如导航链接横排、按钮组对齐、卡片纵向堆叠，flexbox是自然选择；如果必须同时指定某元素在第几行第几列、跨几行几列、或者整体页面要划分为“侧边栏+主内容+广告位”这种行列交织的结构，grid才是正解。
常见错误现象：display: flex套三层容器强行模拟三栏+两行表格，结果加个@media就错位；反过来用grid排纯横向菜单，写grid-template-rows: 1fr却只有一行，属性冗余还难调试。
- 导航栏、表单控件、垂直居中、响应式换行卡片 →
flexbox - 仪表盘、图文混排画廊、带固定区域的后台首页 →
grid - 想让“前三个左对齐，最后一个右对齐” →
margin-left: auto比justify-self: end更直接
响应式换行需求别急着切Grid
flex-wrap: wrap配合flex-basis能覆盖绝大多数卡片流场景，比如宽度固定为280px的卡片，在容器缩小时自动折行，代码简洁且性能好。而grid的grid-auto-flow: dense虽能填空，但语义模糊，维护时容易搞不清哪个轨道被谁占了。
性能影响明显：子项超50个时，频繁resize下flex-wrap的重排开销远低于grid的二维轨道重算。
立即学习“前端免费学习笔记（深入）”；
- 卡片宽度固定、需自动换行 → 用
flex-wrap - 需要“第一行3列、第二行2列、第三行4列”这种不规则分布 → 才该考虑
grid-column手动定位 - 移动端把横排菜单改成竖排 → 改
flex-direction: column，别删掉display: flex重写
兼容性与嵌套复杂度的实际约束
IE11必须支持？flexbox兼容性远好于grid——IE11的grid是旧语法，且不支持gap。嵌套也一样：flex嵌套两层很常见，逻辑隔离清晰；grid嵌套超过两层就容易失控，每个子容器都得重新定义grid-template-areas，父子间无继承关系。
典型翻车场景：外层用grid分三栏，其中一栏里再套grid排按钮组，结果父级gap和子级gap叠加错位，调试时找不到源头。
- 侧边栏菜单垂直排列 →
flex-direction: column - 主内容区要分左右栏，每栏内文字图片上下堆叠 → 外层
grid分栏，内层各用flexbox排内容 - 避免三层及以上
grid嵌套；超过两层就该拆成grid+flex组合
别在同一个元素上反复切换display
PC端用grid做三栏，移动端想堆叠？直接在@media里把display: grid改成display: flex，容易引发Safari渲染抖动，某些旧版Android WebView还会忽略媒体查询里的grid切换。
真正的问题不在CSS，而在HTML结构是否承载了语义变化。比如移动端需要隐藏侧边栏并把内容流式堆叠，那就该用类名控制DOM结构，CSS只负责样式适配，而不是靠display硬切。
- 用
@supports (display: grid)做降级，而不是依赖@media来回切display -
grid-template-areas可在媒体查询中完整重定义，比切换display更可控 - 复杂响应式布局中，
grid定骨架、flexbox填内容，分工明确才不容易翻车
grid时，不如停下来问问：这里是不是其实只需要flex？ 
