现代项目应优先使用 display: flow-root，它原生、语义明确且无副作用；但需注意 margin 折叠被重置和字体继承链被切断两个隐性影响，仅在兼容 IE、flex/grid 中意外 float 或依赖 ::after DOM 行为时才用 .clearfix。
现代项目直接用 display: flow-root，除非要兼容 IE 或特殊继承逻辑
绝大多数 2026 年的新项目已无需支持 IE，display: flow-root 是浏览器原生、语义明确、无副作用的解法。它不插入伪元素、不触发重排、不裁剪 position: absolute 子项，也不干扰 box-shadow 或 border-radius 渲染。而 .clearfix::after 是一套“模拟清除”机制，依赖 content: "" + display: table + clear: both 三者同时成立——漏一个就彻底失效。
flow-root 的两个隐性影响必须手动验证
它不是“零成本替换”，上线前务必检查这两点：
-
margin折叠行为被重置：相邻块级元素（如h2和紧随其后的p）原本靠margin-top合并对齐，加了flow-root后会断开，可能需补margin-top - 字体继承链被切断：子元素的
font-size不再从父容器继承，而是回退到:root值——老项目中文字可能突然变小，尤其当父容器设了font-size: 0.875rem之类缩放时
.clearfix 只在三个明确场景下仍有必要
别把它当默认选项，只在以下情况才保留：
- 项目明确要求支持 IE11 或更旧环境（
flow-root完全不被识别） - 父容器已设
display: flex或display: grid，但又意外保留了子元素的float（此时flow-root无法叠加，clear: both在 flex/grid 上也无效，得先理清布局意图） - 已有大量历史代码依赖
::after的 DOM 行为（比如 JS 通过getComputedStyle(el, '::after')判断状态）
用 @supports 写降级比硬塞 overflow: hidden 安全得多
如果真要兼顾旧环境，降级方案必须避开 overflow: hidden——它在移动端常裁掉下拉菜单、tooltip 和阴影。正确写法是：
立即学习“前端免费学习笔记（深入）”；
.container {
display: flow-root;
}
@supports not (display: flow-root) {
.container::after {
content: "";
display: table;
clear: both;
}
}
@supports 检测的是属性值本身，不是 UA 字符串，稳定可靠；而 overflow: hidden 这类 fallback 看似简单，实际会在 iOS Safari 中引发不可见的滚动条或定位偏移，调试成本远高于多写两行 CSS。
真正容易被忽略的，是把 flow-root 当成“安全替换”直接全局扫雷——它改的是盒模型底层行为，不是样式开关。上线前必须过一遍关键流式区域的 margin 对齐和字体大小表现。
