float 会让父容器高度塌陷，因其将元素移出文档流，父容器计算高度时忽略浮动子元素；可靠清除方式是触发 BFC，如 display: flow-root 或 overflow: auto。
float 属性为什么会让父容器高度塌陷
因为 float 会把元素从文档流中“抽出来”，父容器计算高度时直接忽略它，就像它不存在一样。这不是 bug，是 CSS2.1 明确规定的渲染行为。
- 常见错误现象：
div包着几个float: left的子元素，但父div在页面上“看不见”——背景色不显示、边框没包住内容 - 典型场景：老式图文混排（文字绕图）、多栏导航、无 JS 的网格雏形
- 别用
height: auto硬撑，那只是掩耳盗铃；也别依赖overflow: hidden了事，它可能意外裁剪position: absolute子元素 - 真正可靠的清除方式是触发 BFC，比如给父容器加
display: flow-root（现代写法）或overflow: auto（兼容性更好）
clear 和 clearfix 到底该用哪个
clear 是单点控制，clearfix 是整套防御策略。前者解决“这一行别贴着上面的浮动”，后者解决“这个容器得知道自己里面漂着啥”。
- 错误用法：在最后一个浮动子元素上加
clear: both，结果只清了它自己，父容器依然塌陷 - 使用场景：
clear适合布局断点（比如两栏之后插一段通栏标题）；clearfix必须用在浮动元素的**直接父容器**上 - 经典
clearfix的:after伪元素必须设content: ""和display: table（或block），否则不生效；visibility: hidden不如height: 0安全 - 注意 IE6/7 兼容写法要额外加
*zoom: 1触发 hasLayout
float 布局和 Flex/Grid 的性能差异在哪
不是“快慢”问题，是“重排成本”问题。浮动布局一旦触发重排，浏览器要反复计算浮动边界、回溯父级、检查折行，而 Flex/Grid 的轴线模型是单向推导的。
- 典型卡顿场景：在浮动容器里动态增删子项、或用 JS 频繁改
width/margin -
float的重排影响范围不可控——可能波及整个文档流上游；Flex/Grid 的重排通常局限在容器内部 - 不要为了“兼容 IE8”硬扛浮动布局：现代项目用
@supports (display: flex)做渐进增强更稳妥 - 如果真要支持旧浏览器，优先降级到
display: table-cell，比浮动 + clearfix 更稳定
float 还值得学吗？哪些地方绕不开它
作为布局手段基本淘汰了，但作为文本环绕机制、以及某些 CSS 动画/transition 的触发条件，它还在 quietly 起作用。
立即学习“前端免费学习笔记（深入）”；
- 绕不开的场景：PDF 导出工具（如 PrinceXML）仍重度依赖
float实现图文混排；部分富文本编辑器的“左对齐图片”功能底层仍是float - 容易被忽略的细节：给
float元素加transform会创建新层叠上下文，可能意外遮挡后续内容；而flex里order不影响层叠顺序 - 调试时看到
float相关的错位，先查line-height和vertical-align——它们和浮动的基线对齐逻辑纠缠极深
