tailwindcss 究竟比 unocss 快多少?
前言
大家好,我是去年一篇測評 《unocss 究竟比 tailwindcss 快多少?》 的作者 icebreaker
。
一晃到了 2025 年,tailwindcss@4
也正式發布了,現在最新版本是 4.1.13
。
新版本不僅在功能和性能上大升級,甚至定位也發生了變化: 從一個 PostCSS
插件變成了樣式預處理器。
與此同時,unocss
也一直在進步,一路也更新到了 66.5.1
,新的 preset-wind4
寫法上也對 tailwindcss@4
做了一定的兼容。
但有一點還是不一樣:它還沒辦法像 tailwindcss@4
一樣,把所有配置都直接寫在 css
里。
開始測試
這次測試,我還是沿用了去年的基準用例,不過加了更多場景。
比如,我在里面加入了等量的 @apply
指令,來模擬真實開發時的情況。這樣一來,不管是 tailwindcss
還是 unocss
,都得老老實實去解析 CSS AST
,算是“加點負重”。
測試環境保持一致,依舊還是我的老伙計 MacBook M1 Pro (2021)(想換新的 M4 Pro了)
跑 200
次,提取并生成 1656
個工具類,取 75%
分位數(避免極端值干擾)。
測試代碼大家也可以自己跑跑 👉 源代碼。
測試報告
測試結果如下:
2025/9/11 10:01:53
1656 utilities | x200 runs (75% build time)none 14.42 ms / delta. 0.00 ms
@tailwindcss/vite v4.1.13 268.90 ms / delta. 254.48 ms (x1.00)
unocss/vite v66.5.1 362.08 ms / delta. 347.66 ms (x1.37)
@tailwindcss/postcss v4.1.13 438.63 ms / delta. 424.21 ms (x1.67)
tailwindcss3 v3.4.17 739.27 ms / delta. 724.85 ms (x2.85)
@unocss/postcss v66.5.1 912.33 ms / delta. 897.91 ms (x3.53)
分析結果
從數據里可以很直觀地看出幾個結論:
- 最快的是
tailwindcss@vite
,平均 268ms。 - 最慢的是
@unocss/postcss
,接近 912ms。 @tailwindcss/vite
vsunocss/vite
:unocss/vite
(362ms)對比tailwindcss@vite
(268ms),大概 慢 1.37 倍。
- postcss 模式的開銷真的很大:
tailwindcss@postcss
比vite
版本慢將近一倍(438ms)。@unocss/postcss
更是接近vite
版tailwindcss@4
的 4倍。
- 老的 tailwindcss@3(
739ms
)基本沒法和新版本比,性能差距太明顯。
因為這個結果,所以這篇文章起了這個標題 tailwindcss 究竟比 unocss 快多少?
,正好和去年的反過來了。
為什么會這樣?
個人總結了一些原因:
-
tailwindcss@4 的技術升級
- 它的
Token
提取器用Rust
重寫,效率高很多。(可能這點加了大分) - 定位從
PostCSS
插件轉為“預處理器”,內部對AST
解析和構建做了深度優化。 - 在
Vite
集成模式下,性能直接拉滿。
- 它的
-
unocss 的靈活性代價
unocss
勝在靈活和可擴展,但靈活帶來額外性能開銷。- 特別是 runtime 動態生成規則、插件抽象這些地方,都會拖慢速度。
- 在
PostCSS
模式下表現更差。
-
vite 的加成
vite
本身 HMR 和插件體系就很快。tailwindcss@vite
能直接吃到vite
的緩存和優化紅利。
我們應該選用哪個方案?
從生態的角度考慮
從生態上來說,tailwindcss
基本上是“既成事實的標準”。
無論是前端社區里大大小小的 UI 組件庫,還是各種腳手架、模版項目,AI 生成的代碼,大多數都優先支持 tailwindcss。
比如:
- UI 組件庫:像
shadcn/ui
、daisyUI
、flowbite
等,幾乎全是基于tailwindcss
打造。 - 框架模版:
Next.js
、Nuxt
、Remix
、Astro
的官方或社區starter
里,大多數開箱即配好tailwindcss
。 - 文檔和教程:
tailwindcss
的學習資料、視頻課程、最佳實踐文章,數量遠超unocss
。
換句話說,如果你用 tailwindcss
,幾乎可以無縫接入整個生態,不用自己花太多心思去適配。
所以,如果你項目需要穩定的生態支持、豐富的組件庫,首選 tailwindcss 基本沒懸念。
從自定義和靈活性的角度考慮
但如果你追求的是極致的靈活性,那 unocss
依舊是很強的選項。
unocss 的特點是:
- 規則引擎化:你可以像寫正則一樣,自定義規則來生成工具類。
- 預設體系:除了官方的
@unocss/preset-uno
,還能疊加attributify
、icons
、typography
等預設,甚至自己寫預設。 - 任意屬性模式:不僅僅是類名,甚至可以用類似
text="red-500"
這樣的寫法。
這類靈活性,在 tailwindcss
里要么需要寫 plugin
,要么使用內聯樣式。而在 unocss
里就是一條正則規則的事情。
而且 unocss
能夠使用 Attributify 模式:
<!-- unocss 支持直接在屬性里寫 -->
<div flex="~ col" text="center gray-700" m="y-4"><p>Hello World</p>
</div>
這種寫法比 tailwindcss
的“長串 class
”要簡潔很多,特別適合喜歡 HTML 語義化的人。
不過 unocss
的靈活性,導致 unocss-merge
相對難產, https://www.npmjs.com/package/unocss-merge 這個包沒人用,個位數下載量。
不像 tailwind-merge
已經成為各個 tailwindcss
組件庫的標配了。(Weekly Downloads 將近1千200萬次)
所以結論是:
- tailwindcss = 生態第一,幾乎是“官方標配”。
- unocss = 靈活度第一,適合“想自己捏規則”的場景。
結語
今天的數據用一句話總結:
tailwindcss
的性能全面超越unocss
所以,如果你追求開發體驗 + 構建速度,那現在毫無疑問是 tailwindcss@4 + vite 最優解。
最后,也再期待一波 unocss
的大更新,再和 tailwindcss
它們之間相互卷起來,未來給我們開發者帶來更多的驚喜!