以下内容摘自《CSS揭秘》一书
你很可能听说过像 Stylus（http://stylus-lang.com/）、Sass（http://sass-lang.com/）或 LESS（http://lesscss.org/）这样的 CSS 预处理器。它们为 CSS 的编写提供提供了一些便利，比如变量、mixin、函数、规则嵌套、颜色处理等。
如果使用得当，它们在大型项目中可以让代码更加灵活，而 CSS 自身在这方面确实有很大局限。只要我们在代码健壮性、灵活性和 DRY 方面有追求，就会感受到 CSS 在这方面的局限。不过，预处理器也不是完美无缺的。
-
CSS 的文件体积和复杂度可能会失控。即使是简洁明了的源代码，在经过编译之后也可能会变成一头从天而降的巨兽。
-
调试难度会增加，因为你在开发工具中看到的 CSS 代码并不是你写的源代码。不过这个问题已经大大好转了，因为已经有越来越多的调试工具开始支持 SourceMap。SourceMap 是一种非常酷的新技术，正是为了解决这个痛点而生的，它会告诉浏览器哪些编译生成的 CSS 代码对应哪些预处理器 CSS 代码，精确到行号。
-
预处理器在开发过程中引入了一定程度的延时。尽管它们通常很快，但仍然需要差不多一秒钟的时间来把你的源代码编译成 CSS，而你不得不等待这段时间才能预览到代码的效果。
-
每次抽象都必然会带来更高的学习成本，每当有新人加入到我们的代码库中，这个问题都会重演。他要么已经对我们选择的这门预处理器“方言”很熟悉，要么得从头学。这意味着我们要么强制协作者接受我们的选择，要么花费额外的时间来培训，而这两者都不是我们想要的。
-
另外，别忘了还有抽象泄漏法则：“所有重大的抽象机制在某种程度上都存在泄漏的情况。”预处理器是由人类写出来的，就像所有由人类写出来的大型程序一样，它们有它们自己的 bug。这些 bug 可能会潜伏很久，因为我们很少会怀疑预处理器的某个 bug 才是我们CSS 出错的幕后元凶。
除了上面列出的这些问题，预处理器还可能导致这种风险：网站开发者可能会不自觉地“依赖”和“滥用”。因为在某些时候，预处理器并不必要。比如在小型项目中；或者在未来，说不定预处理器最受欢迎的那些特性都被加入了原生 CSS 中。很惊讶吗？没错，很多受预处理器启发的特性都已经以各种方式融入到原生 CSS 中了。
-
有一份关于（跟变量类似的）自定义属性的草案，叫作 CSS 自定义属性暨层叠式变量（http://w3.org/TR/css-variables-1）。
-
CSS 值与单位（第三版）中的
calc()函数，不仅在处理运算时非常强大，而且已经得到了广泛的支持，当下可用。 -
CSS 颜色（第四版）（http://dev.w3.org/csswg/css-color）引入的
color()函数会提供颜色运算方法。 -
关于嵌套，CSS 工作组内部正在进行一些正式的讨论，甚至以前还有过一份相关的草案（ED）。
请注意，这些原生特性通常比预处理器提供的版本要强大得多，因为它们是动态的 。举个例子，预处理器完全不知道如何完成 100% - 50px 这样的计算，因为在页面真正被渲染之前，百分比值是无法解析的。但是，原生 CSS 的 calc() 在计算这样的表达式时没有任何压力。与此类似，下面这样的变量玩法在预处理器中是不可能做到的：
1 ul { --accent-color: purple; } 2 ol { --accent-color: rebeccapurple; } 3 li { background: var(--accent-color); }
你看清楚这段代码的意图了吗？在有序列表中，列表项的背景色将是
rebeccapurple；但在无序列表中，列表项的背景色将是
purple。试试用预处理器能否做到！当然，在这个例子中，我们可以直接使用后代选择符，只不过这个例子的重点在于向你展示 CSS 的原生变量所具备的动态性。
上面提到的原生 CSS 特性绝大多数在目前还没有得到很好的支持，因此在很多情况下，如果可维护性很重要（它确实很重要），使用预处理器是不可避免的。我的建议是，在每个项目开始时使用纯 CSS，只有当代码开始变得无法保持 DRY 时，才切换到预处理器的方案。为了避免可能发生的“依赖”或“滥用”，在引入预处理器的问题上需要冷静决策，不应该在每个项目一开始时就不动脑筋顺着惯性来。