一维布局应优先选用Flexbox而非Grid。Grid语法冗余、意图模糊，缺乏流式回流能力，gap与对齐行为易失控，响应式维护成本高，order属性不直观，且在Safari等环境下稳定性差。
Grid用在一维场景时语法冗余、意图模糊
Grid本质是容器驱动的二维结构，哪怕只排一行，也得先定义grid-template-columns或grid-template-rows，再手动把每个子项塞进轨道。Flexbox直接display: flex + justify-content就完事，语义清晰、代码量少。常见翻车点：有人写grid-template-columns: 1fr 1fr 1fr排三个按钮，结果发现中间按钮文字变长后整体错位——因为Grid默认不自动伸缩内容，而Flex的flex: 1天然响应内容变化。
Grid的gap和对齐行为在单行中容易失控
Flexbox的gap只作用于主轴方向，justify-content和align-items职责分明；Grid的gap是二维的，justify-items和align-items又容易和容器级的justify-content混淆。典型错误现象：
- 给Grid容器设
gap: 1rem，结果下拉菜单的<ul>被当成子项，意外继承间隙，导致悬停位置偏移 - 想右对齐一个图标，写
grid-column: -1，但在Safari里不渲染或错位——因为Grid依赖显式轨道编号，而Flex用margin-left: auto或justify-content: space-between更稳定
Grid在一维响应式中媒体查询更难维护
Flexbox靠flex-wrap + flex-direction切换单行/多列，一套逻辑覆盖移动端到桌面端；Grid要改grid-template-columns的repeat()参数，还得同步调整grid-column定位，稍有遗漏就错位。实测显示，相同导航栏布局，Grid方案平均比Flexbox多写40%的媒体查询代码。尤其当你要支持折叠菜单+横向快捷入口混合结构时，Grid的二维轨道定义反而成了负担——它不是不能做，而是没必要为一维问题引入二维约束。
Grid子项的order属性不如Flexbox自然
Flexbox的order是线性序号，0→1→2依次排列，直观易懂；Grid的order在二维环境下意义模糊，且受grid-row/grid-column优先级影响。更关键的是：Grid没有“流式回流”概念，一旦某个子项被指定grid-column: 2，它就固定在第二列，不会像Flexbox那样随兄弟元素增减自动重排。这导致动态插入/删除DOM时，Grid布局更容易出现视觉断裂，而Flexbox天然适应内容增减。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是：Grid的minmax()和auto-fill虽能模拟Flex行为，但底层仍是轨道计算，遇到Safari中vh失真或滚动锚定等边界情况，表现反而不如Flexbox稳定。一维问题，别强加二维框架。 
