子菜单定位错乱主因是父级<li>未设position: relative；宽度自适应应弃用width: 100%而用min-width: max-content+max-width；移动端:hover不可靠须改用JS或focus-within；动画须用max-height过渡而非height: auto。
子菜单定位错乱：必须设 position: relative 在父级
二级菜单飘到左上角、或横向偏移严重，90% 是因为父 <li> 没加 position: relative。CSS 的 absolute 定位永远找最近的 position: relative/absolute/fixed 祖先；没找到就回退到 <body>，直接脱离导航流。
常见错误写法：.submenu { position: absolute; top: 100%; left: 0; } 却忘了给 .menu-item 加定位上下文。
- 每个带子菜单的
<li class="has-sub">必须显式声明position: relative - 不要依赖
float或display: inline-block来“撑开”定位上下文——它们不触发包含块（containing block） - 如果一级菜单用了
display: flex，仍需单独给.has-sub加position: relative，flex 容器本身不提供定位上下文
宽度自适应失效：别用 width: 100% 或固定像素
子菜单宽度和父项不一致，比如父项“关于我们”很短，子菜单却铺满全屏，是因为你写了 width: 100% ——它继承的是父 <li> 的内容区宽度，而该区域常被 padding/margin 干扰，且未考虑字体渲染差异。
真正可靠的方案是让子菜单“尽可能贴合文字”，同时防溢出：
立即学习“前端免费学习笔记（深入）”；
- 用
min-width: max-content让菜单至少容纳最长项文字（现代浏览器支持） - 搭配
max-width: 300px防止超宽（尤其在小屏下） - 文字过长时加
white-space: nowrap; overflow: hidden; text-overflow: ellipsis; - 避免
width: 100%+box-sizing: border-box组合——父项 padding 会压缩可用宽度，导致子项换行或截断
:hover 在移动端完全不可靠
iOS Safari 和多数安卓 WebView 对 :hover 的模拟极不稳定：第一次点击可能只触发伪 hover，第二次才算真实 click，造成菜单闪开又立刻收起。这不是 bug，是规范行为。
纯 CSS 方案在移动端必须放弃 :hover，改用可编程状态：
- 桌面端可用
.has-sub:hover > .submenu，但必须配合.has-sub:focus-within > .submenu支持键盘导航 - 移动端必须用 JS 切换
is-open类，或操作data-open属性，再用[data-open="true"] > .submenu控制显隐 - 别试图用
@media (hover: hover)做条件加载——它在 iOS 上返回hover，但实际不生效 - 如果坚持用 checkbox 模拟，每个层级必须用独立
<input type="checkbox" id="sub-1">，不能复用同一 ID
展开动画卡顿或跳变：height: auto 无法过渡
写 height: 0 → height: auto 看起来合理，但浏览器无法对 auto 做插值计算，结果就是瞬间展开或根本不动。
稳定做法只有一条路：用 max-height 过渡，并配合适当的初始值：
- 初始状态：
max-height: 0; overflow: hidden; opacity: 0; - 展开状态：
max-height: 500px; opacity: 1;（500px 要大于所有可能内容高度） - 别用
visibility: hidden替代display: none——前者保留文档流占位，鼠标悬停仍能穿透触发 - 移动端 Safari 对
max-height过渡有渲染延迟，可加transform: translateZ(0)强制 GPU 加速
