display: flow-root能撑开父容器高度，因为它显式创建独立BFC，使父容器重新包含浮动子元素并正确计算高度，不裁剪、不滚动、不干扰定位；但遇display:flex/grid/inline-block、IE不兼容、contain属性或JS依赖offsetHeight时会失效。
直接给父容器加 display: flow-root 就能清除浮动，前提是浏览器支持且没有其他 display 值冲突。
为什么 display: flow-root 能撑开父容器高度
浮动元素脱离文档流，父容器默认不参与它们的布局计算——本质是没形成 BFC（块级格式化上下文）。display: flow-root 的作用就是显式创建一个独立的 BFC，让父容器重新“看见”浮动子元素并正确计算边界和高度。
它和 overflow: hidden 触发 BFC 的原理一样，但只做这一件事：包裹浮动，不裁剪、不滚动、不干扰定位。
-
display: flow-root不会隐藏box-shadow、下拉菜单或position: absolute子元素 - 不会意外触发横向滚动条
- 不改变 z-index 层级或影响滚动容器行为
display: flow-root 容易失效的几种情况
它不是写上去就一定生效，常见失效点集中在 display 值覆盖和兼容性上：
立即学习“前端免费学习笔记（深入）”；
- 父元素已声明
display: flex、display: grid、display: inline-block等——这些值与flow-root互斥，CSS 解析时只认最后一个有效声明 - 项目需兼容 IE11 或更老浏览器：
flow-root完全不支持，必须用@supports (display: flow-root) {}包裹，或保留::afterfallback - 父元素同时设置了
contain: layout或contain: paint，可能抑制 BFC 行为，导致高度仍塌陷 - 旧项目中 JS 动态读取
offsetHeight或依赖 margin 合并逻辑——flow-root会重置外边距合并，原有计算可能出错
和伪元素 ::after 清除法的实际差异
两者都能撑高父容器，但底层机制和维护成本不同：
-
::after方案必须写content: ""+display: table（或block+height: 0），漏掉display就无效；而flow-root是单行声明，无额外节点，不影响可访问性 -
::after在全局 CSS 重置（比如清空所有伪元素content）时可能被意外干掉；flow-root是 display 值，稳定性更高 - 如果父容器本身要用
display: flex实现内部布局，就不能再设flow-root，此时只能退回到 BFC 方案（如overflow: auto或伪元素）
真正容易被忽略的是：浮动本身在现代布局中已退居二线，但清除浮动的问题往往不是出现在你主动写的 float 上，而是第三方组件、图文环绕场景或 legacy 代码里突然冒出来的——这时候选错方案，错位只是表象，更可能是 tooltip 被裁、滚动异常或 JS 高度计算失准。
