**大家好,我是老劉**
2024 年,Tauri 發布,全網一片叫好:「Electron 殺手」、「安裝包體積縮小 90%」、「Rust 性能加持」。各路技術部落客(包括我在內)都在聊這個新玩具。
結果呢?2026 年 4 月,Opencode 團隊在 dev.to 上發了一篇文章,標題很誠實:
Moving OpenCode Desktop to Electrondev.to/brendonovic…
意思就是:我們試過了,現在要切回 Electron。
官方給了三個理由:
1. WebKit 渲染問題
Tauri 在 macOS/Linux 上使用 WebKit 渲染,效能不如 Chromium,且不同平台間樣式不一致,維護成本高。
2. CLI 啟動瓶頸
Bundled CLI 影響啟動速度,Windows 上偶發失敗,使用者體驗打折扣。
3. Bun → Node 遷移
團隊計劃從 Bun 遷移到 Node,Electron 內建 Node 行程,伺服器端程式碼執行更簡單,減少一層執行時依賴。
這三個理由看起來都很具體,那麼這兩個開發框架的差別到底在哪裡?
老劉在 2024 年的時候就發文章對比過 Tauri:
只不過那時候更多是站在手機端的角度進行對比。
如果是站在桌面端的角度,Tauri 和 Electron 就是非常典型的一對競爭對手。
他們兩個之間的關係非常像手機端的 RN 和 Flutter。
RN 和 Tauri 都是將渲染部分交給了系統,他們自己只負責維護邏輯上的 UI 樹。因此它們的體積都可以做得非常小。
而 Flutter 和 Electron 都是將渲染引擎打包到程式內部,因此安裝包的體積看起來就會大很多。
這也是目前很多專案採用 Tauri 作為技術棧的一個賣點,宣稱自己體積是競品的多少分之一,啟動速度快,運行效率高。
但這其實是個誤導,軟體包的體積和執行速度沒什麼直接關係。
關於性能咱們拆成啟動速度和運行速度來看。
Tauri 最小 2-5MB,Electron 動輒 50-150MB,差了 20 倍以上。直覺上,把 5MB 載入到記憶體肯定比 100MB 快。
但現在的電腦基本都是 SSD(PCIe 3.0/4.0),讀取速度約 3500-7000 MB/s:
人眼的極限反應速度大約是 100 毫秒。這 26 毫秒的差距,你根本感知不到。所以「體積小 = 啟動快」這個賣點,在 SSD 普及的今天基本不成立。
Tauri 的 UI 部分仍然是用 TS 開發的,只有底層邏輯可以用 Rust。這就帶來一個問題:哪些程式碼該交給 Rust?
典型的場景是 CPU 密集型的運算任務:大規模日誌掃描、資料加解密、壓縮解壓縮。如果你的應用這類任務多,Tauri 確實能發揮性能優勢。
但如果你的主要工作就是展示幾十個欄位的 JSON 資料(不管是來自本地還是服務端 API),把這種處理也塞進 Rust,除了增加程式碼複雜度,沒什麼明顯收益。
說白了,Tauri 只在特定場景下有性能優勢。
Opencode 遷移的真正原因在哪裡?也是很多專案選型最容易忽視的問題:多端一致性。
看兩張架構圖就明白了。
Electron 的架構:
scss 程式碼解讀複製代碼┌──────────────────────────────┐
│ Renderer Process │ ← 跑 Chromium,展示 UI
│ (HTML + CSS + JS/TS) │
└──────────┬───────────────────┘
│ IPC(行程間通訊)
▼
┌──────────────────────────────┐
│ Main Process │ ← 跑 Node.js,管理視窗生命週期、系統呼叫
│ (Node.js + Electron API) │
└──────────────────────────────┘
Electron 把 Chromium 和 Node.js 都打包進了安裝包,渲染過程完全不依賴作業系統。你在 macOS 上看到的樣子,到 Windows、Linux 上還是一模一樣。
Tauri 的架構:
yaml 程式碼解讀複製代碼┌──────────────────────────────┐
│ 系統原生 WebView │ ← macOS: WKWebView / Linux: WebKitGTK
│ (HTML + CSS + JS/TS) │ Windows: WebView2 (Edge Chromium)
└──────────┬───────────────────┘
│ IPC(行程間通訊)
▼
┌──────────────────────────────┐
│ Tauri Core (Rust) │ ← 視窗管理、系統呼叫、行程管理
│ (Rust + Tauri API) │
└──────────────────────────────┘
為了更小的體積,Tauri 把渲染工作委託給了系統自帶的 WebView。安裝包確實小了很多,但代價是:三個平台,三套 WebView 實作。
這裡面還是有不少坑的,我見過不少 Tauri 專案踩過這些坑:
backdrop-filter 有性能問題,捲動彈跳效果跟其他平台不一致這意味著你寫好一套 UI,需要在三個平台上各自測試、各自調優。如果是小團隊或者獨立開發者,這個維護成本非常可觀。
這就是 Opencode 踩過的坑:「在 macOS 上測試好好的,到 Windows 上樣式渲染出來就是不一樣,Linux 上動畫掉幀」。這是 Tauri 這種嫁接在系統渲染之上的框架固有缺陷。
反觀 Electron,雖然安裝包大了點,但 Chromium 的渲染一致性是業界標竿。而且這幾年 Chromium 的優化一直在進步,V8 引擎越來越快,GPU 加速越來越成熟,記憶體管理也在改善。用體積換來的是一套程式碼在所有平台上的確定性。
對於 AI 時代的桌面應用來說,這就很要命了。AI 編程工具的核心功能是什麼?聊天介面、程式碼高亮、Markdown 渲染、即時串流輸出。這些東西對 UI 一致性的要求遠高於對原生性能的要求。而 WebView 碎片化帶來的「修不完的相容性 bug」,恰恰是最消耗開發精力的地方。
說到底,從 Tauri 切回 Electron,不是 Tauri 不好,而是不適合他們的專案類型。
我列個對照表,你自己對號入座:
維度TauriElectron安裝包體積2-5MB50-150MB啟動速度快約 26ms(感知不到)慢約 26ms(感知不到)UI 一致性❌ 依賴系統 WebView,三平台三套表現✅ Chromium 渲染,全平台一致原生性能✅ Rust 端適合 CPU 密集型任務❌ 但大多數 UI 應用用不到Web API 相容性❌ WebKit 版本碎片化✅ 與 Chrome 保持一致生態成熟度快速發展中,部分功能不完善✅ 極其成熟,幾乎所有場景都有方案調試工具需要跨語言調試(TS + Rust)✅ 一套 Chrome DevTools 搞定AI 工具友好度中等(Rust AI 生態不如 JS/TS)✅ TypeScript + Node 生態,與 AI 工具鏈無縫對接團隊要求需要前端 + Rust 雙技能純前端即可### 老劉的建議
如果你的專案以 UI 互動為核心(聊天工具、編輯器、IDE、管理後台、AI 客戶端),選 Electron。你的體積焦慮在使用者電腦的 SSD 面前一文不值。真正值錢的是:一套程式碼跑三個平台、AI 生態無縫對接、社群方案隨手可得。
如果你的專案確實以 CPU 密集型任務為主(影片處理工具、大數據分析客戶端、檔案格式轉換器),並且 UI 相對簡單,可以考慮 Tauri。Rust 在計算密集場景下的優勢是實實在在的,Tauri 的輕量體積在這種情況下也更有意義。
回到老劉自己,為什麼我一直傾向 Flutter 和 Electron?因為我做的專案大多是 UI 密集型 的:狀態管理、互動設計、跨端一致性,這些才是使用者能感知到的東西。使用者不會因為你省了 100MB 硬碟空間就誇你好,但會因為某個按鈕在 Windows 上點不了而罵你。
最後說句實在話:
對於 AI 時代的獨立開發者和小團隊來說,時間窗口是最稀缺的資源。Opencode 的遷移告訴我們:與其花時間跟 WebView 碎片化搏鬥,不如把精力放在產品本身。
如果你今天要做一個桌面端的 AI 工具,直接從 Electron 開始。別糾結那幾十 MB 的體積,你的 MVP 上線時間比什麼都重要。
先跑到終點的,不是包袱最輕的那個,而是路上少摔跤的那個。
🤝 如果看到這裡的同學對客戶端或者 Flutter 開發感興趣,歡迎聯繫老劉,我們互相學習。
🎁 私訊免費領老劉整理的《Flutter 開發手冊》,覆蓋 90% 應用開發場景。可以作為 Flutter 學習的知識地圖。
💬 : laoliu_dev
📂 老劉也把自己歷史文章整理在 GitHub 倉庫裡,方便大家查閱。