::after伪元素是最干净的清除浮动方案，因其附着于父容器、不依赖DOM顺序，且需content:""和display:table才能生效；现代项目若已用Flex/Grid则无需，但维护旧代码或第三方组件仍需谨慎使用。
::after 伪元素是目前最干净、无需额外 DOM 的清除浮动方案，只要父容器明确包含浮动子项，它就能稳定生效。
为什么 ::after 比 clear: both 空标签更可靠
空 <div class="clearfix"></div> 必须紧接在浮动元素之后，一旦 JS 动态插入、服务端模板注入或组件复用导致 DOM 顺序变动，清除就立刻失效；而 ::after 是附着在父容器上的伪元素，不依赖后续兄弟节点是否存在。
常见错误现象包括：父容器背景色/边框消失、后续区块上移覆盖浮动内容、响应式断点下突然错位。
- 必须给父容器加
content: ""，否则伪元素根本不生成，clear: both形同虚设 -
display: table比display: block更稳妥——避免 IE8 下 margin 双倍、不继承 line-height、不意外撑高容器 - 不能用
visibility: hidden或opacity: 0替代height: 0 + overflow: hidden，前者仍占文档流高度
.clearfix::after 的最小可用写法及兼容性取舍
现代项目（IE11+）只需两行：
立即学习“前端免费学习笔记（深入）”；
.clearfix::after {
content: "";
display: table;
clear: both;
}
若需支持 IE6/7，补一行 *zoom: 1（星号前缀 hack），这是触发 hasLayout 的最低成本方式，比 overflow: hidden 安全得多。
- 别用
display: flex或display: grid父容器“强行清浮”——这改变了布局模型，不是清除，是绕过 - 避免混用
overflow: hidden和clear: both，后者在 BFC 已触发时多余，还可能干扰position: absolute子元素定位 - PostCSS/Sass 中可封装为
@mixin clearfix，但别全局@extend，会污染选择器权重
哪些场景下 ::after 清除会悄悄失效
它只对「当前父容器内部的浮动」起作用，且依赖渲染上下文是否完整。容易被忽略的失效点有：
- 父容器设了
transform、filter或will-change，创建新层叠上下文后，clear行为可能被隔离 - 父容器是
position: absolute且未设宽高，::after无法正确计算尺寸 - 子元素用了
float+ 负margin-top，与::after的clear产生冲突，优先改用margin-bottom控制间距 - CSS-in-JS 或 Shadow DOM 中，伪元素选择器作用域受限，
::after可能根本没生效，需显式写入:host
现代项目里要不要还写 clearfix
如果你已全面使用 display: flex 或 display: grid 布局，基本不需要——浮动本身已不该用于主布局。但以下情况仍是刚需：
- 维护老项目（尤其含 IE11 兼容要求）
- 图表库、图例、富文本编辑器等第三方组件内部仍用
float实现紧凑排列 - CSS-in-JS 动态生成浮动结构（比如某些 UI 组件的 tooltip 对齐逻辑）
关键不是“会不会写”，而是“该不该加”：只加在明确包含浮动子项的父容器上，别无脑套用到所有 div 上——复杂点往往不在写法本身，而在浮动是否真被需要。
