第1节 原生CSS的痛点：从“样式表”到“样式工程”的挑战
想象一下，你正在为一个网站设计一套精美的主题色。主色调是一种特别的蓝色，它出现在按钮、链接、标题边框等几十个地方。某天，产品经理希望将这个蓝色调得更亮一些。于是，你打开样式文件，开始使用“查找并替换”功能，小心翼翼地修改每一个颜色代码。这个过程不仅枯燥，还极易出错——万一漏掉一处，或者把另一个不该改的蓝色也改了，页面的视觉统一性就被破坏了。这个场景，正是无数前端开发者每天都要面对的、源自原生CSS的典型困境。本节的核心结论是：原生CSS在设计之初，并未考虑到现代大型、复杂Web应用的开发需求，它在代码复用、维护性和规模化组织方面存在天然的短板，而CSS预处理器的出现，正是为了系统性地解决这些工程化挑战。
“样式表”与“样式工程”的区别
在深入痛点之前，我们需要先理解两个关键概念：“样式表”和“样式工程”。这并非官方术语，但能很好地帮助我们划分认知阶段。
“样式表”是CSS最原始的角色。它就像一份指令清单，逐条告诉浏览器：“这个标题用24像素的粗体字，那个按钮的背景是红色。”在这个阶段，我们关注的是单一样式规则的书写，目标是为一个或几个页面添加静态的装饰。代码规模通常较小，一个人就能轻松管理。
而“样式工程”则是一个完全不同的维度。当你的项目成长为一个拥有数百个页面、数十个可复用组件、需要支持多种主题和复杂交互的Web应用时，CSS就不再是简单的“表”了。它变成了一个需要被设计、架构、测试和维护的“工程系统”。这时，你需要考虑：如何保证整个网站的颜色、间距等设计元素绝对一致？如何让多个开发者高效协作而不产生样式冲突？如何让样式代码像软件一样，具备可复用、可扩展、易于修改的特性？从“样式表”到“样式工程”的跃迁，是前端开发复杂化的必然结果，也是原生CSS开始力不从心的地方。
原生CSS的“阿喀琉斯之踵”
那么，具体是哪些特性让原生CSS在应对“样式工程”时捉襟见肘呢？让我们顺着一个真实的开发流程，看看问题是如何一步步浮现的。
首先是变量（或常值）的缺失。在编程中，变量是基石。你可以定义一个primaryColor，然后在任何地方使用它。但在原生CSS中，一个颜色值、一个字体大小、一个边框半径，都是以“魔法数字”的形式硬编码在样式规则里的。就像开篇的例子，任何全局性的设计变更，都变成了一场体力与眼力的双重考验。你无法声明“这是我们品牌的主色”，只能一遍遍地重复书写同一个十六进制色码。
接着是选择器重复与嵌套的缺失。假设你要为一个卡片组件写样式，它的结构是.card > .card-header > .card-title。在原生CSS中，你不得不这样写：
- .card { /* 一些样式 */ }
- .card .card-header { /* 一些样式 */ }
- .card .card-header .card-title { /* 一些样式 */ }
你不得不重复书写.card和.card-header这些选择器。这不仅让代码变得冗长，更重要的是，它割裂了样式与HTML结构的视觉关联。当你看CSS代码时，无法直观地感受到这个.card-title是深深嵌套在卡片结构内部的。这种重复和结构模糊性，在组件化开发中会迅速放大代码体积并降低可读性。
再者是逻辑处理能力的薄弱。CSS几乎没有任何编程语言中常见的逻辑结构。你想根据不同的条件应用不同的样式吗？想循环生成一系列相似的样式规则（比如为不同间隔的margin类）吗？在原生CSS中，这要么不可能，要么需要极其繁琐的重复劳动。例如，创建一个从mt-1到mt-10（margin-top从1px到10px）的工具类，你需要老老实实写10条几乎一样的规则。这种机械劳动，正是工程师们渴望用自动化工具来消除的。
最后是模块化与代码组织的困境。随着项目变大，把所有样式塞进一两个巨大的.css文件是灾难性的。你希望按功能或组件拆分文件。原生CSS提供了@import，但它有一个致命缺点：每个@import都会产生一次额外的HTTP请求（除非用构建工具手动合并），这会拖慢页面加载速度。因此，开发者常常被迫将所有代码合并到一个文件中，牺牲了代码的物理结构清晰度，使得维护和多人协作变得异常困难。
从个人博客到电商平台：痛点的放大镜
我们可以通过两个案例，更具体地感受这些痛点。
第一个是个人博客。在初期，你可能只有三五篇文章，样式简单。这时原生CSS游刃有余。但当你决定添加一个深色模式主题时，问题来了。你需要为每一个涉及颜色的样式规则，都写一份对应的媒体查询或类名覆盖。例如，不仅要写body { background: white; color: black; }，还要写@media (prefers-color-scheme: dark) { body { background: black; color: white; } }。你会发现，几乎所有颜色相关的规则都需要重复一遍。这种重复不仅是工作量的倍增，更埋下了未来修改时两边不同步的隐患。此时，你已经开始触及“样式工程”的边界。
第二个是大型电商平台。这里有成百上千个UI组件：按钮、导航栏、商品卡片、模态框、表单……每个组件又有多种状态（默认、悬停、点击、禁用）。设计系统要求所有地方的主色、圆角、阴影深度都必须严格一致。如果没有变量，任何一个设计规范的微调，都需要一个团队花数天时间进行全局搜索和验证。组件之间的样式嵌套关系复杂，CSS文件可能长达数万行。没有良好的模块化机制，不同团队开发的组件样式极易相互污染，产生难以调试的样式冲突。在这个场景下，使用原生CSS进行开发和维护，其成本和风险是难以承受的。这迫使前端团队必须寻找更强大的工具和方法论，也就是转向“样式工程”的实践。
关于原生CSS的两个常见误解
在指出原生CSS的痛点时，我们也需要澄清一些常见的误解，这能帮助你更客观地看待它的定位。
误解一：原生CSS一无是处，应该被完全取代。 绝非如此。CSS本身是一门极其强大和成功的样式语言，它负责的最终样式渲染，是任何工具都无法替代的。预处理器并不生产CSS，它们只是CSS的“增强型作者工具”。所有预处理器的代码，最终都必须编译成标准的、浏览器能理解的原生CSS。我们讨论的痛点，集中在“开发体验”和“大型项目管理”层面，而非CSS的渲染能力本身。
误解二：这些痛点都可以用CSS新特性（如CSS变量）解决。 CSS确实在持续进化，例如CSS自定义属性（俗称CSS变量）的出现，就部分解决了变量共享的问题。然而，CSS变量的动态性（可以在运行时用JavaScript修改）既是优点，也带来了与预处理器变量（编译时确定）不同的使用场景和复杂度。更重要的是，预处理器的能力是一个集合，包括嵌套、混合、函数、逻辑控制等。原生CSS的标准化和普及是一个漫长的过程，例如嵌套规则直到最近才在部分浏览器中实现。在可预见的未来，预处理器提供的是一套更成熟、更完整、且能立即投入生产的增强开发方案。
动手之前先思考
在急不可耐地想要学习预处理器之前，不妨先基于我们今天讨论的痛点，进行一些思考和练习，这能让你带着更明确的目标进入后续的学习。
练习一：审视你的项目。 打开你最近正在维护或学习的一个前端项目，找到它的CSS文件。尝试找出至少三处存在“魔法数字”（如重复的颜色值、尺寸）的地方。如果现在需要将这些值统一调整，你需要修改多少个位置？这个过程让你感到安心还是焦虑？
练习二：模拟一次设计变更。 假设你项目的品牌主色要从 #3498db 改为 #1abc9c，并且所有使用这个颜色的按钮，在悬停时颜色要加深20%。在不使用任何新工具的前提下，请你大致描述一下，在原生CSS中完成这个变更需要哪些步骤？其中最容易出错或遗漏的环节是什么？
练习三：想象代码组织。 如果让你把一个庞大的、有2000行代码的styles.css文件拆分成更易于管理的多个小文件，你会按什么原则来拆分？（例如：按页面、按组件、按功能？）拆分之后，你打算如何将它们重新组合起来供浏览器使用？这个过程中，你预见到会遇到什么麻烦？
本节要点回顾
从清单到系统：现代前端开发要求CSS从静态的“样式表”进化为可工程化的“样式系统”，而原生CSS在此转型中基础支撑不足。
变量的缺失：无法定义和复用设计令牌（如颜色、字号），导致全局样式修改成为高风险、高成本的体力劳动。
选择器与结构的冗余：缺乏嵌套语法导致选择器重复书写，割裂了样式规则与HTML结构的直观对应关系，代码冗长。
逻辑能力薄弱：不具备条件、循环等基本编程逻辑，无法自动化生成规律性样式，阻碍了代码的抽象和复用。
模块化之困：原生的@import机制存在性能缺陷，迫使开发者在代码组织清晰度和页面性能之间做出艰难取舍。