.clearfix本身不污染，但子应用全局引入reset/normalize会将其注入document全局，多个子应用同名规则后加载者覆盖前序，qiankun不拦截静态CSS加载与卸载。
直接说结论：clearfix 类本身不污染，但子应用全局引入（如 @import "normalize.css" 或 import "reset.css"）会把 .clearfix 注入 document 全局，一旦多个子应用都带同名规则，后加载的就会覆盖前一个——而微前端框架（如 qiankun）根本不管这类静态 CSS 的加载顺序和卸载清理。
为什么 .clearfix 会跨子应用“串味”
它不是 JS 变量，不进 JS 沙箱；也不是 scoped 样式，不随组件销毁自动移除；更不是 Shadow DOM 内部规则，天然参与主文档层叠。只要两个子应用都执行了 import './assets/reset.scss'，它们的 .clearfix { zoom: 1; *zoom: 1; } 就会先后写入 document.styleSheets，最终生效的是最后一个插入的版本——哪怕只是 margin 值不同，也可能导致主应用侧边栏塌陷或顶部导航错位。
常见错误现象：
- 子应用 A 切换到子应用 B 后，主应用的折叠菜单突然无法展开（
.clearfix被 B 的重置覆盖，丢失hasLayout触发逻辑） - DevTools 中看到多个
.clearfix规则并存，但只有最后一条被标记为 “active” - 构建产物 dist/css/*.css 里仍存在裸露的
.clearfix，未绑定任何应用前缀或容器约束
必须禁用子应用的全局 reset / normalize 引入
子应用不能自己 import 'normalize.css' 或 @import "./base/reset.scss"。这些文件天生就是为单页应用设计的，和微前端的多实例共存模型冲突。
立即学习“前端免费学习笔记（深入）”；
正确做法：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 主应用统一提供基础样式重置，并通过
:where()或[data-micro-app]属性选择器限定作用域，例如：:where(.micro-app-container[data-app="order"]) .clearfix { ... } - 子应用所有样式必须基于主应用已声明的 CSS 变量（如
--space-xs、--border-radius-sm）和布局基线编写，禁止重定义盒模型、display、float 等底层行为 - 若子应用确实需要 clearfix 行为，应封装为局部 mixin 或 utility class，并强制绑定运行时 app ID：
.<code>{window.__MICRO_APP_NAME__}__clearfix { ... }
用 PostCSS 动态重写 + 运行时容器注入
仅靠 SCSS @mixin clearfix 不够，必须确保生成的选择器在 DOM 中有对应挂载上下文。Vite 子应用需配置 postcss-prefix-selector 插件，将所有顶层类名（包括 .clearfix）自动包裹进容器选择器。
示例配置（postcss.config.js）：
module.exports = {
plugins: [
require('postcss-prefix-selector')({
prefix: `.micro-app-container[data-app="${process.env.MICRO_APP_NAME}"]`,
exclude: [/^html$/, /^body$/],
}),
],
}
同时，在子应用挂载前，主应用需确保容器 DOM 元素已带有 data-app 属性：<div id="subapp-order" data-app="order"></div>。否则重写后的 .micro-app-container[data-app="order"] .clearfix 永远不会匹配任何节点。
最容易被忽略的一点：第三方 UI 库自带的 clearfix
Element Plus 的 el-row、Ant Design 的 Row 组件内部可能隐式依赖 clearfix 实现栅格清除浮动。如果你只隔离了自己写的 .clearfix，但没处理 UI 库的 reset 文件，污染照旧发生。
验证方式：
- 打开 DevTools → Elements → 搜索
clearfix，确认结果全部来自主应用注入的样式表 - 检查子应用构建产物中是否还存在
node_modules/element-plus/theme-chalk/src/common/var.scss或类似路径的 reset 片段 - 运行
Array.from(document.styleSheets).filter(s => s.href?.includes('normalize'))，结果应为空数组
真正起效的隔离，不在命名是否规范，而在所有 CSS 字节流是否经过同一道“容器闸门”——漏掉任意一个入口（@import、link、style.textContent、UI 库内置 reset），整个隔离链就断了。
