::after 清浮动更可靠，因其直接附着父容器、不依赖后续DOM结构，只需父元素存在且设置content: ""和display: table等规则即可稳定生效，适配组件化开发。
为什么 ::after 清浮动比 clear: both 更可靠
因为 clear: both 必须加在浮动元素之后的**下一个块级兄弟元素**上，一旦 DOM 结构变动（比如后端注入、JS 动态插入），就容易漏掉或错位；而 ::after 是直接附着在父容器上的伪元素，只要父容器存在，清除逻辑就稳定生效。
关键点在于：它不依赖后续 HTML 元素，只依赖父元素自身是否设置了 overflow 或伪元素规则——所以更适配现代组件化开发中“封装即隔离”的思路。
- 必须给父容器设置
zoom: 1（IE6/7）或display: block（现代浏览器），否则伪元素可能不渲染 -
content: ""不可省略，否则伪元素不会生成，清除失效 - 不要用
visibility: hidden或opacity: 0替代height: 0+overflow: hidden，前者仍占文档流高度
::after 清浮动的标准写法及兼容性取舍
最简可用版本是：.clearfix::after { content: ""; display: table; clear: both; }。它在 IE8+ 和所有现代浏览器中都有效，且不触发 BFC（避免意外的边距合并或滚动条）。
但如果你需要支持 IE6/7，就得补一行 *zoom: 1（注意是星号前缀 hack），这是触发 hasLayout 的最低成本方式。
立即学习“前端免费学习笔记（深入）”；
- 不用
display: block+height: 0+overflow: hidden组合，它虽能清浮，但会隐藏溢出内容（比如下拉菜单、tooltip） - 避免用
display: flex或display: grid父容器强行清浮——这改变了布局模型，不是“清除”，而是“绕过” - PostCSS 或 Sass 中可抽成
@mixin clearfix，但别无脑全局@extend，会污染选择器权重
什么时候不该用 ::after 清浮动
当父容器本身需要参与 BFC 上下文（比如要防止外边距塌陷、要隔离内部浮动对页面其他区域的影响），这时仅靠 ::after 不够，得配合 overflow: hidden 或 display: flow-root。
另外，如果浮动子元素本身用了 position: absolute 或 position: fixed，那它们已脱离文档流，::after 清的其实是“不存在的浮动”，纯属白忙。
- Flex 容器或 Grid 容器内部的子项即使写了
float，也会被忽略——此时清浮动毫无意义 - 服务端渲染（SSR）场景下，若父容器初始无内容，
::after可能因 CSS 加载延迟短暂失效，需搭配min-height防抖 - Web Component Shadow DOM 中，需把 clearfix 规则写在
:host内，外部样式不会穿透
display: flex 或 display: grid 替代，::after 清浮动只是兜底手段，不是首选方案。 
