浮动本身不支持多层级菜单的显示控制，仅能用于一级菜单横向排列，子菜单必须依赖:hover+position:absolute+display实现，且需清除浮动塌陷、设置relative锚点，现代应改用flex布局。
浮动本身不支持多层级菜单的显示控制
纯 CSS 浮动（float）只能让元素脱离文档流并靠左/右排列，它没有“悬停展开子菜单”“层级定位”“显示/隐藏切换”这些交互能力。你看到的所谓“浮动菜单”，实际是用 float 布局一级菜单项，但二级及以下菜单的显示逻辑完全依赖 :hover + position: absolute + display 或 visibility 控制——浮动在这里只是个布局配角，不是控制逻辑的主力。
常见错误现象：
– 子菜单跟着父项一起浮动，错位或堆叠在奇怪位置
– 悬停时子菜单闪退（因浮动导致父容器高度塌陷，:hover 区域丢失）
– 多级菜单无法对齐父项右侧/底部（float 不提供锚点定位能力）
- 一级菜单项可用
float: left横向排列，但必须给父容器清除浮动（如overflow: hidden或伪元素::after），否则高度塌陷会直接破坏悬停区域 - 子菜单必须脱离浮动流：设
position: absolute，并确保其最近的非static定位祖先是一级菜单项（即给li加position: relative） -
display: none/display: block是最直接的显隐控制方式；避免用visibility: hidden，它仍占空间且悬停可能失效
为什么现代写法早就弃用浮动做菜单布局
浮动设计初衷是文字环绕图片，不是 UI 组件布局。用它做菜单会触发一系列兼容性与维护问题：
- IE6–8 中浮动元素的
:hover仅支持a标签，若菜单项是li或div，悬停无效 - 浮动元素无法用
flex或grid对齐控制，响应式断点时容易错行、换行不可控 - 移动端 touch 事件下，
:hover行为不一致（iOS Safari 会延迟触发甚至不触发），而浮动布局对此毫无补救能力 - 无障碍（a11y）支持差：屏幕阅读器难以理解浮动造成的视觉层级，也无法暴露子菜单的展开状态
替代方案：用 display: flex + position: absolute 实现可靠多级菜单
一级菜单用 display: flex 替代 float，干净、可控、无塌陷风险；子菜单继续用 position: absolute 定位。这是目前最稳妥的组合。
立即学习“前端免费学习笔记（深入）”；
示例关键片段：
nav ul { display: flex; }
nav li { position: relative; }
nav li ul {
position: absolute;
top: 100%;
left: 0;
display: none;
}
nav li:hover > ul { display: block; }
- 必须给
li设position: relative，否则ul的absolute会相对于 body 定位 - 不要给子菜单加
float，它只会干扰absolute的定位基准 - 若需右对齐二级菜单（如“设置”菜单向右展开），改
left: auto; right: 0;即可，浮动做不到这点
真正要小心的是 hover 区域断裂和键盘导航缺失
即使布局写对了，多级菜单最常崩在两个地方：一是鼠标从一级菜单移向二级菜单途中经过空白间隙，导致 :hover 离开而菜单消失；二是完全忽略键盘用户（Tab 键无法进入子菜单，Enter/Space 无法展开，Esc 无法收起）。
- 解决悬停断裂：在一级菜单和二级菜单之间加一个垂直方向的重叠区（如
margin-bottom: -1px或用top: 99%微调），或用pointer-events: none在过渡区域临时透传事件（需谨慎） - 键盘支持不能靠 CSS 完成，必须配合
tabindex、aria-expanded和 JS 监听keydown，否则再漂亮的浮动或 flex 菜单，在真实使用场景里都是半残废
浮动不是菜单的解法，它只是历史遗留的布局惯性。真正卡住项目的，往往不是怎么写 CSS，而是没想清楚：谁来触发显示？谁来维持焦点？断网或低性能设备下是否还能操作？这些点比 float 还 float。
