css类名加前缀是最直接有效的命名空间方案，如.user-profile-button可避免多团队协作时的样式冲突，但需控制长度、避免泛化前缀，并配合postcss-prefixer等工具与@layer、shadow dom等技术协同实现完整隔离。
CSS类名加前缀是最直接有效的命名空间方案
大项目里多个团队共用同一份样式表，.button 这种通用名一撞就冲突。不靠工具、不靠约定，最稳的方式是手动加业务或模块前缀：.user-profile-button、.cart-item-price。这不是“语义化退步”，而是把命名权收回到具体上下文里。
常见错误现象：.modal 被弹窗组件和表单校验提示同时使用，结果一个 z-index 改动让另一个消失；.title 在文章页和后台管理页渲染效果完全不一致。
- 前缀长度控制在 2–4 个单词内，太长影响可读性（如
.admin-dashboard-sidebar-navigation-toggle-button就过度了） - 避免用
global-、base-这类泛化前缀，它们实际起不到隔离作用 - 如果用 CSS-in-js（如 Emotion），
css函数生成的样式默认已局部化，但导出的 className 仍需前缀，否则透出到 DOM 后仍可能被全局样式污染
PostCSS + postcss-prefixer 是轻量级自动化补救手段
已有大量未加前缀的老代码，又不能全量重写？postcss-prefixer 可以在构建时给所有规则自动加前缀，比手改快，也比引入 CSS Modules 改动小。
使用场景：迁移期过渡、第三方 ui 库定制、微前端子应用样式隔离。
立即学习“前端免费学习笔记（深入）”；
- 配置里必须指定
prefix和include范围，否则会把html、body甚至@keyframes都套上，导致动画失效或基础样式错乱 - 它不处理
:global()或:local()语法，也不识别 CSS-in-JS 的动态 class 插入，仅作用于静态 CSS 文件 - 注意和
autoprefixer的执行顺序——postcss-prefixer必须在autoprefixer之前，否则带厂商前缀的属性（如-webkit-transform）可能被误匹配并重复加前缀
@layer 声明层叠顺序，但无法替代命名空间
@layer 解决的是“谁该后生效”的问题，不是“谁该互不干扰”。哪怕你把所有业务样式都包进 @layer app { ... }，只要两个地方都写了 .header { color: red; }，最终还是后者胜出——层叠没变，冲突照旧。
容易踩的坑：@layer 不提供作用域，也不改变选择器权重。它只是给 !important 和源码顺序之外多一个可控层级。
- 只在需要精细控制第三方样式（如 Tailwind、bootstrap）与自定义样式优先级时才用
@layer - 不要用
@layer替代模块化命名，那相当于用交通灯管住车速，却不给每辆车发独立车牌 - 目前 safari 15.4+、chrome 101+、firefox 97+ 支持，旧版浏览器需回退到
@import顺序控制，兼容性要兜底
微前端中 CSS 隔离必须靠运行时沙箱或 Shadow DOM
子应用各自打包 CSS 并注入 ，光靠命名前缀挡不住全局样式泄漏。比如主应用设了 html { font-size: 14px; }，子应用的 rem 计算就全乱了。
真实使用场景：qiankun、micro-app 等框架接入老系统，字体、颜色、间距全部错位。
- Shadow DOM 是最彻底的方案，但要求组件用 Web Components 实现，且部分 CSS 特性（如
::backdrop、:focus-visible）穿透行为不一致 - qiankun 的样式沙箱默认启用，但它依赖动态插入/移除
<style></style>标签，若子应用内联了style属性或用了insertRule，依然会逃逸 - 更隐蔽的问题：CSS 变量（
--primary-color）是全局的，即使 DOM 隔离了，变量值仍会被覆盖，必须配合:host或 scoped 变量前缀二次约束
复杂点在于，命名空间不是单点技术选择，而是贯穿设计、开发、构建、集成各环节的约束习惯。最容易被忽略的是：CSS 变量、字体声明、伪元素样式、以及所有没显式限定作用域的全局规则，它们不会因为你加了 .user- 前缀就自动变安全。