在中小型团队的实际项目中，CSS往往是最容易被低估的一环。当页面模块增多、人员流动频繁，样式冲突和浏览器兼容问题就会集中爆发。本文结合真实项目经验，梳理一套可落地的应对思路，帮助你在复杂场景下保持样式可控。
一、样式冲突的根本原因与命名约束
样式冲突通常不是因为CSS本身难写，而是因为缺乏作用域概念。传统全局样式表中，所有选择器都处于同一命名空间，两个人各自写了.btn类，后加载的就会覆盖前面的。项目里曾出现过登录按钮在A页面正常、B页面变方角的现象，排查后发现是公共组件库和业务代码都定义了.btn。
解决这类问题，第一步是建立命名约束。BEM（块、元素、修饰符）是比较成熟的方案：块名独立、元素用双下划线、修饰符用双连字符。例如card__title--large能清晰表达归属与变体，降低撞名概率。下面是一段采用BEM思路的样式代码：
/* 卡片块 */
.card {
border: 1px solid #e5e5e5;
border-radius: 8px;
}
/* 卡片标题元素 */
.card__title {
font-size: 16px;
margin: 0;
}
/* 大号修饰符 */
.card__title--large {
font-size: 20px;
}
不过纯手工BEM在大型项目里仍可能疲劳出错。更彻底的做法是用CSS Modules，它在构建期把类名哈希化，实现局部作用域。在Vue或React项目里开启后，你写的styles.btn会被编译成_btn_1a2b3_4，不同文件互不影响。缺点是类名可读性下降，需要配合源码映射排查。
二、浏览器兼容的渐进增强策略
兼容问题集中在老版本WebKit、IE11以及部分移动端内核。它们对flex布局、grid布局、CSS变量支持不完整。如果强行统一写法，要么牺牲新特性，要么放弃旧用户。渐进增强的核心是先写基础可用布局，再用特性查询包裹高级能力。
例如下拉菜单用float做底线，支持flex的浏览器再切换为更灵活的排列。代码示例如下：
.menu {
/* 旧浏览器底线 */
overflow: hidden;
}
.menu li {
float: left;
margin-right: 10px;
}
/* 新浏览器增强 */
@supports (display: flex) {
.menu {
display: flex;
overflow: visible;
}
.menu li {
float: none;
margin-right: 0;
}
}
这种写法让低端设备也能看到菜单，现代浏览器获得更好排版。需要注意@supports本身在IE11不支持，所以底线样式必须不依赖它。项目里我们还会用PostCSS的autoprefixer自动补前缀，减少手工兼容成本。
三、层叠规则与优先级的正确使用
很多人遇到冲突就加!important，结果下一个人只能加更多!important，优先级战争就此开始。其实CSS优先级是可计算的：行内样式权重千级，ID是百级，类与属性是十级，标签是个级。理解这点能少用暴力覆盖。
我们曾把主题色放在:root的变量里，但某个旧组件用了ID选择器写死颜色，权重过高导致变量失效。后来统一规范，禁止在业务代码用ID选样式，冲突率明显下降。下面用表格说明常见选择器权重：
| 选择器类型 | 示例 | 权重等级 |
|---|---|---|
| 行内样式 | style属性 | 1000 |
| ID选择器 | #header | 100 |
| 类选择器 | .btn | 10 |
| 标签选择器 | div | 1 |
当必须覆盖第三方组件样式时，优先用更高具体性而非!important，比如包裹一层父级类提升权重。实在需要!important也应写在工具类里并加注释说明场景。
四、用预处理器统一设计令牌
重复色值、间距散落在各处，是后期维护噩梦。Sass或Less的变量与mixin能把设计令牌集中管理。我们项目里定义了$primary、$space-md等变量，换肤只需改一处。
下面是一段Sass代码示例，展示如何用mixin统一卡片阴影：
$primary: #2c7be5;
$space-md: 16px;
@mixin card-shadow {
box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
}
.card {
padding: $space-md;
border-left: 4px solid $primary;
@include card-shadow;
}
预处理器也带来编译依赖和调试源映射问题。建议把变量文件独立，并在构建里开启source map，方便在浏览器里定位到原始scss行号。这样既能享受抽象便利，也不丢排查效率。
五、工程化层面的长效保障
单靠个人规范不够，需要在工具链上加护栏。我们在CI里接入stylelint，禁止ID选择器、限制!important、强制BEM命名。提交前自动格式化，把冲突消灭在合并前。
同时把全局样式拆分为基础层、组件层、业务层，用ITCSS倒置三角管理优先级。基础层只放reset和变量，业务层权重自然最高而不混乱。配合上文的CSS Modules，整体样式冲突率从每月十几起降到几乎为零。这套组合拳比追新框架更实在，也更适合存量项目渐进改造。