SCSS提升CSSDRY技巧全解析

SCSS本身不会自动帮你践行DRY原则，真正起决定作用的是你写代码时的意识与习惯：能否敏锐识别显性重复（如重复的颜色值）更关键的是发现语义重复（如多处“flex居中”背后统一的行为意图），并通过语义化变量（如$color-primary而非$blue-500）、精准抽象的@mixin（如@mixin flex-center并附带清晰注释）、审慎规避@extend陷阱来落地可维护的复用；面对旧项目，不必激进重构，而是用_ _legacy.scss渐进隔离、边改边提、小步清理——因为DRY的本质不是少写几行代码，而是在变化来临时，让你能自信地只改一处，且清楚它影响在哪里。

SCSS 本身不自动执行 DRY 原则，它只是提供了变量、@mixin、@function、@extend 这些工具；真正让 DRY 落地的，是你在写代码时是否主动识别重复、是否愿意多花 30 秒抽象一个 @mixin 或提取一个 $color-primary。

识别“隐形重复”比写变量更重要

很多人只盯着“颜色值相同”“边框写法一样”这种显性重复，却忽略语义层面的重复。比如多个组件都用 display: flex; justify-content: center; align-items: center;，这不只是样式重复，更是“居中行为”的重复表达。

• 常见错误现象：.header, .modal, .card-footer 各自写一遍相同的 flex 居中代码，后期改对齐方式要改三处
• 正确做法：立刻抽成 @mixin flex-center，哪怕当前只用了一次——因为下个组件大概率也要居中
• 判断依据：只要你在写某段样式时心里默念“这我好像刚写过”，就该停手，先查 _mixins.scss 是否已有对应封装

变量命名必须带语义，不能只写 $blue-500

纯色值变量（如 $blue-500）在主题切换或设计系统演进时会迅速失效。DRY 不是“少打几个字”，而是“一处定义，全局语义一致”。

• 错误示例：$blue-500: #2563eb; → 后期设计师把主色改成紫色，你得搜遍所有 $blue-* 并手动替换
• 推荐写法：$color-primary: #2563eb; + $color-primary-hover: #1d4ed8;，再配合 $color-primary-text 等上下文变量
• 关键点：变量名要回答“它在产品中代表什么”，而不是“它在色卡里叫什么”

@extend 的坑：别为了省几行 CSS 损害可维护性

@extend 表面看能复用选择器，但实际会把被扩展的选择器塞进所有引用它的 CSS 规则里，导致最终 CSS 文件体积不可控、调试困难。

• 典型问题：.btn-primary {@extend .btn;} → 编译后所有 .btn 的声明都会出现在 .btn-primary 规则块里，哪怕你只想要 padding 和 font-size
• 更安全替代：@include button-base（用 @mixin 封装真正需要的属性）
• 仅建议场景：极简、完全静态的基类（如 .sr-only），且确认它永远不会拆分职责

重构旧项目时，先建 _legacy.scss 隔离脏代码

直接在老项目里强行推行 DRY，容易引发样式冲突和回归 bug。真实工程中，渐进式隔离比一步到位更可靠。

• 操作步骤：新建 _legacy.scss，把原有全局 CSS @import 进来，但不再允许新代码写入这个文件
• 新增样式一律走 _variables.scss + _mixins.scss + 组件级 SCSS 文件
• 后续每次修改旧样式，都同步补一个对应的 @mixin 或变量，并把原样式替换成调用——不是一次全量重写，而是“改一行，清一点”

最常被忽略的一点：DRY 的成本不在写 @mixin 的那一刻，而在三个月后有人想改 flex-center 的行为时，得翻遍所有用了它的组件确认影响范围——所以每个 @mixin 必须配一句注释说明“它到底承诺了什么”，比如 // 仅居中子元素，不设置 flex-wrap 或 gap。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《SCSS提升CSSDRY技巧全解析》文章吧，也可关注golang学习网公众号了解相关技术文章。