直接结论：给导航容器加 display: flow-root，90% 的情况一步解决；若需兼容 IE11，用 @supports 回退到 overflow: hidden。导航栏高度为 0 是因浮动子元素脱离文档流，父容器无法感知其高度，display: flow-root 能创建 BFC 且无副作用，@supports 可安全降级，clearfix 已非首选。
直接结论：给导航容器加 display: flow-root，90% 的情况一步解决；若需兼容 IE11，用 @supports 回退到 overflow: hidden。
为什么导航栏高度变成 0 了
浮动子元素（比如 .nav-item）脱离文档流，父容器（.nav）完全感知不到它们的高度。你看到的“错位”“背景色消失”“下方内容上移”，本质都是父容器 height: 0 导致的——不是样式写错了，是布局机制在按规范运行。
常见误判点：
- 以为加
position: relative就能撑高（它不触发 BFC，无效） - 把
clear: both写在li上（清除的是兄弟元素，对父容器高度无影响） - 用
padding-top硬撑（视觉上像好了，但 computed height 仍是 0，后续 margin-collapse 或定位仍会出问题）
现代项目首选 display: flow-root
这是 CSS 为解决浮动塌陷专门设计的值，语义明确、无副作用：
立即学习“前端免费学习笔记（深入）”；
- 一行生效：
.nav { display: flow-root; } - 不裁剪溢出内容（下拉菜单、tooltip、阴影全保留）
- 不干扰
position: fixed或z-index层叠（移动端 Safari/安卓 WebView 安全） - 无需伪元素，避免重排开销，动画和滚动更顺滑
兼容性兜底写法（推荐直接用）：
.nav {
display: flow-root;
}
@supports not (display: flow-root) {
.nav {
overflow: hidden;
}
}
别再用 clearfix::after 除非必须兼容老浏览器
经典 clearfix 在移动端容易失效，尤其在缩放、高 DPI 或某些 WebView 下：
- 必须写全四条：
content: ""、display: table、clear: both、height: 0，缺一不可 - 只写
clear: both是常见错误，伪元素根本不会生成 - 旧版 UC 浏览器或 QQ 浏览器内核可能把
display: block当成行高来算，导致高度异常
如果你的项目已用 Flex/Grid 布局，注意：float 在 display: flex 或 display: grid 的父容器中会被忽略——此时加 clearfix 完全无效，纯属冗余。
绝对定位不是解法，是新坑
有人试过给 .nav 加 position: absolute 强行“钉住”，结果：
- 导航脱离文档流，下方内容直接顶上来，页面布局断裂
-
margin和float对它完全失效，调试时容易误判原因 - 响应式断点失效（宽度不再随容器变化）
- 若真要吸顶，该用
position: sticky，并确保父容器有明确高度或overflow: visible
真正难处理的，往往是遗留系统里混用 float + inline-block + JS 动态插入菜单项的场景——这时候 flow-root 依然可靠，但得检查 JS 是否在插入后触发了重排，导致短暂闪动。
