为什么 .clearfix 还在用，但不能乱套
因为浮动元素会脱离文档流，导致父容器高度塌陷，而 .clearfix 是最轻量、兼容性最好（IE6+）的修复方案。它不依赖现代布局（如 Flex 或 Grid），适合需要兜底老浏览器的公共库。
但直接复制网上“万能 clearfix”容易出问题：比如用了 ::after 但没设 content: ""，或忘了 display: table 在 IE7 的必要性。
-
content: ""必须存在，否则伪元素不渲染，清除失效 - IE6/7 不支持
::after，所以得用*zoom: 1触发 hasLayout - 如果父元素本身有
overflow: hidden，可能遮住下拉菜单等溢出内容，此时.clearfix更安全
.clearfix 的最小可靠写法
不是越长越好，而是刚好覆盖主流场景。下面这段在 PC 端项目中稳定用了十年：
`.clearfix::before,
.clearfix::after {
content: "";
display: table;
}
.clearfix::after {
clear: both;
}
.clearfix {
*zoom: 1;
}`
说明：
立即学习“前端免费学习笔记（深入）”；
-
::before和::after都设display: table，是为了让它们成为块级框并参与 BFC，避免 margin 合并干扰 - 只在
::after清除浮动，::before单纯撑开顶部间距（防止上边距塌陷） -
*zoom: 1是 IE6/7 的 hack，仅触发 hasLayout，不影响现代浏览器解析
什么时候不该用 .clearfix
当容器本身已是 BFC 容器时，浮动不会造成塌陷，加 .clearfix 属于冗余甚至引发意外。
- 父元素设置了
overflow: auto/hidden/scroll - 父元素是
display: flex/grid/table-cell - 父元素有
float自身（虽然少见，但此时它也不在文档流里） - 用
display: flow-root（Chrome 58+/Firefox 59+）已可替代，但公共库要考虑兼容性，暂不推荐替换
在 CSS 公共库中定义的注意事项
公共库里的 .clearfix 得足够“钝”，不能带业务语义，也不能依赖其他类或变量。
- 不要写成
.clear或.cf—— 缩写易冲突，语义模糊 - 不要加
!important，否则下游无法覆盖（比如某些组件需要clear: none） - 避免用 SCSS 变量或嵌套，确保编译后是纯 CSS，方便被其他构建工具消费
- 如果项目已全面弃用 IE，可精简为
display: flow-root，但务必在文档里注明兼容范围
真正麻烦的从来不是写对这一段代码，而是团队里有人在父元素上同时写了 overflow: hidden 和 .clearfix，又查不出为啥下拉菜单被截了——这时候得翻 DOM 结构，而不是重看 CSS 文件。
