清除浮动易全局污染，因clear: both和.clearfix::after等规则若写在common.css等全局文件中会全站生效；css modules需严格满足.module.css后缀、js导入使用、禁用html硬编码class三条件才能局部化；现代项目应优先用flexbox/grid替代float布局根治问题。
为什么清除浮动的样式容易全局污染
清除浮动本身不是模块化操作，clear: both、.clearfix::after 这类规则一旦写在非模块化 CSS 文件里（比如 common.css 或 reset.css），就会对整个页面生效。更隐蔽的问题是：你在一个组件里写了 .clearfix 类，结果其他组件里只要用了同名类，哪怕没 import 这个文件，也可能被意外覆盖或干扰——因为类名没隔离。
用 CSS Modules 封装 clearfix 类必须满足三个条件
想让清除浮动逻辑真正局部化，不能只靠“把样式写进 .module.css”，还得确保：
- 文件后缀必须是
.module.css（Vite/Webpack 默认只对这个后缀启用模块化） - 类名必须通过 JS 导入使用，例如
import styles from './Card.module.css'，然后在 JSX/TSX 中写className={styles.clearfix} - 不能在 HTML 模板里硬编码
class="clearfix"，否则构建时不会重命名，直接走全局流程
:global() 不能用来“修复”浮动清除的跨组件问题
有人试图在模块文件里写 :global(.clearfix) { ... } 让它变成全局可用，这反而破坏了模块初衷，而且：
-
:global()只作用于选择器本身，不改变其内部声明的作用域——:global(.clearfix)::after仍会生成全局伪元素，污染所有用到.clearfix的地方 - 第三方库或旧代码里已存在的
.clearfix不会自动映射到你的模块样式，JS 里无法通过styles.clearfix控制它 - 若多个模块都定义了
:global(.clearfix)，最终 CSS 规则会叠加甚至冲突，权重和加载顺序决定谁胜出
现代项目更推荐绕过浮动清除本身
真正根治问题的方式，是让“需要清除浮动”这个需求消失：
- 用
display: flex或display: grid替代float布局，父容器天然包含子项，无需清除 - 如果必须兼容老浏览器，把
.clearfix提取成独立的、无.module后缀的工具类文件（如utils.css），并在入口统一import一次，避免重复注入 - 在组件内小范围清除时，优先用
overflow: hidden或display: flow-root，它们不依赖额外类名，也不产生全局选择器
最容易被忽略的一点：CSS Modules 对伪元素（::before/::after）的选择器部分照样做哈希处理，但如果你在 .clearfix::after 里写了 content: "" 以外的全局依赖（比如引用了未模块化的字体或动画），那些资源依然会泄漏出去。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
