Sass预处理器使用指南
写样式写到想撞墙的时候，很多人都会冒出同一个念头：能不能让 CSS 像写程序一样写？变量、复用、嵌套、条件判断，哪怕只是少敲几行重复代码，都能让心情变好一点。于是，Sass 这个老伙计又被请了回来。它不是什么新框架，也不是什么炫技神器，而是一套能让你把样式写得更有条理的工具。用了它以后，你会发现，改一处颜色，不用再全局搜索；调一个间距，不用担心漏掉哪个角落。
第一次接触 Sass 的时候，我是在一个混乱的项目里。那天页面的按钮颜色飘忽不定，设计师上午说用这个蓝，下午说要那个蓝，代码里却躺着五六种相近的颜色值。我试着把颜色提到一个文件顶部，可普通 CSS 不认变量，只能老老实实复制粘贴。后来换成 Sass，用一个变量把颜色兜住，改一次就全局生效。那一刻的感觉，像给乱成一团的耳机线打了个结，顺滑得让人想笑。
Sass 真正的威力不在炫技，而在把重复的事情交给它。比如项目中总有几个长得差不多的卡片，区别只在边框颜色和阴影深浅。用 Sass 的 mixin，可以把公共样式打包，需要的时候传个参数就行。这样写出来的代码更短，读起来也更像在描述意图，而不是在堆砌属性。时间一长，页面结构慢慢浮出水面，不再是一堆零散的规则，而是一张有逻辑的网。
还有一个让我印象深刻的变化，是对层级的理解。普通 CSS 里，为了不污染全局，常常被迫把类名写得又臭又长，像在给自己设路障。Sass 的嵌套写法把父子关系收拢在一起，视觉上更紧凑，心智负担也小了。不过嵌套这事容易上瘾，写深了会发现选择器越来越重，调试越来越难。所以后来我给自己立了个规矩：三层是红线，超过就拆。克制一点，反而更自由。
工具只是工具，能不能用好，最后拼的还是习惯。我见过有人把 Sass 写成另一门完全读不懂的语言，变量满天飞，函数绕来绕去，最后还不如老老实实写 CSS。Sass 的意义，不在于能写出多复杂的样式，而在于能不能把复杂的事情变简单。文件怎么拆，命名怎么起，变量怎么管，这些琐碎决定，比语法本身更影响长期体验。
别让颜色到处流浪
颜色是最容易失控的地方。一个项目刚上线时，可能只有十来种颜色，可随着需求叠加，渐变色、强调色、状态色一拥而上，CSS 文件里很快就五颜六色。如果没有一个统一的出口，改颜色就会变成盲人摸象。
Sass 的变量不是为了炫技，而是为了让人心里有底。把常用颜色收进一个变量文件，用语义化的名字去称呼它们，比如 $color-primary、$color-bg-surface。这样写样式的时候，不需要再盯着十六进制值发呆，只要确认语义对不对。哪天品牌色换了，只需要改变量，不用去样式文件里大海捞针。
有时候颜色还要分状态，hover、active、disabled，每种状态下颜色都会微调。这时候可以用一个小函数，把基础颜色传进去，返回明度调整后的结果。这样既保持了统一，又留出了弹性。颜色不再是一个个孤立的值，而是一套可以推导的逻辑。页面看着舒服，很多时候不是因为设计多惊艳，而是因为颜色用得克制。
我见过一个项目，按钮颜色多达二十几种，理由是“不同场景要用不同色”。后来换成 Sass，把颜色收敛成三种基调，用透明度和饱和度表达差异。结果不但代码量减少了一半，视觉上反而更统一。颜色一安定，页面气质就稳住了。
像搭积木一样写样式
写样式最怕的不是复杂，而是重复。导航、卡片、表单，这些组件在页面里反复出现，可样式却总有些微差别。如果每种差别都新写一套规则，代码会像不断摊开的煎饼，越来越大，越来越脆。
Sass 的 mixin 就像一块块积木，把公共样式打包，需要的时候拿出来拼装。比如一个简单的圆角加阴影的组合，可以写成一个 mixin，哪个组件要用，传个参数就行。这样既避免了复制粘贴，又保留了调整的余地。更重要的是，它让样式有了“默认”和“例外”的区分，而不是一上来就硬编码。
参数还可以有默认值，这样大多数情况不用关心细节，只在必要的时候才介入。写代码像搭积木，先搭整体，再换零件。组件之间的边界清楚了，改动的时候也就不容易牵一发而动全身。
有时候 mixin 会变得臃肿，参数越来越多，这时候就要警惕。是不是把太多不相关的样式硬塞进同一个 mixin？是不是应该拆成更小的单元？工具再顺手，也经不起无节制的堆砌。写得顺手的时候尤其要停一停，看看能不能更轻一点。
把结构叠清楚
CSS 本身是平铺的，可页面的结构是有层级的。Sass 的嵌套写法让人可以用视觉上的缩进，表达这种层级关系。父元素和子元素的样式挨在一起，读起来更顺，也更容易理解上下文。
比如一个菜单，列表、链接、图标、状态，这些样式如果散落在文件各处，维护起来像在拼图。用嵌套把它们收拢在一起，结构就像树一样展开。修改某个状态下的样式，不用再靠命名去猜测位置，直接在对应的层级里找就行。
但嵌套也有陷阱。写得越深，生成的选择器就越长，权重越高，调试就越费劲。有时候为了图省事，一层层嵌下去，结果样式像缠在一起的耳机线，理都理不顺。所以嵌套要有节制，像写大纲一样，只把必要的层级写进去，细节部分交给类名去区分。
我习惯把嵌套当成梳理思路的工具，而不是偷懒的出口。写之前先问自己：这个子元素是不是真的只在这个父元素里出现？如果是，那嵌套合理；如果不是，那就把它拎出来，单独写。结构清不清楚，改起样式来差别很大。
把文件拆明白
Sass 真正改变工作方式的，其实是文件拆分的能力。一个巨大的样式文件，读久了容易晕，改起来更晕。把变量、混合、组件、页面级别的样式分开存放，就像把书分章节，想找哪部分就翻到哪部分。
变量和函数放在最前面，因为它们是被依赖的。公共的 mixin 和基础样式放在中间，组件样式再往后，页面覆盖的样式最后。这样一种自底向上的结构，让新成员也能很快找到该改哪里。导入的方式让文件之间保持联系，又不至于互相干扰。
命名和路径的约定也很重要。文件名尽量反映它所承担的角色，而不是它“看起来像什么”。这样团队协作的时候，不会因为命名不一致而产生重复代码。文件拆得合理，改样式就像整理抽屉，哪里空了补哪里，不会手忙脚乱。
拆分也不是越多越好。拆得太碎，导入和管理的成本就会上升。找到一个平衡点，让每个文件都有明确的职责，又不至于到几十上百个，才是可持续的做法。
别让工具替你思考
用了 Sass 以后，很容易产生一种幻觉：代码变短了，效率变高了，就等于质量变好了。可工具终究是工具，它不会替我们做决定。变量命名不清，文件结构混乱，嵌套过深，这些问题并不会因为用了 Sass 就自动消失。
真正让项目好维护的，是围绕工具建立的习惯。比如提交前检查有没有多余嵌套，变量是否还在使用，组件边界是否清晰。这些琐碎的纪律，比语法本身更重要。Sass 提供的是可能性，能不能把可能性变成可控的现实，取决于人。
时间久了，会发现 Sass 最有价值的部分并不是那些花哨的功能，而是它让人慢下来的能力。写之前多花一点时间想清楚结构，写的时候克制一点，改的时候轻一点。页面就是这样，慢慢变得清晰、好改、耐看。
写样式这件事，说到底是在和不确定性打交道。需求在变，设计在变，团队在变，能抓住的只有自己的逻辑和习惯。Sass 并不能消除变化，但它能让变化变得可预期。当样式不再四处漏风，改动不再心惊胆战，工作就会多出一点从容。
技术会过时，工具会换代，可把复杂事情变简单的愿望不会变。Sass 像一双旧跑鞋，不显眼，却让人跑得稳一点。把它用好，项目会跟着受益，自己也会受益。写代码写久了，会发现真正的效率，从来不是敲得多快，而是返工少一点，心态稳一点。