display: flow-root 是现代标准解法，专为触发 BFC 设计，无副作用且兼容 Chrome 64+/Firefox 58+；Flex/Grid 容器默认已是 BFC，无需额外清除浮动。
浮动元素导致父容器高度塌陷，页面布局错乱
这是最典型的“抖动”表象：浮动子元素脱离文档流后，父容器无法自动包裹内容，后续元素上移、重叠或错位。本质不是抖动，而是盒模型计算失效。
解决核心是让父容器重新建立 BFC（块级格式化上下文），从而包含浮动子元素。不要用 clear: both 单独加空标签——冗余、语义差、维护成本高。
-
overflow: hidden或overflow: auto是最快捷的方案，但注意会裁剪溢出内容（比如下拉菜单、tooltip） -
display: flow-root是现代标准解法，专为触发 BFC 设计，无副作用，Chrome 64+/Firefox 58+ 支持 - 避免用
float: left给父容器本身设浮动——这会让它也脱离文档流，问题转移而非解决
CSS清除浮动的三种写法，哪一种真正可靠
所谓“清除”，其实是让元素避开前面浮动元素的影响区域。但很多写法只治标不治本，甚至引入新问题。
-
::after伪元素 +clear: both是兼容性最好、语义最干净的方式，需配合content: ""和display: table（或block） -
clear: both直接写在下一个兄弟元素上，仅适用于你明确控制后续 DOM 结构的场景；若后续是第三方组件或动态插入内容，极易失效 - 用
height: 1px或font-size: 0强制撑开父容器——属于 hack，响应式下极易崩，且违背盒模型逻辑
display: flow-root 在 Flex/Grid 布局中是否还必要
不需要。Flex 容器和 Grid 容器默认就是 BFC 根元素，天然包含内部浮动子项。强行加 display: flow-root 不仅多余，还会覆盖原有布局模式。
立即学习“前端免费学习笔记（深入）”；
常见误用场景：在 display: flex 的父容器里，又给它加 display: flow-root，结果 flex 行为消失，子项按 block 流排列。
- 判断依据很简单：只要父容器已启用
display: flex、display: grid或display: table，就不需要额外清除浮动 - 如果子元素用了
float但父容器是 Flex，说明设计逻辑矛盾——浮动在 Flex 中本就无效，浏览器会忽略float声明
移动端 Safari 下 overflow: hidden 清除浮动失效？
不是失效，是触发了 iOS WebKit 的一个渲染边界行为：当容器有 overflow: hidden 且同时存在 -webkit-overflow-scrolling: touch 时，BFC 触发可能被延迟或跳过。
真实原因常被误判为“清除失败”，其实是滚动优化干扰了布局计算。
- 优先改用
display: flow-root，它不依赖 overflow 属性，完全规避此问题 - 若必须用
overflow: hidden，请移除-webkit-overflow-scrolling: touch（iOS 16+ 已废弃该属性） - 检查是否同时设置了
transform或will-change，这些也会创建独立图层，影响 BFC 判定
