不能直接用 overflow: hidden 清除浮动，因其会意外裁剪绝对定位、transform 或可滚动子元素；可靠 clearfix 需满足 display: block、clear: both、content: ""、height: 0 且 visibility: hidden 四条件。
为什么不能直接用 overflow: hidden 封装清除类
它看似一行解决，但副作用太强：一旦子元素有 position: absolute、transform 或滚动容器（如 textarea、div[contenteditable]），内容会被意外裁剪。模块化项目中，你无法预判下游组件是否含溢出内容，硬塞 overflow: hidden 等于埋雷。
::after 伪元素清除类的最小可靠写法
必须同时满足四个条件才算真正通用：触发块级渲染、清除浮动、不占空间、兼容 IE8+。缺一不可。
-
display: block—— 确保伪元素参与 BFC 建立 -
clear: both—— 关键动作，否则无效 -
content: ""—— 必须存在，否则伪元素不生成 -
height: 0; visibility: hidden;—— 防止无意义高度撑开布局（仅设display: none会彻底移除伪元素，失去清除效果）
完整代码：
.clearfix::after {
content: "";
display: block;
clear: both;
height: 0;
visibility: hidden;
}
.clearfix {
*zoom: 1; /* IE6/7 兼容，模块化项目若已放弃支持可删 */
}模块化场景下 class 命名与复用边界
不要把清除逻辑耦合进布局类名里，比如 .grid 或 .card 内部硬写 ::after。这会导致：
立即学习“前端免费学习笔记（深入）”；
- 语义混乱：
.card的职责是视觉样式，不是处理浮动副作用 - 难以调试：当清除失效时，你得在多个地方检查重复逻辑
- 无法组合：
.card.clearfix比.card--has-floats更直观、可预测
正确做法是单独导出 clearfix 工具类，在需要的地方显式叠加，例如：<div class="card clearfix">。<h3>现代项目中该不该继续封装这个类</h3>
<p>如果项目已全面使用 <code>display: flex 或 display: grid 布局，就别再封装了。浮动只应留在极少数场景：图文混排中的 img + p、历史组件兼容、或 CSS-in-JS 中动态生成浮动结构。把这些例外场景单独抽象成 float-wrap 类更合适，而不是让 clearfix 成为每个模块的默认依赖。
真正容易被忽略的是：很多团队把 clearfix 当成“安全网”全局注入，结果反而掩盖了本该用 Flex/Grid 替换的过时浮动写法。
