父元素高度为0是因为浮动子元素脱离文档流，父容器无法感知其存在；推荐用clearfix配合::after伪元素清除浮动，或现代方案display:flow-root触发bfc。
父元素高度为 0，不是因为 CSS “出错了”，而是因为 float 让子元素彻底退出了标准文档流——父容器在计算 height: auto 时，根本不会把它们算进去。
float 元素为什么在 height 计算中“隐身”
浏览器对 height: auto 的计算逻辑非常明确：只基于仍在文档流中的子元素内容撑开。一旦子元素设置了 float: left 或 float: right，它就从这个“撑高名单”里被移除。
- 即使该浮动元素有
height: 300px、margin-bottom: 50px，父容器的 computedheight仍可能显示为0 -
min-height无效——它依赖内容撑高，而浮动内容不被视为“有效撑高内容” - 父容器加
border或background-color后看起来“空了”，是因为没有高度可渲染，不是样式没生效 - 后续兄弟元素上移、覆盖浮动区域，是同一机制的连带表现，不是独立 bug
clear: both 写在子元素上完全没用
clear: both 只对处于同一浮动上下文中的**后续兄弟元素**生效，它不改变父容器的布局逻辑。
- 错误写法：
.child { float: left; clear: both; }→ 这只是让该子元素避开前面的浮动，和父容器高度无关 - 真正起作用的
clear，必须出现在所有浮动子元素之后、且本身仍在文档流中的一个块级元素上 - 伪元素
::after能胜任，是因为它被插入在父容器末尾，且默认是文档流内的块级元素 - 如果伪元素没写
content: ""，它就不会渲染，clear自然失效
display: flow-root 是最干净的现代解法
display: flow-root 是 CSS 明确为解决这类问题设计的属性：它创建一个新的 BFC（块级格式化上下文），强制父容器“重新包含”所有子元素，包括浮动的。
- 它不裁剪溢出内容（不像
overflow: hidden），也不影响子元素定位（不像position: absolute） - 必须直接作用于**包裹浮动子元素的那个父容器**上；套一层 wrapper 或写在子元素上，都无效
- 兼容性到 Chrome 64+/Firefox 58+，但 IE 完全不支持；老项目需回退到
clearfix - DevTools 的 Computed 面板里要能看到 “Block formatting context” 提示，才说明 BFC 真正生效
别被 padding/border 的“视觉假象”骗了
给父容器加 padding-top 或 border-bottom，确实能让背景或边框“露出来”，但这只是视觉欺骗。
- computed
height依然是0，浮动子元素依然不在文档流中 - 后续元素的 margin 可能因塌陷导致合并异常，尤其在响应式断点切换时更难排查
- 如果父容器需要和 flex/grid 容器对齐，或者有
box-shadow，错位会立刻暴露 - 真正该检查的，永远是 DevTools 中父容器的 Computed 面板里的实际
height和 BFC 状态
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
