父容器高度塌陷是浮动元素脱离文档流导致的必然结果；解决方法包括触发BFC（如overflow:hidden或display:flow-root）或使用.clearfix::after伪元素清除浮动，现代布局推荐直接采用flex/grid避免该问题。
父容器高度塌陷是浮动最直接的视觉表现
只要子元素用了 float: left 或 float: right，又没做任何清除处理，父容器高度几乎必然变成 0 —— 不是“可能”，而是 CSS 渲染引擎的标准行为。这不是 bug，是规范定义：浮动元素脱离文档流后，不再参与父容器的高度计算。
常见现象包括：border 看不见、background-color 不显示、后续兄弟块级元素向上“塌陷”覆盖原位置。尤其在 CMS 输出或动态插入内容时，这种问题容易被误判为数据缺失或 JS 执行失败。
- 检查父容器是否设置了
height或min-height：有则可能掩盖问题，但属于硬编码补丁，不解决根本 - 用浏览器开发者工具的“Computed”面板看父容器
height值，确认是否为0px - 临时加
outline: 1px solid red到父容器，快速验证是否“看不见边框”而非“没渲染”
overflow: hidden 不是万能解，反而可能遮掩真实问题
给父容器加 overflow: hidden 确实能触发 BFC，让父容器重新包含浮动子元素并撑开高度。但它同时会裁剪所有溢出内容 —— 比如子元素用了 position: absolute 向外偏移、或者 transform: translateY(-10px) 上移，这些都会被无声截断。
更隐蔽的问题是：当父容器本身需要滚动（比如卡片列表），overflow: hidden 会让滚动失效；若后续加了 position: fixed 子元素，还可能引发层叠上下文冲突。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 只在明确不需要溢出内容、且无其他定位需求时才用此法
- 避免与
position: relative+z-index组合使用，否则可能意外改变堆叠顺序 - 在移动端 Safari 中，某些旧版本对
overflow: hidden的 BFC 触发不稳定，建议加overflow: auto作兼容
::after 伪元素清除法必须写对选择器和 display 类型
现代标准清除方式是用 ::after 在父容器末尾插入一个清除节点，但很多人复制代码却漏掉关键细节：伪元素必须是 display: block，且 clear: both 才生效；content: "" 缺失会导致整个规则无效。
典型错误写法：.clearfix::after { clear: both; } —— 没有 display: block，伪元素默认是 inline，clear 对它不起作用。
- 完整可靠写法：
.clearfix::after { content: ""; display: block; clear: both; } - IE8 及以下需额外加
.clearfix { *zoom: 1; }触发 hasLayout - 不要用
visibility: hidden或height: 0替代display: block，它们无法建立清除上下文
现代布局中应优先规避 float 而非修复它
float 的原始设计目标只是图文环绕，不是页面布局。现在用它实现两栏、三栏甚至响应式网格，本质是在用“副作用”当功能 —— 每次都要对抗塌陷、清除、换行、间隙等连锁反应。
真正省事的做法：把浮动仅留给 <img> 旁的文字环绕场景；其余布局改用 display: flex 或 display: grid。它们天然不脱离文档流，父容器高度自动计算，无需清除，也无 margin 折叠、基线对齐等干扰。
- Flex 容器内子项即使设了
float，也会被忽略 —— 这说明引擎已不鼓励混用 - Grid 布局中
float同样无效，且会触发 warning 提示 - 如果 legacy 代码必须保留浮动，至少把清除逻辑封装成可复用 class，别每次手写
浮动带来的高度计算异常，根源不在“怎么修”，而在于“为什么还在用”。真正难排查的，往往是那些没显式写 float 却继承了浮动父级样式的元素 —— 它们藏得深，影响却一样真实。
