最直接有效的方式是采用命名空间式类选择器，即为类名添加项目/模块前缀（如user-profile-），按“前缀-功能-状态”格式命名，避免语义化单词重复，并禁用嵌套选择器与!important。
避免 CSS 选择器冲突最直接有效的方式，是让类名自带“作用域”——也就是采用命名空间式类选择器。它不依赖 HTML 结构嵌套或 CSS 优先级硬拼，而是从源头上隔离样式影响范围。
用项目/模块前缀统一约束类名
给每个功能模块或业务区域的类名加上明确前缀，比如 user-profile-、cart-sidebar-、admin-dashboard-。所有相关样式都只作用于带该前缀的类，天然避开全局污染。
- 推荐格式：前缀-功能-状态，如
product-card-hover、form-input-error - 避免仅靠语义化单词（如
title、list），这类名称极易在不同模块中重复出现 - 团队可制定命名规范文档，并配合 ESLint 或 Stylelint 插件做提交前校验
组件级样式边界需靠类名而非结构
不要依赖 .sidebar .item .label 这类多层嵌套选择器来限定作用域——它脆弱、难维护，且一旦 DOM 结构微调就失效。改用单一层级、带命名空间的类名：
- ❌
.sidebar .item .label { color: #333; } - ✅
.sidebar-item-label { color: #333; } - 组件内所有样式都基于这个唯一类名展开，即使被插入到任意父容器中也不会误匹配
第三方 UI 库也要做轻量封装
引入 Ant Design、Element Plus 等库时，别直接用原始类名（如
.el-button）。在项目中包裹一层自有命名空间：
- 写一个
ui-button-primary类，内部通过@apply（Tailwind）或composes（CSS Modules）复用库的样式 - 或用 CSS-in-JS 的 className 映射方式，在组件渲染时注入带前缀的类名
- 这样既保留库能力，又确保项目样式体系可控、可追溯
慎用 ID 和 !important 来“强行覆盖”
ID 选择器权重高但不可复用；!important 会破坏层叠逻辑，让后续维护变成猜谜。命名空间方案的价值，就在于用清晰的命名代替暴力压制：
- 遇到“怎么又覆盖不了？”先检查是否两个模块用了相同基础类名，而不是加权重
- 把“为什么这个按钮变蓝了”这种问题，变成“哪个
xxx-button类生效了”，排查路径立刻变短 - 命名空间不是增加复杂度，而是把隐含的依赖关系显性化、可管理
