现在不该用 float 创建复杂导航栏，因其代价高、容错低、维护难，尤其清除溢出易致下拉裁剪、响应错位、宽度失准；根本原因是清除的是浮动流而非视觉溢出，且现代应优先用 flex 或 flow-root 替代。
直接说结论：现在不该用 float 创建复杂导航栏。它能做，但代价高、容错低、维护难——尤其“清除溢出”这一步，稍有不慎就导致下拉菜单被裁、响应式错位、计算宽度失准。
为什么 float 导航栏容易出现“清除后仍溢出”
根本不是 clear: both 没生效，而是你清的是“浮动流”，不是“视觉溢出”。常见误判点：
- 给
.nav加了overflow: hidden→ 确实清了塌陷，但下拉菜单（position: absolute）超出部分被裁掉 - 用伪元素
::after清除 → 成功撑高父容器，但若li有border或padding且没设box-sizing: border-box，总宽仍超 100% - 在
ul上写clear: both→ 完全无效，clear只对自身生效，不作用于父级高度计算
如果必须用 float，怎么避免宽度和溢出双重翻车
关键不在“怎么清”，而在“清之前先控宽”。浮动项的宽度误差几乎都来自默认盒模型和未显式归零的 inherited padding/margin：
- 重置
ul.nav：去掉默认padding-left: 40px，加margin: 0 - 统一
li盒模型：box-sizing: border-box必须写，否则width: 25%+padding: 8px= 实际宽 > 25% - 用
calc()扣减 margin：比如 4 个项、每项左右margin: 0 12px，则写width: calc(25% - 24px)（注意空格，2*12px会解析失败） - 清除必须用伪元素：
.nav::after { content: ""; display: table; clear: both; }，别用空div，也别依赖overflow
浮动导航里下拉菜单被截断，最快修复方式
不是调 z-index，也不是改 position，而是检查包含块层级：
立即学习“前端免费学习笔记（深入）”；
- 下拉菜单（
ul.dropdown）的父级是哪个？如果是li，而li的父级ul.nav用了overflow: hidden→ 立刻失效 - 解决方案：把
overflow移到更外层容器（如.header），让ul.nav仅负责清除浮动，不干预溢出 - 更稳妥的做法：给
ul.nav改用display: flow-root（Chrome 64+/Firefox 59+ 支持），它触发 BFC 但不裁剪内容 - 若需兼容 IE11，只能保留伪元素清除，并确保下拉菜单的
top值足够大、且其transform不触发新的包含块
真正麻烦的从来不是“怎么清浮动”，而是浮动一旦嵌套多层、又混用 position 和 transform，清除逻辑就会和渲染层打架——这时候花两小时调 calc 公式，不如半小时改成 display: flex。现代浏览器里，float 在导航栏中只剩一个合理用途：文字环绕图片。其他所有场景，它都在悄悄增加你的调试成本。
