CSS 可维护性实践：样式失控通常不是技术问题，而是边界问题
前端项目里，CSS 经常是最容易被低估、也最容易失控的一层。
功能开发阶段，大家通常更关注接口、状态、交互、性能；样式经常被视为“最后补一下”。结果项目做久了以后，最让人不敢动的反而是样式文件。
CSS 在项目里经常 问题表面看起来像“技术选型不对”，其实更常见的原因是边界不清。
样式为什么这么容易变脏
因为 CSS 默认就是全局生效、相互影响的。
这意味着只要你没有主动管理边界，就很容易出现：
- 修改一个类名影响多个页面
- 提高优先级去覆盖旧规则
- 新样式不断叠加补丁
- 组件样式和页面布局样式混在一起
写的时候都合理，叠久了就开始变乱。
最常见的反模式：为了解决一个问题，再加一层覆盖
项目里的 CSS 最终常常会演化成这样：
1.card-title { 2 color: #333; 3} 4 5.page-a .card-title { 6 color: #111; 7} 8 9.dialog .page-a .card-title { 10 color: #000; 11}
每一次覆盖都在解决眼前的问题，但长期看，其实是在提高整套样式系统的耦合度。
样式的职责要分层
一个更稳定的方式，是把样式按职责拆开，而不是全部混在一起。
常见可以分为：
- 基础样式
- 组件样式
- 页面布局样式
- 状态样式
基础样式负责：
- 重置
- 字体
- 颜色变量
- 间距变量
组件样式负责组件本身的外观。
页面样式负责页面结构和布局，不应该直接侵入组件内部细节。
命名不是形式主义
很多人觉得 CSS 命名规范只是团队洁癖，其实不是。
命名说到底是在表达边界。
比如：
.button.user-card.article-list__item
这些名字会直接影响后来的人如何理解和使用这个样式。
如果命名过于模糊，例如：
.box.item.left.active
那么后续维护者几乎只能靠猜。
不要让页面直接修改组件内部
一个很常见的问题是，页面层样式直接写到组件内部类名上。
例如某个页面为了调整卡片标题颜色，直接覆盖了组件里的 .card-title。这样虽然快，但组件边界已经被打破。
更稳的做法是：
- 通过 props 或变体控制样式
- 通过外层 class 控制布局
- 必要时提供明确扩展点
而不是让页面随便改组件肚子里的结构。
工具能帮忙，但不能代替设计
无论你用的是：
- CSS Modules
- Sass
- Tailwind CSS
- styled-components
它们都只能帮你管理样式，不会自动帮你设计边界。
如果结构本身就是乱的，换工具并不会根治问题。
稳定的样式系统，核心还是：
- 样式归谁管
- 哪一层能改哪一层
- 哪些是通用规范
- 哪些是局部特例
变量体系比复制颜色更重要
CSS 在项目里经常 维护难，不是规则复杂，而是设计令牌缺失。
例如颜色、边距、字号、圆角全部写死，后面你一旦想统一调整视觉风格，就会发现全项目到处散落着重复值。
比起不停复制 #333、16px、8px，更应该做的是先建立变量。
写在最后
CSS 可维护性的关键，不在于选了多高级的方案，而在于有没有把样式边界设计清楚。
只要职责明确、命名清晰、组件和页面各守边界，样式就会越来越稳；反过来，如果一切都靠覆盖和补丁推进，再现代的技术栈也救不了后期失控。