浮动高度塌陷是因浮动元素脱离文档流，父容器计算高度时“看不见”它们；所有清除方案本质都是让父容器重新感知其高度，从而正确撑开背景、边框及外边距。
浮动高度塌陷不是样式写错了，而是父容器在计算高度时根本“看不见”浮动子元素——因为它们已脱离文档流。所有清除方案的本质，都是让父容器重新感知浮动元素的高度。
float 脱离文档流的后果必须讲清楚
面试中一说“浮动”，很多人只想到“向左向右排”，但关键得分清：浮动元素仍在页面上、有位置、能交互，唯独不参与父容器的高度计算。这直接导致三个可观察现象：
-
background-color和border只显示一条线（父高为 0） - 父容器后的兄弟元素向上顶进浮动区域（比如一个
<div>直接叠在浮动块上） -
margin-bottom在父容器上失效（因为高度没撑开，下边距无处可落）
别只说“它脱离流了”，要强调：脱离的是「高度计算流」，不是「渲染流」或「事件流」。
clear: both 不是清除浮动，而是阻止重叠
这是高频误解点。clear 作用对象是「当前元素自身」，不是浮动源。它声明：“我的上边界不能和前面的浮动元素挨着”。所以：
立即学习“前端免费学习笔记（深入）”；
- 加在浮动子元素末尾的空
<div style="clear:both"></div>，靠的是这个空元素本身是标准流块级元素，会强制换行并撑开父高 - 加在父容器上无效（
clear对父容器无意义） -
clear: left和clear: right在多列混合浮动时才真正有用，纯左浮场景用both就够
BFC 触发方案要分清兼容性与语义代价
触发 BFC 是现代清除浮动最主流思路，但不同方式影响不同：
-
overflow: hidden：简单有效，但会意外裁剪溢出内容（比如下拉菜单、阴影、transform 位移） -
display: flow-root：2018 年起标准化，语义清晰、无副作用，但 IE 完全不支持，需确认项目兼容要求 -
display: table：能触发 BFC，但会改变盒模型（变成表格行为），可能干扰 margin 合并或垂直对齐 -
::after伪元素：.clearfix::after { content:""; display:table; clear:both; }兼容性最好，但需额外 class，且 IE6/7 需配zoom:1
如果面试官问“为什么不用 overflow:auto”，得答出：它虽能触发 BFC，但滚动条可能意外出现（尤其动态内容高度变化时）。
现代布局中浮动该不该用？要诚实回答
别回避现实。可以说：“浮动本就不是为复杂布局设计的，它最初只为图文环绕服务。现在 display: flex 和 display: grid 能更可靠地控制对齐、换行、响应式，且天然不存在塌陷问题。” 但如果被追问“那为什么还要考清除浮动”，可以补一句：“理解它，是理解 CSS 布局演进的关键切口——从流式到弹性再到网格，每一步都在解决前一代的缺陷。”
真正容易被忽略的，是清除浮动从来不是目的，而是手段；核心诉求永远是：让父容器正确包裹内容高度。只要达到这点，用什么方案，取决于项目约束，而不是教科书排名。
