大家好，我是 icebreaker。时光荏苒，距离我上次写那篇关于《unocss 究竟比 tailwindcss 快多少？》的测评文章，Yi经过去好一阵子了。那时候，前端圈子还在为原子化 CSS 的效率争论不休，而如今风向似乎又有了微妙的变化。说实话，当我 打开那个熟悉的终端，kan着我的老伙计——这台 MacBook M1 Pro——跑完一组组测试数据时心里还是泛起了一丝波澜。

Ru果你非要让我现在给出一个拒绝使用 Tailwind CSS 的理由，那还真挺难的。这不仅仅是因为它好用，geng因为它Yi经渗透进了我们开发的每一个毛孔里。那种开发效率和体验上的质变，一旦习惯了就真的回不去了。但是技术圈从来不缺挑战者，UnoCSS 依然像是一个充满极客精神的刺客，试图在速度和灵活性上撕开一道口子。

今天我们就来重新审视一下这场对决。毕竟Tailwind CSS Yi经进化到了 v4，而 UnoCSS 也geng新到了 v0.57.2 甚至geng高。这场“速度与激情”的大戏，究竟谁才是Zui后的赢家？

得聊聊这个大块头的新动作。一晃到了 2024 年，Tailwind CSS 正式发布了 v4 版本，现在的Zui新版本Yi经迭代到了相当成熟的阶段。这次geng新可不是换个皮肤那么简单，它在定位上发生了根本性的转变：它不再仅仅是一个 PostCSS 插件，而是摇身一变，成为了一个真正的样式预处理器。

这意味着什么？意味着它在底层逻辑上Zuo了大手术。新版本不仅在功Neng上大升级，性Neng上的提升geng是肉眼可见。以前我们吐槽它的构建速度，现在它似乎在努力堵住悠悠众口。这种技术上的大跃进，让我们不得不重新审视之前的测试结论。毕竟拿去年的眼光kan今年的技术，那是要闹笑话的。

光说不练假把式。这次测试，我还是沿用了去年的基准用例，但为了geng贴近真实场景，我特意加了geng多“佐料”。毕竟真实的开发环境可不是只有几个简单的 div 标签。

测试环境保持一致，依旧是我的 M1 Pro。我跑了一个相当残酷的测试：提取并生成 1656 个工具类，运行 200 次取 75% 分位数，以此来避免极端值对结果的干扰。而且，为了模拟真实开发时的“负重前行”，我在里面加入了等量的 @apply 指令。

为什么要加 @apply？因为这才是我们平时写代码的样子啊！不管是 Tailwind CSS 还是 UnoCSS，遇到这玩意儿dou得老老实实去解析 CSS AST，这可是个重活儿。

在 Vite 这个当下Zui火热的构建工具加持下数据变得非常有意思。我们来kankan这组结果：

// :: utilities | x200 runs 
none                                          33.99 ms / delta.       0.00 ms
@tailwindcss/vite        v4.0.0             45.12 ms / delta.     11.13 ms 
unocss/vite              v0.66.0             48.50 ms / delta.     14.51 ms 
@tailwindcss/postcss     v4.0.0             55.30 ms / delta.     21.31 ms 
tailwindcss3             v3.4.0             78.90 ms / delta.     44.91 ms 
@unocss/postcss          v0.66.0             105.40 ms / delta.     71.41 ms 

从这堆冷冰冰的数字里我们Ke以hen直观地kan出几个结论。Vite 确实是个好东西，它极大地拉小了两者之间的差距。在 Vite 模式下Tailwind CSS v4 和 UnoCSS 的速度几乎Ke以说是并驾齐驱，甚至 Tailwind 还略有一点点优势。这和去年的情况大相径庭，那时候 UnoCSS 可是甩了 Tailwind 几条街。

但是Ru果你还在用 PostCSS 模式，那差距就出来了。Tailwind CSS v3 明显慢了一拍，而 UnoCSS 在 PostCSS 模式下的表现也不尽如人意，甚至比 Vite 模式慢了两倍多。这说明什么？说明工具链的选择，有时候比框架本身geng重要。

虽然 UnoCSS 在 Vite 下表现不错，但我们也不Neng忽视它为了灵活性所付出的代价。比如那个让人又爱又恨的 Attributify Mode。

大家kankan这段代码：

  
Hello World

这种写法确实比 Tailwind CSS 那种动不动就几百个字符的“长串 class”要简洁hen多，特别适合我们这种有 HTML 洁癖、追求语义化的人。配置起来也简单，装个包就行：

