推荐优先使用 display: flow-root 修复浮动导致的父容器高度塌陷，它创建 BFC 包裹浮动元素且不改变布局，兼容 Chrome 64+/Firefox 59+/Edge 17+，比 overflow: hidden 和伪元素清除法更安全高效。
浮动元素导致父容器高度塌陷，怎么快速修复
父容器没高度，里面浮动的 div 全“飘”出去了，这是最典型的症状。根本原因是浮动元素脱离文档流，父容器计算高度时直接忽略它们。
推荐优先用 display: flow-root —— 它创建一个块级格式化上下文（BFC），天然包裹内部浮动，且不改变布局行为，兼容性也够用（Chrome 64+/Firefox 59+/Edge 17+）。
- 别再无脑加
overflow: hidden：它会意外裁剪内容或隐藏阴影、下拉菜单 - 避免用伪元素清除法（
::after { content: ""; display: table; clear: both; }）写在每个浮动容器里——维护成本高，且容易漏掉或写错content - 如果必须支持 IE8/9，才退回到
zoom: 1+*display: inline的 hasLayout 触发方案
定位元素（position: absolute）和浮动混用时，为什么定位失效
浮动元素会影响其后续兄弟元素的“正常流位置”，而 position: absolute 的参照物是最近的已定位祖先（position 不为 static），不是浮动元素本身。两者逻辑不在同一层，强行混搭极易出偏移。
常见错误是给浮动元素加 position: relative 后，再让子元素 absolute 定位，结果发现偏移基准不对——因为浮动改变了元素在行框中的位置，但 relative 只是“视觉偏移”，不重置定位上下文的起始点。
- 浮动 + 绝对定位，只在明确需要“视觉锚定”且父容器已设
position: relative时才用；浮动本身不该承担定位职责 - 想让某元素贴着浮动块右上角？直接给该元素设
position: absolute，并指定top和right，父容器加position: relative即可，别依赖浮动的“位置” - 浮动元素内部不能靠
top/left拉绝对定位子元素来“对齐”——它没 BFC，子元素可能脱出或重叠
Flexbox 或 Grid 出现后，还有必要学清除浮动吗
有必要，但目的变了：不是为了“必须清除”，而是为了看懂遗留代码、理解文档流机制、以及处理某些 CSS 无法接管的场景（比如富文本编辑器输出的 img 默认浮动、第三方组件库内部样式）。
现代布局中，float 已退化为纯文本环绕工具（如图文混排），不再用于整体页面布局。强行用浮动做三栏，不如一行 display: flex 清晰稳定。
- 遇到老项目里满屏
float: left+clear: both，优先评估能否整体替换成display: flex或grid，而不是修修补补 - 清除浮动的代码（如
clearfix类）仍可能出现在 UI 库源码里，读懂它有助于调试，但自己新写代码时应主动规避 -
float在打印样式表（@media print）中仍有实际用途，比如让图片自动右对齐不打断段落流
清除浮动的性能和渲染影响差异
所有清除方式最终都只是触发浏览器重新计算布局（reflow），但触发时机和范围不同。最轻量的是 display: flow-root，它不新增 DOM 节点、不引入额外样式规则，BFC 创建开销极小。
而伪元素清除法（::after）会增加一个匿名盒子，虽不明显，但在大量列表项中叠加使用，会略微增加样式计算和绘制压力；overflow: hidden 则可能强制开启图层合成，尤其当容器内有动画或 transform 时，易引发意料外的 GPU 占用。
- 避免在滚动容器（如
.list-scroll）上滥用overflow: hidden清除浮动——它会截断滚动条或遮挡悬停效果 - 用
flow-root时注意：它会让margin折叠行为改变，若父容器原本依赖 margin 合并，需额外检查视觉表现 - 没有“万能清除方案”，关键看上下文：是临时修复？长期维护？是否要兼容旧浏览器？选最窄、最可控的那个
浮动不是 bug，是 CSS 原始设计的一部分；问题在于把它当布局主力用。真正难的不是怎么清，而是判断什么时候该停手、换种思路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
