必须切换flex-direction，因row在窄屏会压缩溢出，column则天然垂直堆叠、结构清晰；桌面端用row配合justify-content布局，移动端切column以支持汉堡菜单，且需媒体查询彻底分离、避免层叠冲突。
flex-direction在桌面端和移动端为何必须切换
因为 flex-direction: row（默认）只适合水平空间充足时展开菜单，一旦容器宽度不足，项目就会被强行压缩、文字换行或溢出；而 flex-direction: column 能天然规避宽度计算问题，让菜单项垂直堆叠，结构清晰且无需额外处理折行逻辑。不切换方向，仅靠 flex-wrap: wrap 容易在中等屏幕（如 iPad 横屏）出现两行错位、对齐失衡或高度突变。
- 桌面端保持
flex-direction: row，配合justify-content: space-between或flex-end控制 logo 与菜单的分布 - 移动端必须切为
flex-direction: column，否则无法可靠收起为汉堡菜单形态 - 切勿在同一个规则里同时写
row和column—— 媒体查询要彻底分离，避免层叠冲突 - 若导航容器内嵌了搜索框或用户头像等非链接元素，
column模式下它们会自然垂直排列，比强行用margin-left: auto挤到右侧更稳定
media-queries断点值怎么定才不白写
写死 @media (max-width: 768px) 是最常见却最危险的做法。真实断点取决于你的导航文字长度、图标尺寸、padding 设置——比如 5 个汉字菜单项 + logo，在 540px 宽度下就已开始挤压，这时 768px 的断点根本没生效，用户看到的是重叠文字或横向滚动条。
- 打开浏览器 DevTools，用响应式模式拖动窗口宽度，观察导航何时首次出现换行、文字截断或图标错位，记下那个像素值
- 优先使用
max-width（而非min-width），符合“移动优先”逻辑，也避免大屏样式意外覆盖小屏 - 一个导航栏通常只需 1 个有效断点：比如
@media (max-width: 560px)，足够区分手机与平板以上设备 - 慎用
em或rem断点（如48em），除非你明确控制了根字体大小；否则缩放或系统设置会干扰实际触发时机
汉堡菜单展开后为什么看不见或位置偏移
纯靠 flex-direction: column 不等于菜单就能正确弹出。它只是布局方向，显示/隐藏、定位、层级都得单独处理。常见现象是点击按钮后菜单“闪一下就消失”，或卡在页面顶部/左侧外不可见区域。
-
.nav-menu在移动端初始状态必须设position: absolute+top: 100%（相对父nav定位），不能依赖文档流自然撑开 - 展开时仅改
display: flex不够，还要确保z-index: 1000，否则可能被 header 或 banner 盖住 - 别用
transform: translateY(-100%)隐藏菜单——屏幕阅读器仍会读取，且动画结束后焦点管理失效 - 如果菜单高度不固定，用
max-height: 0+overflow: hidden过渡，比height: 0更可靠（height: auto无法 CSS 动画）
为什么 Safari 下 flex-direction 切换后菜单错位
iOS Safari（尤其是 14–15 版本）对嵌套 flex 容器中 flex-direction 变更的重排计算有延迟或偏差，典型表现是：切换断点后，菜单项突然左偏、图标下沉、或整体高度塌陷。
- 给导航容器（如
.nav）显式加flex-shrink: 0，阻止 Safari 错误压缩整个 flex 容器 - 所有菜单项（
.nav-link）加上min-width: max-content或具体值（如min-width: 80px），防止文字被强制截断或换行 - 避免在
.nav上同时设width: 100%和max-width，Safari 对盒模型的解析容易在此处出错 - 测试必须覆盖 320px（iPhone SE）、480px（老款 iPhone）、560px（主流安卓小屏）三个窄宽，不能只看 768px
flex-direction 切换只是表象，背后牵扯定位方式、可访问性属性（aria-expanded）、键盘焦点闭环，以及 Safari 对 min-width 和 flex-shrink 的特殊解析。漏掉任一环，视觉上可能“看起来能用”，但实际在弱网、缩放、辅助工具场景下立刻失效。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