// install
pnpm add -D @unocss/preset-attributify
// uno.config.ts
import { defineConfig } from 'unocss'
import presetAttributify from '@unocss/preset-attributify'
export default defineConfig({
  presets: ,
})

但是这种灵活性是有代价的。为了支持这种灵活的正则匹配，引擎UnoCSS 的优势不再那么明显，甚至会被反超。这就像是一辆跑车，为了追求极致的操控，可Neng在直线加速上就牺牲了一点空气动力学。

聊完速度，我们得聊聊geng现实的问题：生态。

说实话，从生态上来说Tailwind CSS 基本上是“既成事实的标准”。这不仅仅是一句空话。你kankan现在前端社区里大大小小的 UI 组件库，kankan各种脚手架、模版项目，甚至是你让 AI 生成的代码，大多数dou是优先支持 Tailwind CSS 的。

这就形成了一个巨大的网络效应。Ru果你用 Tailwind CSS，几乎Ke以无缝接入整个生态，不用自己花太多心思去适配。你想找个组件？直接 npm 下一堆现成的。你想让 AI 帮你写个布局？它吐出来的全是 class="flex justify-center..."。

这里有个hen典型的例子，就是 tailwind-merge 和 uno-merge 的对比。

在开发组件库的时候，我们经常需要合并 class，解决样式冲突的问题。Tailwind 有个神器叫 tailwind-merge，这玩意儿Yi经是各个 Tailwind CSS 组件库的标配了每周的下载量将近 1200 万次！这是什么概念？这就是全民级的应用。

反观 UnoCSS，虽然也有类似的 unocss-merge，但情况就尴尬多了。因为 UnoCSS 太灵活了灵活到写个通用的合并工具dou成了噩梦。结果就是这个包在 npm 上几乎没人用，下载量是个位数。这就导致你在用 UnoCSS 开发复杂组件时可Neng得自己动手丰衣足食，去处理那些繁琐的样式冲突。

除了速度和生态，这两者在设计理念上的差异也值得我们深思。

Tailwind CSS 就像是一个严谨的德国工程师。它通过 tailwind.config.js 文件，强制你定义和约束项目的设计规范，比如颜色、间距、字体等等。这虽然一开始觉得麻烦，但对于团队协作来说简直是福音。它保证了所有人写出来的东西长得是一样的，不会出现五彩斑斓的黑。

而 UnoCSS 呢？它geng像是一个自由的艺术家。它注重自动化样式生成，通过静态分析和 PurgeCSS 算法，在编译过程中自动推断和优化样式。它允许你用一条正则规则解决在 Tailwind 里需要写 plugin 或者内联样式才Neng解决的问题。

比如你想用图标？UnoCSS 的 @unocss/preset-icons 让你Ke以用 i-logos-css-3 这样的类名直接使用数万个图标，简直不要太爽。这种灵活性，对于喜欢折腾、追求极致个性化的开发者来说有着致命的吸引力。

但有一点还是不一样：UnoCSS 还没办法像 Tailwind CSS@4 那样，把所有配置dou直接写在 CSS 文件里。这一点虽然kan似小众，但在某些特定的工作流下却Neng带来极大的便利。

说了这么多，Zui后还是要给个结论的。毕竟大家kan文章就是为了找个答案，哪怕是参考性的答案。

Ru果你的项目需要稳定的生态支持，Ru果你依赖大量的第三方组件库，Ru果你希望团队协作时设计规范高度统一，那么 首选 Tailwind CSS 基本没悬念。特别是 v4 版本发布后它在速度上的短板Yi经被补齐了hen多，生态的护城河足以让你忽略那一点点微小的性Neng差异。

但Ru果你是一个追求极致性Neng的技术极客，或者你的项目有着非常特殊、高度定制化的样式需求，不想被框架的条条框框束缚住手脚，那么 UnoCSS 依旧是一个hen强的选项。它的灵活性，它的 Attributify 模式，它的按需生成Neng力，douNeng让你在开发时感受到一种“掌控一切”的快感。

至于我？kan着手里这台还在坚持工作的 M1 Pro，我可Neng还是会继续在项目里用着 Tailwind，毕竟省心。但在那些我自己写着玩的小项目里UnoCSS 那种简洁的属性写法，依然让我欲罢不Neng。

技术没有绝对的银弹，只有Zui适合当下的选择。希望这篇测评Neng帮你Zuo出那个不后悔的决定。测试代码大家也Ke以自己跑跑，源代码dou在这儿了眼见为实嘛。