Opencode 從 Tauri 切回 Electron,桌面端技術選型別被體積陷阱帶偏了

**大家好,我是老劉**

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 行程,伺服器端程式碼執行更簡單,減少一層執行時依賴。

這三個理由看起來都很具體,那麼這兩個開發框架的差別到底在哪裡?


Tauri vs Electron

老劉在 2024 年的時候就發文章對比過 Tauri:

flutter、tauri、maui你更看好哪一個?

只不過那時候更多是站在手機端的角度進行對比。

如果是站在桌面端的角度,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:

  • 載入 5MB → 約 1.4 毫秒
  • 載入 100MB → 約 28 毫秒
  • 差距:26 毫秒

人眼的極限反應速度大約是 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 專案踩過這些坑:

  • macOS(WKWebView)不支援某些 CSS Grid 版面特性,backdrop-filter 有性能問題,捲動彈跳效果跟其他平台不一致
  • Windows(WebView2 / Edge Chromium)相對最好,但部分 Windows 10 以下版本沒裝 WebView2 執行階段,需要額外引導安裝
  • Linux(WebKitGTK)版本碎片化嚴重,Ubuntu 自帶的 WebKitGTK 可能還是兩三年前的版本,某些 ES6+ 語法直接不支援

這意味著你寫好一套 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 倉庫裡,方便大家查閱。

🔗 github.com/lzt-code/bl…


原文出處:https://juejin.cn/post/7660513725813014578


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝17   💬3   ❤️5
737
🥈
我愛JS
📝3   💬6   ❤️4
167
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
📢 贊助商廣告 · 我要刊登