正确写法是先写 fallback（如 .clearfix），再用 @supports (display: flow-root) 覆盖；fallback 必须用带 content: "" 和 display: table 的 ::after 伪元素清浮，且需兼容 Android 4–5 WebView 等陷阱环境。
直接用 display: flow-root 并配 @supports 回退是可行的，但必须写对顺序、检测方式和 fallback 逻辑，否则旧浏览器照样塌陷。
为什么 @supports (display: flow-root) 必须写在 fallback 后面
旧浏览器（如 IE11、Android 4.4 WebView）根本不认识 display: flow-root，遇到整条规则会静默跳过——包括它后面的声明块。如果你把 fallback 写在 @supports 里面，等于没写。
- ❌ 错误写法：
@supports (display: flow-root) { .parent { display: flow-root; } } .parent { display: block; }→ IE11 跳过整个@supports块，.parent没任何样式 - ✅ 正确写法：
.parent { display: block; } @supports (display: flow-root) { .parent { display: flow-root; } }→ 旧浏览器执行第一行，现代浏览器覆盖为flow-root - 注意：
display: block本身不创建 BFC，所以 fallback 必须是真正能清浮的方案（见下一条）
fallback 必须是真能清浮的伪元素写法，不能只靠 display: block
display: block 或 display: inline-block 都无法解决浮动塌陷，它们不触发 BFC。IE11 下唯一可靠 fallback 是带 ::after 的 .clearfix，且需满足三个硬性条件。
- 必须同时声明
::before和::after，否则 IE8/旧 Safari 可能漏掉顶部 margin collapse 导致布局偏移 - 伪元素必须有
content: ""+display: table（不是block），因为table天然创建 BFC，而block不保证 - 不能省略
clear: both，且不能加在父元素自身上（.parent { clear: both; }完全无效）
标准写法：
立即学习“前端免费学习笔记（深入）”；
.clearfix {
*zoom: 1; /* IE6/7 hack */
}
.clearfix::before,
.clearfix::after {
content: "";
display: table;
}
.clearfix::after {
clear: both;
}Android WebView 4.4–5.1 是最大陷阱，@supports 检测会失效
这些系统内核虽识别 @supports 语法，但对 (display: flow-root) 返回 true，实际却完全不触发 BFC。仅靠 CSS 无法判断是否真正生效。
- 运行时验证更可靠：
getComputedStyle(el).display === 'flow-root'在 Android 5.1 WebView 中可能返回'block'，但高度仍为 0 - 建议结合 UA 检测：
navigator.userAgent.match(/Android\s[4-5]\.\d/)，匹配到就强制启用.clearfix - 回退策略要叠加：对浮动父容器同时加
overflow: hidden和.clearfix，二者缺一不可（实测中单用任一都可能失败）
别忽略 display: flow-root 自身的副作用
它不是“无感替换”，而是改变了盒模型行为，降级时若只换清除方式，其他逻辑可能崩。
- 它禁用外边距合并（margin collapse）：父容器和第一个/最后一个子元素之间不再合并 margin，旧代码若依赖这个行为会错位
- 它让原本是
inline级的元素（如span）强制块级化，可能意外换行 - 若父容器已设
contain: layout或contain: paint，flow-root可能被抑制，高度仍塌陷 —— 这种情况 fallback 必须接管全部逻辑
最稳妥的做法是：把 flow-root 当作增强，把 .clearfix 当作底线，两者共存不互斥；不要指望一次声明覆盖所有环境。
