clearfix 是解决浮动导致父容器高度塌陷的标准化方案，优于 clear: both 的硬编码方式；主流推荐 micro clearfix（双伪元素 + display: table），兼顾兼容性与稳定性；需避免类名冲突、滥用及伪元素被全局重置，并不建议用 contain: layout 替代。
clear: both 为什么在现代项目里越来越不够用了
浮动元素脱离文档流后，父容器高度塌陷的问题确实能用 clear: both 在末尾加个空 <div> 解决，但实际项目里很快会遇到几个硬伤：它强制要求 HTML 结构配合 CSS，破坏语义；多人协作时容易漏写或重复写；Flex/Grid 布局混用时，<code>clear 完全失效。更麻烦的是，某些 CSS 预处理器或组件化框架（比如 Vue 的 scoped style）会让 .clearfix 类的作用域失效，导致清理行为不生效。
真正需要的不是“在哪加 clear”，而是“让父容器自动感知子浮动并撑开”——这正是 Clearfix 的核心价值。
主流 Clearfix 实现的区别和选型依据
现在能看到的 Clearfix 写法至少有三种：micro clearfix、new clearfix（伪元素双冒号）、以及针对 IE6/7 的 zoom: 1 版本。它们不是越新越好，得看项目实际约束：
-
micro clearfix（:before+:after+content: ""+display: table）兼容性最好，从 IE6 到现代浏览器都稳，但会在渲染树里多出两个匿名节点，对极端性能敏感的动画页可能有微小影响 - 只用
:after的简化版在 IE8+ 可用，代码少，但 IE6/7 下完全无效——如果你的项目已明确放弃支持，可以放心用 - 带
zoom: 1的老版本是为触发 IE6/7 的 hasLayout，现在基本不用，除非维护遗留系统
推荐直接采用 micro clearfix 的标准写法，它在 postcss-preset-env 或 autoprefixer 下也无需额外处理。
立即学习“前端免费学习笔记（深入）”；
`.clearfix::before,
.clearfix::after {
content: "";
display: table;
}
.clearfix::after {
clear: both;
}`全局统一应用时最常踩的三个坑
Clearfix 不是“写了就完事”，在大型项目中，以下问题几乎必现：
- 类名冲突：不同团队各自定义
.clearfix，有的用display: block，有的漏了::before，最终样式互相覆盖。解决方案是把它收进基础样式库（如@mystyle/base），并通过构建工具确保全局只有一份 - 滥用场景：给 Flex 容器或 Grid 容器也加
.clearfix，不仅无效，还可能干扰align-items或justify-content的表现。判断标准很简单：只要容器声明了display: flex或display: grid，就别加 - 伪元素被重置：某些重置样式（如
* { box-sizing: border-box; }）没影响，但若项目里全局设置了*::before, *::after { display: none; }，Clearfix 就彻底失能——这种配置虽少见，但一旦存在，排查起来极耗时间
要不要用 CSS 的 contain: layout 替代 Clearfix
contain: layout 确实能让父容器“包含”浮动子元素的高度，但它目前（2024 年中）在 Safari 中仍需 -webkit-contain: layout，且 Firefox 对该值的支持不稳定。更重要的是，contain 是布局隔离机制，副作用比 Clearfix 大得多：它会阻止外部 transform 动画穿透、影响 position: fixed 的参照系，甚至改变滚动锚点行为。
所以除非你正在做高度可控的微前端沙箱环境，并且所有子模块都承诺不使用 fixed 或复杂动画，否则别拿 contain: layout 当 Clearfix 的平替。它解决的不是同一个问题。
Clearfix 的本质是补丁，而补丁的价值不在多酷炫，而在所有人用同一套逻辑去堵同一个洞。项目越大，越不能靠“我这里加个 clear”来临时救火。
