### display: flow-root——浮动塌陷的优雅解法 你可能会觉得，浮动这东西明明是CSS里最基础的技能，为什么翻来覆去就是清不干净？父容器高度塌了、后续元素跑偏了、背景和边框消失得莫名其妙……这些症状，其实都不是“样式没写对”那么简单，而是文档流秩序被破坏后的必然反应。解决的核心，不是盲目地加个`clear`，而是理解触发条件和作用范围的差别。 先说个结论：在现代浏览器中，`display: flow-root`是解决浮动塌陷的最优解。一行代码触发BFC，干干净净，没有副作用，不裁剪内容。相比之下，`clear: both`只作用于自身，放到父容器上根本没用；而经典的伪元素clearfix方案则需要`content: ""`、`display: table`、`clear: both`三者缺一不可，少一个就失效。 `` #### 为什么`clear: both`放在浮动元素后面无效？ 这个坑踩的人太多。常见的做法是在浮动元素的下一个同级`

`上写`clear: both`，以为这样就能解决问题——但`clear`只影响自身所在行的“换行行为”，它不会去修复父容器的高度塌陷。真正需要清除的，是浮动对父级高度计算的影响，而不是单纯让下一行不绕排。 几个关键点： * `clear`只控制元素自身的定位位置，不能帮父元素重新“看见”它的子元素 * 如果浮动元素都在同一个父容器里，`clear`必须作用于该父容器的内部末尾（比如用伪元素），或者直接触发父容器本身的BFC * 直接在浮动元素后面加一个`

`虽然能撑开父容器高度，但这种做法污染了HTML结构，对响应式布局也不友好 #### `overflow: hidden`清除浮动的副作用 给父容器设置`overflow: hidden`是最快捷的清除方式——这句话听着耳熟吧？但它的本质是触发BFC，同时会**裁剪所有溢出内容**。哪怕只是轻微的阴影、下拉菜单、tooltip，或者一个`transform: translateY(-5px)`做微调，都可能被意外截断。 使用`overflow: hidden`需要警惕的风险： * 如果父容器内有`position: absolute`子元素超出边界，会被隐藏 * 配合`transform`微调位置时，可能会被意外裁剪 * `overflow: auto`同样触发BFC，但滚动条的出现逻辑不可控，用户体验难保证 * `overflow: clip`更精准，可惜IE不支持 所以，现代项目里建议优先用`display: flow-root`替换`overflow: hidden`，语义清晰、无裁剪风险。 #### 伪元素`::after`清除法的三个硬性条件 经典的`.clearfix::after`方案，技术上没有问题，但必须同时满足三个条件才生效，缺一不可： * `content: ""` —— 伪元素没有内容就不会渲染，`clear`也就无从谈起 * `display: block`（或`table`）—— 行内伪元素无法应用`clear` * `clear: both` —— 只写`clear: left`或`clear: right`，遇到混合浮动方向就失灵 漏掉任意一条，比如只写了`content: ""`和`clear: both`，却没设置`display`，伪元素就不会占据空间，清除自然失败。很多“清除不干净”的问题，排查到最后发现就是少写了一条`display`。 #### 现代布局中，何时可以彻底放弃清除浮动？ 答案很明确：当你使用`display: flex`或`display: grid`布局父容器时，子元素就算写了`float`也**完全失效**。Flex/Grid容器自带强文档流控制，浮动被忽略，塌陷问题自然不存在。 这里有几个容易被忽视的点： * 浮动只在块级格式化上下文（BFC）中起作用；Flex/Grid创建的是独立格式化上下文，与浮动机制互斥 * 千万别混用——比如父容器设了`display: flex`，又给子项写`float: left`，后者会被静默丢弃，调试时很容易误判 * 如果历史代码中浮动已成习惯，迁移时应该同步删除所有`float`声明，而不是保留下来再费劲“清除” 说到底，清除浮动不是目的，恢复文档流秩序才是。很多问题表面看是“清不干净”，实际是父容器没形成BFC、伪元素没渲染、或根本不需要清除——比如你已经用了Grid，还费劲加`clearfix`，反而引入冗余逻辑。选对方法，代码清爽，复用安心。