clearfix能撑开父容器高度，是因为浮动元素脱离文档流导致父容器塌陷，而.clearfix::after通过插入块级伪元素并设置clear: both和display: table来触发BFC、拉低父容器底边，从而修复包含逻辑。
会，但只在特定条件下触发——关键不是clear本身，而是它导致父容器高度变化后，迫使浏览器重新计算依赖该高度的后续元素位置。
clear 为什么会间接引发重排
clear属性本身不直接触发重排，但它会让浏览器回溯检查前面所有浮动兄弟节点，以确定“清除点”在哪。这个过程只有在以下条件同时满足时，才会升级为真实重排：
- 被清除的元素是参与文档流的块级元素（比如
display: block） - 它的垂直位置依赖于前序浮动元素的最终布局（例如紧接在多个
float: left之后） - 清除动作改变了它的高度（典型如撑开原本塌陷的父容器）
- 后续兄弟元素的位置受该高度变化影响（比如紧跟其后的
<p></p>或.footer）
display: flow-root 是唯一不触发重排的清除方案
它让父容器原生创建 BFC，在样式计算阶段就确定了包含所有浮动子元素的高度，后续布局无需回溯、不依赖清除时机。
- 兼容 Chrome 64+ / Firefox 58+ / Safari 15.4+，IE 完全不支持
- 不会裁剪
box-shadow、position: absolute子元素或下拉菜单 - 不要和
display: flex或display: grid混用——后者已自带 BFC，叠加反而覆盖布局模式 - 若父容器已有
overflow: auto，再加flow-root不冲突但冗余
overflow: hidden 清除浮动时抖动的真实原因
抖动不是overflow: hidden本身的问题，而是它在某些渲染路径中触发 BFC 的时机不可控：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 或 Chrome 移动端：当同时存在
-webkit-overflow-scrolling: touch（或scroll-behavior: smooth）时，BFC 可能延迟到 layout 阶段才生效，造成首帧渲染时父高为 0 → 内容先挤上去 → BFC 生效后突然撑开 → 视觉“闪一下” - 部分安卓 WebView 中
overflow: auto可能意外显示滚动条，看起来像抖动 - 绝对不要用
overflow: hidden清除浮动的同时放 tooltip、阴影、position: fixed子元素——裁剪即抖动源
伪元素 clearfix 为什么有时也抖
抖动往往来自两个被忽略的细节：
- 伪元素没设
display: table（或block），或用了display: inline（默认值），无法正确撑高 - 父容器设了
font-size: 0（常见于 inline-block 布局 hack），但伪元素未重置字体大小，导致display: table在旧引擎中失效 - 动态插入浮动内容后，JS 只改了
innerHTML却没触碰offsetHeight等 layout 触发属性，伪元素清除滞后一帧
真正难处理的是清除浮动与动画、滚动加载、动态 DOM 插入耦合的场景——这些地方的重排不是单次发生，而是逐帧或逐 item 累加，容易演变成持续性卡顿。别把clear: both当成收尾工具，它本质是个布局探针，每次调用都在要求浏览器重新扫描前面所有浮动节点。
