子菜单对不齐一级菜单项，根本原因是未给一级菜单项设position: relative导致子菜单相对body定位，或left: 0硬对齐但一级项宽度不均；应确保每个.menu-item设relative，子菜单用left: 50%+transform: translateX(-50%)居中。
子菜单为什么总对不齐一级菜单项？
不是 justify-content 没用，而是它只管 flex 主轴，而子菜单通常用 position: absolute 脱离文档流——它的定位基准是父级的 position: relative 容器，和父容器的 flex 排列逻辑无关。
常见错误现象包括：子菜单左边缘悬空、右侧溢出、或随一级项宽度变化而偏移。根本原因是没给一级菜单项设 position: relative，导致子菜单相对 body 定位；或者用了 left: 0 硬对齐，但一级项本身宽度不均（比如文字长短不一）。
- 确保每个带子菜单的
.menu-item都有position: relative - 子菜单用
left: 50%+transform: translateX(-50%)实现水平居中（前提是父项已设相对定位） - 若一级项是 flex 布局且宽度动态（如
flex: 1），纯 CSS 居中可能失效，此时需用 JS 的getBoundingClientRect()动态计算中心点
二级菜单横向排列时内容被压缩或换行异常
当子菜单内是横向按钮组（比如“编辑｜删除｜分享”），直接套用父级 flex 容器的样式容易出问题：flex 默认会压缩子项、min-width 不生效、white-space 被继承导致意外换行。
关键不是加 flex-wrap: wrap，而是先阻止压缩、再控制换行边界：
立即学习“前端免费学习笔记（深入）”；
- 给子菜单容器设
min-width: max-content（比min-width: 100%更可靠，尤其父项有 padding 时） - 内部按钮用
white-space: nowrap防止文字折行 - 若按钮过多需换行，加
flex-wrap: wrap并配width: fit-content，避免整行撑满后留白 - 避免对子菜单设
width: 100%——它会继承父ul的 padding，实际宽度 > 100%
:hover 触发时菜单闪退或点不到
这不是浏览器 bug，是热区断裂的物理问题：一级项和子菜单之间存在像素级间隙（哪怕只有 1px），鼠标移出时触发 :hover 离开，子菜单立刻 display: none，用户根本来不及移入。
加 transition-delay 是掩耳盗铃，真正要做的，是把“可 hover 区域”连成一片：
- 子菜单设
top: 100%+margin-top: 0，确保紧贴一级项底部 - 如果一级项用了
gap或上下 margin 分隔，把这部分距离挪到子菜单的top偏移里（例如top: calc(100% + 8px)），而不是留白 - 更鲁棒的做法：给一级项加
padding-bottom: 20px（透明区域），扩大 hover 热区，不影响视觉
iOS Safari 中子菜单展开后高度截断或滚动卡顿
在 iOS Safari 或部分安卓 WebView 中，嵌套 flex 容器对 height: auto 和子项 flex: 1 的解析不稳定，表现为内容只显示一半、滚动条失效、或展开瞬间空白。
这不是 CSS 写错了，是渲染引擎对嵌套弹性布局的高度回流计算有缺陷：
- 临时解法：给展开中的子菜单强制设
height: fit-content，并搭配overflow: hidden触发重排 - 避免在子菜单内部再用
display: flex+flex-direction: column+flex: 1组合，改用grid或纯 block 布局 - 若必须用 flex，子菜单容器加
align-items: flex-start显式约束交叉轴，减少不确定性
对齐的本质不是“看起来居中”，而是让定位锚点、热区范围、渲染行为三者对齐——任何一环松动，菜单就会在某个设备上突然失联。
