父容器高度为0px是因为浮动元素彻底退出标准文档流，height: auto仅基于文档流内内容计算，浮动元素被排除在“撑高名单”外，即使其自身有height或margin，父容器仍视而不见，min-height也因无有效撑高内容而失效。
父容器高度变为 0px，不是 CSS 出错了，而是浮动元素彻底退出了标准文档流——父容器在计算 height: auto 时，压根不把它们当“内容”看。
浮动元素为什么在 height 计算中“隐身”
浏览器对 height: auto 的计算逻辑非常明确：只基于仍在文档流中的子元素内容撑开。一旦子元素设置了 float: left 或 float: right，它就从这个“撑高名单”里被移除。
- 哪怕该浮动元素有
height: 300px、margin-bottom: 50px，父容器的computed height仍可能显示为0 -
min-height也无效——它依赖内容撑高，而浮动内容不被视为“有效撑高内容” - 给父容器加
border或background-color后看起来“空了”，是因为没有高度可渲染，不是样式没生效
clear: both 写在子元素上完全没用
clear: both 只对处于同一浮动上下文中的**后续兄弟元素**生效，它不改变父容器的布局逻辑。
- 错误写法：
.child { float: left; clear: both; }→ 这只是让该子元素避开前面的浮动，和父容器高度无关 - 真正起作用的
clear，必须出现在所有浮动子元素之后、且本身仍在文档流中的一个块级元素上 - 伪元素
::after能胜任，是因为它被插入在父容器末尾，且默认是文档流内的块级元素
display: flow-root 是最干净的现代解法
display: flow-root 是 CSS 明确为解决这类问题设计的属性：它创建一个新的 BFC（块级格式化上下文），强制父容器“重新包含”所有子元素，包括浮动的。
- 它不裁剪溢出内容（不像
overflow: hidden），也不影响子元素定位（不像position: absolute） - 必须直接作用于**包裹浮动子元素的那个父容器**上；套一层 wrapper 或写在子元素上，都无效
- DevTools 的 Computed 面板里要能看到 “Block formatting context” 提示，才说明 BFC 真正生效
- 兼容性到 Chrome 64+/Firefox 58+/Safari 15.4+/iOS 15.4+，但 IE 完全不支持；老项目需回退到
clearfix
伪元素 clearfix 容易失效的几个关键点
用 .clearfix::after 方案时，漏掉任一条件都会导致它“看起来没效果”。
-
content: ""必须存在——没有内容，伪元素不生成，clear自然失效 -
display: table比display: block更稳妥：table 自带块级行为，还能避免 margin collapse 异常 - 父容器自身得在文档流中——不能是
display: inline，也不能被height: 0或overflow: hidden锁死高度 - Chrome DevTools 默认不显示伪元素，需勾选 “Show user agent shadow DOM” 才能验证是否渲染成功
真正卡住人的，往往不是“怎么闭合高度”，而是闭合之后忘了检查父容器是否还有可靠的尺寸锚点——比如图片加载延迟、字体加载未完成、或 margin 折叠意外压缩了可用高度。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
