造輪子還是買輪子？一個前端工程師的組件庫實驗

三周前，一位開發者決定再做一個組件庫。不是因為他覺得市場缺這個，而是現有的工具組合里，找不到同時滿足三個條件的方案。

導讀

這件事的吊詭之處在于：React生態里組件庫成百上千，但把Tailwind v4、Framer Motion動畫、TypeScript類型安全這三個需求打包在一起的，居然沒有現成的。他花了三周驗證了這件事——然后開源了25個組件。本文拆解這個決策背后的技術權衡，以及為什么"重復造輪子"有時候是理性的。

一、需求拆解：三個條件同時滿足有多難

這位開發者的需求清單很具體：

? Tailwind CSS v4（不是v3）
? Framer Motion做動畫覆蓋層和過渡效果
? Headless瀏覽器鉤子——全部來自同一個包，且TypeScript API一致

他找了一圈現有的方案，結論是：沒有一個能開箱即用滿足這個組合。這不是挑剔，而是v4剛發布不久，生態還沒跟上。

于是Zentauri UI誕生了。三周時間，25+組件、一套headless鉤子、完整排版系統。

二、技術棧選擇：為什么押注Tailwind v4

Tailwind v4的核心變化是新的CSS-first配置架構。這位開發者選擇v4-first，意味著要承擔早期采用者的代價——周邊工具鏈可能還沒適配。

他的判斷是：v4的變體API（variant APIs）配合CVA（Class Variance Authority）能讓設計系統擴展時保持類型安全。代碼示例顯示，按鈕組件的變體定義如下：

「每個變體都是CVA支持的，所以重構時隨著設計系統增長依然安全」——這是他給出的理由。

Framer Motion的集成方式更直接：模態框、標簽頁、抽屜的入場動畫全部內置，不需要用戶自己拼接動畫邏輯。這對需要精致交互但不想深入研究動畫API的團隊是賣點。

三、產品形態：不是又一個UI庫

Zentauri UI的架構分三層：

視覺層：玻璃態、實色、描邊、漸變四種外觀變體，跨按鈕、輸入框、覆蓋層通用

動畫層：Framer Motion封裝為組件內部實現，調用方無感知

邏輯層：useLocalStorage、useDebouncedValue、useClickOutside、useMediaQuery等headless鉤子獨立導出

這種分層的好處是：你可以只拿鉤子走，也可以全套采用。排版組件（Heading、Text、Blockquote等）單獨成體系，暗示這個庫的目標用戶是完整重建界面的團隊，而非只想找個按鈕樣式。

安裝方式有兩種：

? npm包直接引入組件
? npx CLI腳手架初始化項目

CLI的存在說明他預判到：v4的配置復雜度足以讓初始化成為痛點。

四、辯論：這個輪子該造嗎

反方觀點：生態已經足夠

Shadcn/ui、Radix、Headless UI、Chakra——React組件庫的戰爭早已結束。再做一個，維護成本誰來承擔？用戶憑什么信任一個個人項目的長期更新？

這些質疑成立。但有一個變量被忽略了：技術棧的版本鎖定效應。當Tailwind v4的breaking change讓現有庫遷移滯后時，窗口期出現了。這位開發者捕捉到了3-6個月的生態真空。

正方觀點：組合即創新

他不是在做"更好的按鈕"，而是在做"特定技術組合的預配置方案"。價值主張不是組件本身，而是省下的集成時間。

看具體交付：25個組件、類型安全的變體系統、動畫內置、鉤子獨立。這對一個三周的項目，完成度足夠高。

判斷：什么時候該造輪子

這個案例的啟示是：造輪子的合理性不取決于"有沒有輪子"，而取決于"現有輪子是否適配你的軌道"。

三個信號出現時，自建組件庫是理性選擇：

1. 核心技術版本升級造成生態斷層（如v4發布）
2. 所需能力分散在多個庫，集成成本高于自建
3. 團隊有強類型安全要求，現有方案的類型覆蓋不完整

但風險同樣明確：個人項目的可持續性、社區貢獻的可持續性、與上游（Tailwind、Framer Motion）版本升級的同步成本。

五、可復用的技術決策

即使你不打算自建組件庫，這位開發者的技術選擇也有參考價值：

CVA + Tailwind v4的類型安全變體：把設計token和組件實現綁定，重構時編譯器幫你兜底。這比運行時檢查更早暴露問題。

動畫內聚而非分散：把Framer Motion封裝在組件內部，調用方只關心open/close狀態。這種"復雜度下沉"讓團隊其他成員不用學習動畫庫API。

Headless鉤子的獨立封裝：useClickOutside、useMediaQuery這些邏輯與UI解耦，可以被任何組件消費，包括非Zentauri的組件。

CLI降低采用門檻：v4的配置涉及postcss、css導入順序、主題變量，手動 setup 容易出錯。一鍵初始化消除早期流失。

六、開源產品的冷啟動邏輯

Zentauri UI的發布策略也值得拆解。他沒有先建官網再發代碼，而是直接放npm包和GitHub，用代碼說話。

這種"代碼優先"的冷啟動適合技術產品：早期用戶是開發者，他們更信任能直接讀源碼的項目，而非精心設計的落地頁。

但長期看，需要回答的問題沒變：誰來維護？如何建立社區貢獻機制？與上游依賴的版本策略是什么？

這位開發者在文章結尾沒有承諾路線圖，只說了"有些代碼你可以偷走"——誠實，也暗示了項目的當前階段。

數據收束

三周，25+組件，一套鉤子系統，一個CLI工具。這個數字密度說明：在現代前端工具鏈支持下，個人開發者的產出邊界遠高于五年前。

但更重要的是決策質量——他不是因為"想造輪子"而造，而是因為"特定技術組合的窗口期"而造。這種時機判斷，比代碼能力更難復制。

對于讀者中的技術負責人：下次評估"買vs造"時，除了功能清單，請加上版本生態圖和集成成本估算。有時候，沒有現成方案不是因為市場失敗，而是因為技術迭代正在發生。