样式管理是Vue项目工程化中最容易被忽视的一环。项目初期大家随手写样式，组件里style一挥而就，等页面数量突破几十个，问题开始集中爆发：同一个按钮样式在十几个组件里复制粘贴，改一个颜色要全局搜索替换；公共样式文件越来越臃肿，覆盖顺序全靠!important硬撑。公共样式文件和原子化CSS是解决这类问题的两条主流路线，本文从原理、体积、维护成本几个角度做一次系统对比。
公共样式文件：集中管理的传统路线
公共样式文件的思路很好理解：把项目中复用度高的样式抽取出来，放到统一的目录里维护。典型结构是src/styles目录下放reset.css、variables.scss、mixins.scss、common.scss几个文件，然后在main.js里统一引入。组件内部再通过class名称引用这些公共类，比如按钮统一用btn，卡片统一用card。
这种方式的优点是语义清晰。一个.btn-primary类名本身就说明了用途，读模板的人一眼就能明白元素长什么样。同时SCSS的变量和mixin让主题切换、设计系统落地变得容易，设计师给的色板直接映射成$primary、$danger变量，全局一改全站生效。
但它的缺陷也很明显。第一是命名污染，随着公共类越来越多，团队里没人敢确定某个类是否还在被使用，删掉怕出问题，留着就变成死代码。第二是覆盖链失控，当组件内scoped样式需要微调公共类时，优先级战争就开始了，最终代码库里充斥着各种选择器嵌套和!important。第三是打包体积，公共文件里的样式不管有没有被用到都会全部打进产物，一个只用到一个按钮的页面也要背上整个common.scss的负担。
<!-- 典型的公共样式引入方式 -->
<style lang="scss">
@import '@/styles/variables.scss';
@import '@/styles/mixins.scss';
.btn-primary {
@include button-variant($primary-color, #fff);
padding: 8px 16px;
border-radius: 4px;
}
</style>从实践来看，公共样式文件适合中小型项目，尤其是设计规范稳定、页面风格统一的后台管理系统。当项目规模扩大到多人协作、页面风格差异明显时，它的维护成本会陡增。
原子化CSS：把样式粒度拆到最小
原子化CSS（Atomic CSS）的思路完全相反：不再抽象语义化的类名，而是每个类只做一件事。flex只负责弹性布局，mt-4只负责上边距，text-red-500只负责文字颜色。代表工具有Tailwind CSS和UnoCSS，后者是Vue生态中Vite项目用得较多的方案，主打按需生成。
原子化最大的卖点是体积可控。传统CSS体积随页面数量线性增长，而原子类的组合是有限的，页面越多，类名复用率越高，CSS产物增长会趋于平缓。UnoCSS的做法更彻底：构建时扫描模板中实际出现的类名，只生成用到的样式，没用到的字节都不进产物。一个中型项目最终CSS产物控制在30KB以内并不少见。
// vite.config.js 中配置 UnoCSS 按需生成
import UnoCSS from 'unocss/vite';
export default {
plugins: [
vue(),
UnoCSS({
// 预设了常用的原子类规则
presets: [],
shortcuts: {
// 将多个原子类组合成一个快捷类，兼顾语义化
'btn-primary': 'px-4 py-2 rounded bg-blue-600 text-white hover:bg-blue-700',
},
}),
],
};开发效率是另一个常被提及的优势。写原子类不需要在模板和样式文件之间来回切换，不用纠结类名怎么起，大部分样式直接在模板里拼出来就能看效果。配合VS Code的智能提示插件，开发体验相当顺畅。
当然代价也存在。模板会变得很长，一个元素挂十几个类很常见，初次接触的团队成员会有明显的不适应期，review代码时样式可读性也依赖对原子类的熟悉程度。另外，动态拼接类名在按需生成的机制下会失效，比如:class="'text-' + color"这种写法扫描不到完整的类名，必须改成映射对象或safelist显式声明。
四个维度的直接对比与选型建议
把两种方案放到同一张表里看得更清楚。
| 维度 | 公共样式文件 | 原子化CSS |
|---|---|---|
| 打包体积 | 随功能增加持续膨胀，含大量未使用样式 | 按需生成，体积增长平缓 |
| 开发效率 | 需要命名思考，模板与样式文件来回切换 | 直接在模板组合类名，上手后有优势 |
| 可读性 | 语义化类名，结构清晰 | 类名冗长，依赖团队熟悉度 |
| 维护成本 | 命名冲突、覆盖链混乱、死代码难清理 | 删元素即删样式，无死代码 |
| 适用场景 | 设计规范稳定的中小项目、后台系统 | 多风格、多页面、长期迭代的项目 |
实际上这两种方案并不是非此即彼。比较成熟的实践是混合使用：基础重置和变量仍放在公共文件里，通用业务组件（按钮、弹窗、表单控件）用语义化的公共类封装，页面级的布局和间距细节交给原子类处理。这样既保住了设计系统的一致性，又避免了在细节样式上反复造轮子。
如果是老项目渐进式迁移，推荐先引入UnoCSS处理新写的页面，旧代码不动，等有改版需求时再逐步替换。同时保留一套shortcuts定义核心的语义类，让团队从熟悉的类名平缓过渡到原子类的写法。这种策略的风险最低，也不会在迁移过程中出现两套体系互相打架的情况。
最后提醒一点，无论选哪种方案，scoped和CSS Modules与原子化CSS并不冲突，Vue的scoped属性给组件内样式加数据属性隔离，恰好可以用来写那些确实只属于当前组件、不值得抽成原子类的复杂样式。工具永远是手段，让样式可预期、可维护才是目的。