用CSS工具提升大型项目样式维护性

大型项目里 CSS 维护难，问题从来不是“写得不够快”，而是改一处、崩三处——类名冲突、变量散落、样式隐式依赖、新人看不懂结构。工具本身不解决问题，但用对了，确实能卡住常见错误入口。

先从一个核心痛点说起：BEM 类名。

为什么 BEM 类名必须严格手写或靠工具生成

BEM 不是“多打几个下划线”的体力活。它的真正价值在于，用命名强制表达作用域边界。一旦写成 .button--primary 却漏掉双连字符，或者写成 .card__header__title（嵌套两层 Element），隔离能力就被破防了。

• 常见错误现象：!important 越来越多、审查元素时发现样式被远在 components/modal/modal.less 里的同名 .button 覆盖
• JS 操作类名也必须完全匹配：el.classList.add('user-card__a vatar--loading')，千万别拼 'user-card__a vatar' + '--' + state，容易少个连字符或大小写错
• VS Code 配 PostCSS BEM 插件或自定义 snippet，永远比靠人盯更可靠；Webpack/Vite 项目里，强烈建议用 postcss-bem 在编译期校验类名格式

再说说 Less 变量和 Mixin。

Less 变量和 Mixin 怎么避免“越用越乱”

变量不是往 variables.less 里堆颜色就行。真正的卡点在于：谁改、谁用、改了影响谁——得有可见路径。

• 变量命名必须带语义：用 @color-text-primary，别写 @blue-500；后者在设计系统换色后立刻失效
• Mixin 必须纯样式化、参数化：.flex-center() 可以，但 .card-style() 这种包裹整块选择器的写法会锁死结构，调用方无法覆盖内部某条规则
• 禁止在组件文件里重定义同名变量——Less 不报错，但导入顺序决定最终值，调试时根本看不出哪一层覆盖了哪一层

最后，来聊聊那个容易被人忽略的 index.less。

为什么 index.less 文件不能省，也不能乱写

index.less 是模块的“对外接口”，不是偷懒的汇总文件。它唯一的任务是声明本模块的依赖关系和导出内容。

• 错误写法：pages/dashboard.less 直接 @import "../../components/button/button.less" —— 一旦 button 内部重构、拆分文件，这里立刻报 Undefined mixin
• 正确写法：每个模块根目录放 index.less，只写三行：@import "variables"; @import "mixins"; @import "button";；业务页只 @import "../index"
• 根目录 styles/index.less 按层级顺序导入：@import "base/index"; @import "components/index"; @import "pages/index";，顺序错了，@color-text-primary 可能还没定义就被用了

说到底，真正卡住维护滑坡的，从来不是某个工具没装，而是变量谁都能改、类名谁都能乱写、index.less 谁都敢跳过——这些地方没有机器约束，全靠人自觉，迟早要出问题。