17370845950

最直接有效的方式是采用命名空间式类选择器，即为类名添加项目/模块前缀（如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 类生效了”，排查路径立刻变短
• 命名空间不是增加复杂度，而是把隐含的依赖关系显性化、可管理