clearfix能撑开父容器高度，是因为其伪元素通过display:table和clear:both在浮动元素下方生成有高度的不可见块，使父容器重新获得可测量高度。
clearfix 为什么能撑开父容器高度
浮动元素脱离文档流，父容器无法感知其高度，clearfix 并不是“拉回”浮动元素，而是通过伪元素在视觉末尾插入一个强制下移的块，让父容器重新获得可测量的内部高度。
核心机制是两件事同时发生：display: table（或 block）让伪元素参与盒模型计算；clear: both 强制它落到所有浮动元素下方——这个“落点”本身就有高度，哪怕内容为空，也足以撑起父容器。
-
content: ""必须存在，否则伪元素不渲染，整个方案失效 -
display: table比block更稳妥：旧版 Safari 对clear在block伪元素上的支持不稳定 - 必须加在浮动子元素的**直接父容器**上，写在祖父层无效
标准 clearfix 写法与 IE 兼容性取舍
当前最通用、无副作用的写法仍是：
.clearfix::after {
content: "";
display: table;
clear: both;
}
这段代码兼容 IE8+，已覆盖绝大多数存量项目。若你明确不需要支持 IE，可省略 *zoom: 1；若仍需兼容 IE7，才需补上：
.clearfix { *zoom: 1; }
-
*zoom: 1是 IE7 的 hasLayout 触发 hack，现代项目基本可删 - 别把
::before当“标配”硬加——它主要防外边距合并，多数场景不必要 - 用 PostCSS 或 Tailwind 时，
clearfix类本质仍是这套伪元素逻辑，没变
overflow: hidden 看似简单，但容易踩坑
overflow: hidden 能触发 BFC，确实会让父容器包含浮动子元素，但它不是“清除”，只是“包裹”。副作用非常具体：
- 所有溢出内容被裁剪：比如
position: absolute的下拉菜单、box-shadow、负 margin 拉出的装饰线全消失 - 在 iOS Safari 上，
overflow: auto可能引发滚动卡顿或意外出现滚动条 - 和
transform或fixed元素交互时，层级和定位行为可能异常 - 调试时容易误判：看到高度正常，就以为布局没问题，其实浮动干扰仍在
现代项目里，什么时候该放弃 clearfix
如果父容器用 display: flex 或 display: grid 布局，子元素根本不需要 float，也就不存在塌陷问题——这时加 clearfix 不仅多余，还可能干扰 flex item 的对齐行为。
更值得关注的是那些“看起来没浮动，其实用了第三方库”的场景：
- Bootstrap 的
.row已内置clearfix，重复添加会导致双倍清除，可能引发意外交互 - 某些 UI 组件库的卡片容器内部用了 float，但文档没明说，得 inspect 元素确认
- 嵌套浮动容器必须逐层加
clearfix：父清了，子容器里再 float，还得再清一次
真正难处理的，从来不是那段 .clearfix::after 代码，而是你忘了检查那个嵌套三层深、没加 class 却悄悄 float 的 div。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
