横向导航首选 display: inline-block，兼容性好且无塌陷问题；避免用 inline 导致宽高失效；需处理空白符间隙、基线对齐空隙；ie11 下 flex 有 flex-wrap 渲染 bug，建议降级方案。
HTML 横向导航用 display: inline-block 最稳
纯 CSS 实现横向菜单，display: inline-block 是兼容性好、行为可预测的首选。它不会像 float 那样引发父容器塌陷，也不像 flex 在老浏览器里需要一堆前缀或降级方案。
常见错误是直接给 <li> 设 display: inline，结果发现没法控制宽高、内边距错位、换行异常——因为 inline 元素天生不支持 width/height 和部分 vertical-align 行为。
- 把
<li>设为display: inline-block，不是<a></a> - 加
vertical-align: top防止基线对齐导致的底部空隙 - 父
<ul></ul>建议设font-size: 0，子项再设回正常字号，彻底干掉默认空白符间隙 - 别依赖 HTML 中的换行或缩进，它们会转成空格，影响布局
Flexbox 水平菜单要防 IE11 的 flex-wrap bug
用 display: flex 做横向导航确实简洁，但 IE11 对 flex-wrap: nowrap（默认值）的处理有隐性 bug：当子项总宽度超容器时，它可能强行换行或截断，而不是正确溢出滚动或隐藏。
这不是写法错，是渲染层缺陷。线上真实项目里，这个 bug 常在窄屏设备或动态加载菜单后突然暴露。
立即学习“前端免费学习笔记（深入）”；
- 显式声明
flex-wrap: nowrap，哪怕它是默认值 - 给
<ul></ul>加min-width: max-content防止被压缩变形（Chrome/Firefox 支持，IE11 不支持，所以得配合 JS 回退） - 如果必须支持 IE11，优先用
inline-block方案；Flex 只用于现代浏览器渐进增强 -
justify-content: space-between在项数少时容易露白边，不如flex-start+ 手动 margin 控制可靠
导航链接点击区域太小？改 padding 别碰 width
横向菜单常被吐槽“点不准”，根源不是 JS 绑定问题，而是 <a></a> 默认是 inline 元素，只包裹文字内容，点击热区窄得可怜。很多人第一反应是给 <a></a> 设 display: block 再配 width，结果菜单项挤成一列或错位。
正确做法是保持 <a></a> 在行内流中扩展热区，靠 padding 向外撑开，不破坏布局流。
- 给
<a></a>加padding: 12px 24px，比设height+line-height更安全 - 避免设置
width或min-width，让文字长度自然决定宽度，适应多语言场景 - 如果要用图标+文字，确保
padding-left留足图标空间，别靠margin推，那会扩大不可见热区 - 移动端记得加
touch-action: manipulation，减少 iOS Safari 300ms 点击延迟
下拉菜单悬停失效？检查 :hover 作用域和层级
横向导航加下拉，最常遇到“鼠标移过去菜单一闪就消失”。不是 JS 逻辑错，90% 是 CSS 层级或 :hover 触发范围没连上——比如 <li> 和下拉 <ul></ul> 之间有 1px 间隙，或者 z-index 被父容器的 overflow: hidden 截断。
- 下拉
<ul></ul>必须和触发它的<li>是同级子元素，不能隔层 - 给触发
<li>设position: relative，下拉<ul></ul>用position: absolute并设top: 100% - 确认没有父级
overflow: hidden把下拉框裁掉了（常见于 header 固定高度容器） - 移动端慎用
:hover，iOS Safari 在非<a></a>上不触发，优先用focus-within或 JSclick切换类名
横向导航真正难的不是写出来，而是让不同屏幕、不同输入方式、不同浏览器版本下都“点得着、看得清、不闪跳”。细节全在 padding、position、display 这几个属性的组合里，改一个值，可能就跨过了可用和不可用的边界。
