领导：小明，你这个页面在苹果手机上错乱了。
领导：小明，你这两个页面的高度好像不一样啊。
领导：小明，所有这个东西统一调大一点。
小明整天被一些样式细节所困扰，反复调整间距、对齐、适配、统一风格，大量时间消耗在琐碎的 CSS 调试上，导致他根本无法专心编写业务功能代码。这是前端开发中普遍存在的怪圈：业务开发人员在写样式上花费的时间，往往超过了编写核心业务逻辑的时间。
写样式坑多、钱少，一般人根本写不好。
很多人觉得CSS很简单，因为它入门极其容易，只需几行代码就能改变页面的颜色和大小。但CSS也是前端领域最难“掌控”的语言之一。
- 坑多： CSS具有全局作用域、复杂的特异性权重、难以捉摸的层叠规则。改了一行代码，很可能导致十几个原本正常的页面 suddenly 变得奇形怪状。再加上不同浏览器、不同设备（尤其是苹果手机）的渲染差异，样式调试往往是一场噩梦。
- 钱少（价值低）： 从商业角度看，除了极少数视觉驱动型的产品，在大多数项目的排期中，样式调整往往被视为“低价值工作”。老板不会因为你把按钮调得圆润了而给你加薪，但如果因为样式问题导致页面不可用，锅还得你背。
- 写不好： 正因为样式问题琐碎且难以抽象，如果没有严格的规范和工程化手段，一百个开发者会写出一百种风格的代码。有的人用px，有的人用rem，有的人随手写
!important。最终导致样式代码库变得混乱不堪，难以维护。
绝大多数业务开发者并不擅长精细调样式，也不应该把大量精力放在写 CSS 上。让不擅长样式的人反复写样式，本质是资源错配，也是团队工程化不成熟的表现。
我们要在架构层建立前端样式体系。
真正高效的前端团队，不会让业务人员重复造样式轮子，而是在架构层建立一套完整、统一、可复用的前端样式体系。业务层少写甚至不写样式，优先使用架构层封装好的能力，不但能减少开发工作量，还能提升样式质量，保持全站风格统一，后期维护也更简单，改一处即可全局生效。
下面这套样式体系，就是让业务 “少写、不写样式” 的核心支撑。
公共组件库
架构层应当为业务开发人员提供公共组件库。把按钮、输入框、卡片、表格、弹窗、导航等高频 UI 全部封装成稳定、统一的组件，内置样式、交互、适配逻辑。业务人员开发页面时，应当优先使用组件库，不自己手写 DOM 与 CSS，从根源避免风格混乱、适配异常等问题。
公共样式库
当组件库无法满足一些灵活布局或特殊场景时，架构层应该为业务提供公共样式，增加灵活度。使用公共样式库和组件库的核心差别是，组件库更便利，拿来即用；样式库更灵活，适合轻量组合定制。
比如我在设计公共样式时，提供了 content、layout、components、helpers、utilites 这么几类公共样式，分别负责内容排版、布局结构、组件增强、辅助样式、工具类样式。开发人员只需要参考文档例子，在 class 上组合使用即可，不需要自己写新的 CSS 规则。
公共 mixin 库
对于需要复用逻辑的样式场景，架构层需要封装公共 mixin 库。例如文本省略、响应式断点、统一边框、动画效果、渐变等逻辑，统一封装成 mixin。业务层即便需要少量扩展，也只需要引入 mixin，不用重复编写样式逻辑，保证全站规则一致。
预处理器公共变量
架构层必须维护一套统一的预处理器公共变量，包括颜色、字号、间距、圆角、阴影、z-index、断点等全部规范。所有组件、样式、mixin 都必须使用变量，禁止硬编码色值与像素。这样一来，全局调整字号、换主题、统一风格时，只需要修改变量即可全站生效，非常高效。
PostCSS 后处理器兜底
PostCSS 作为样式工程化的最后一道兜底，负责自动处理兼容、适配、压缩等工作。通过 autoprefixer 自动补全前缀、pxtorem/pxtoviewport 做移动端适配、cssnano 压缩代码，让开发者完全不用关心底层兼容细节，保证样式在不同设备上稳定运行。
Stylelint
最后用 Stylelint 做强制规范约束，在架构层统一配置样式规则：禁止嵌套过深、禁止冗余选择器、禁止不安全属性、必须使用变量等，并配合提交钩子拦截不规范代码。Stylelint 不是限制开发，而是提前把样式问题扼杀在开发阶段，减少后期维护成本。
总结
前端开发的核心价值，在于业务逻辑、交互体验与性能优化，而不是日复一日手写 CSS。不写样式代码，不是偷懒，而是更高级的工程化思路。
当团队在架构层把公共组件库、公共样式库、mixin、变量、PostCSS、Stylelint 整套体系搭建完成，业务开发者就能真正从样式泥潭里解放出来，专心写业务功能。页面风格统一、bug 更少、迭代更快、维护更轻松，小明式的烦恼也会彻底消失。
当架构足够成熟时，你会发现，优秀的前端开发者，不是那些能写出最复杂CSS的人，而是那些一行样式代码都不用写，就能完美实现产品需求的人。
