display: flow-root能解决浮动塌陷，因为它创建bfc使容器正确计算包含浮动子元素的高度，且语义明确、不截断溢出，但ie不支持。
为什么display: flow-root能解决浮动塌陷
因为flow-root会为元素创建一个新的块级格式化上下文（BFC），而BFC的特性之一就是：**内部浮动元素不会影响外部容器的高度计算**。它不像overflow: hidden那样靠“隐藏溢出”间接触发BFC，而是明确、语义化地声明“我要当一个独立的布局根”。浏览器因此会重新计算高度，把浮动子元素撑起来。
常见错误现象：div里放了几个float: left的img或section，父容器高度变成0，背景色/边框消失，后续元素往上跑。
-
flow-root在Chrome 58+、Firefox 57+、Safari 10.1+支持，IE完全不支持 - 比
overflow: hidden更干净——不意外截断阴影、下拉菜单、定位元素 - 比
clear: both伪元素方案少写两行CSS，也不依赖额外DOM节点
不用flow-root时，哪些替代方案还在用
老项目或需兼容IE时，仍得绕开flow-root。但要注意：每个方案都有隐性代价。
-
overflow: hidden或auto：最常用，但可能剪掉position: absolute子元素的展开区域（比如下拉菜单） -
::after伪元素 +clear: both：可靠，但多一层抽象，维护时容易漏掉content: ""或忘记display: table -
display: flex或grid：父容器变弹性/网格容器后，浮动子元素会失效（float对flex item无作用），行为突变需验证
示例（伪元素清浮）：
.container::after { content: ""; display: table; clear: both; }
flow-root和display: block的区别在哪
看起来都“正常显示内容”，但底层布局规则完全不同。设成block的容器仍处于普通文档流中，浮动子元素会脱离流、不参与高度计算；而flow-root强制开启BFC，让容器“看见”浮动子元素的真实尺寸。
- 性能上无差异——BFC创建是渲染引擎的常规操作，不是昂贵计算
- 兼容性是唯一硬约束：若需支持IE11，不能单独依赖
flow-root - 它不会改变子元素的盒模型、内外边距行为，只修正高度坍缩这一个问题
什么时候不该用flow-root
不是所有浮动场景都适合。如果浮动只是临时排版手段（比如文字环绕图片），而父容器本就不该有高度（如inline级文字流中的span），强行加flow-root反而破坏预期布局。
- 父元素本身是
inline元素（如span）：设flow-root会触发display值重置为block，导致换行 - 已有复杂
transform或will-change优化逻辑：BFC可能干扰图层合成策略（极少见，但动画卡顿时可排查） - 团队规范禁止隐式BFC创建：有些架构要求BFC必须显式通过
overflow或contain控制
真正要盯住的，是那个被浮动撑开却没显式设定高度的父容器——它是否本就该“感知”子元素？这才是决定用不用flow-root的关键。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
