RustRover 2026.2 把 Rust 設定收成一個檔

以前我得先裝一堆 Rust 外掛，現在只要打開 Cargo.toml 就能開工。

我用 Rust 專案一陣子了，最煩的從來不是語法，是開工前那段鬼打牆。新 repo 一打開，先找 Rust 外掛、formatter、Cargo 整合、測試 runner、debugger、TOML 支援，順手再補 Git、Docker、資料庫工具。等我真的開始寫 code，半小時常常已經過去。Rust 本來就夠有主見了，結果很多編輯器還要我自己拼工作環境，像在拿零件組桌子。

這次我看的是 RustRover 2026.2，來源是 Warp2Search 的整理，它轉述 JetBrains 這版把 Rust 工作流直接包進 IDE。RustRover、JetBrains AI、DataGrip 這些東西我都不陌生，所以我看的角度很實際：這到底是少折騰，還是又一個看起來很完整、用起來很重的 IDE。

我翻完 release write-up 之後，腦袋裡留下的不是「新功能很多」，而是另一個更直接的結論：它在賣的其實是少做決定，少裝插件，少切工具，讓 Rust 的基本盤直接出現在一個地方。

它在賣的不是功能，是少折騰

RustRover addresses these frustrations by providing comprehensive support for Cargo, TOML editing, remote development, and Docker management in its base installation.

翻譯一下就是：JetBrains 想把 setup tax 砍掉。不是把 Rust 變簡單，Rust 還是那個 Rust；是把那些很煩、但又非做不可的編輯器配置先收掉，讓我不用先當半小時的系統整合師。

我每次開新 Rust workspace，最先做的事都不是寫程式，而是確認編輯器有沒有真的懂這個專案。它看得懂 Cargo.toml 嗎？測試能不能直接跑？debugger 有沒有接上？formatter 跟 rustfmt 是不是同一套？這些問題單看都不大，連在一起就很煩。RustRover 的方向很明確：把基本盤直接包好，不要叫我自己湊。

實操上，這種設計最適合兩種場景。第一種是團隊 onboarding，新同事不用先研究「這個 repo 要裝哪三個外掛」。第二種是你自己有很多 Rust 專案，根本不想每次都重做一遍工具鏈拼裝。IDE 先把 Cargo、TOML、遠端開發、Docker 都接好，你才有空回到真正的問題：這段 code 為什麼不對。

• 適合你：每次開新 Rust repo 都要重裝一輪環境。
• 適合你：團隊一直重複講同一套編輯器設定。
• 不適合你：你只想要最輕的編輯器，其他一律自己來。

我也不想把話說得太漂亮。這種 all-in-one 通常有代價，最常見的就是 RAM 吃得比較兇。JetBrains 工具一直都站在這條線附近。你如果是老機器，體感一定有差；你如果是正常工作機、又常常被插件地獄搞到心累，那這種整包式做法反而比較省命。

真正有用的是 Cargo-first，不是 UI 漂亮

Users simply need to point the IDE at their Cargo.toml file, and the environment is ready to use.

這句話我很買單，因為它直接告訴我：你只要給我 manifest，剩下我自己推。這才是 Rust 該有的工作方式。Cargo 本來就是專案的真相來源，依賴、workspace、build target、feature、test layout 都在那裡。IDE 只要讀對了，很多東西根本不用再問人。

我以前最受不了的，就是編輯器嘴上說支援 Rust，實際上只是 syntax highlighting 加一個半死不活的 plugin。然後我每次換 workspace、加 example、拆 crate、放 bench、補 integration tests，整個工具就開始跟不上專案結構。這不是小問題，這是你每天都會撞到的痛點。

實操寫法很簡單：開專案時永遠從 Cargo.toml 進去，不要從某個子資料夾亂開。先確認 workspace members、tests、examples、benches 都有被正確辨識，再看 formatter 和 lint 行為是不是跟 Cargo 預期一致。這種檢查很無聊，但很值錢，因為它能直接告訴你這套 IDE 是真的懂 Rust，還是在假裝懂。

• 從 manifest 開專案，不要從任意資料夾開。
• 先驗證 workspace members，再驗證 test targets。
• 把 formatter、linter、run config 都跟 Cargo 對齊。

JetBrains 在這版也把 remote development 和 Docker management 一起放進 base install。這點我很在意，因為現在很多 Rust 工作根本不在本機完成，容器、遠端主機、開發環境都混在一起。編輯器如果把這些當外掛附屬品，就會一直慢半拍。

AI 有沒有用，看它懂不懂 Rust

Developers can utilize various AI models such as Claude, GPT-4, and more, while maintaining transparency regarding costs and avoiding mandatory subscriptions.

這段話的意思很直白：JetBrains 想把 AI 做成工具選項，不是綁架你訂閱。我對這種設計比較有好感，因為我真的看膩了那種「功能很實用，但你先付錢再說」的套路。

但 AI 真正有沒有用，不在於它列了多少模型，而在於它懂不懂 Rust。Rust 不是那種你丟個 generic autocomplete 就會自動變聰明的語言。ownership、borrowing、lifetime、async、macro、trait bound、error propagation，任何一個地方懂一半都會出事。模型如果沒吃到上下文，產出的東西就只是看起來很像答案的廢話。

我之前在一個 Rust service 裡就撞過這件事。那個專案有一層又一層 async error path，便宜 AI 最愛把錯誤處理改成一坨看似乾淨、實際上只有模型世界能編譯的東西。真正有用的 AI，是能幫我補 test scaffold、解釋 macro 展開、整理 match arm、提議重構，但不會亂踩 borrow checker。

實操上，我會把 AI 當第二個讀 code 的人，不是當代寫者。拿它來生測試骨架、解釋一段陌生 code、整理重複樣板，這些都很合理。拿它來跳過 type check、lifetime 檢查、async 邊界確認，那就是自找麻煩。IDE 如果能把這些驗證做得更順，AI 才真的有價值。

相關的 AI 生態可以看 JetBrains AI，而這次提到的模型包含 Claude 和 GPT-4。我不會把模型名單當神諭，我只在乎它能不能少浪費我一點時間。

團隊協作最怕的是每個人都以為自己設定很正常

The IDE allows for the sharing of project configurations, thereby simplifying collaboration on coding style and formatting preferences.

這句話講得很實際：RustRover 想把團隊的 editor 行為收斂成一致的東西。這件事平常很少人拿出來講，但它超重要。因為很多 merge request 的爭吵，表面上是 code style，實際上是大家本機設定不一樣。

我看過太多「這裡怎麼被改掉了」的 review，最後追下去才發現是某個人的 formatter、inspection profile、run config 跟別人不一樣。這種問題很浪費時間，而且很難一眼看出來。共享 project configuration 的價值，就是把會影響團隊結果的設定留在 repo 或專案層，別讓它飄在每個人自己的筆電裡。

實操寫法也不複雜：先決定哪些設定是團隊共用，哪些是個人偏好。格式化、檢查規則、run configuration、shared tooling defaults，通常都該往專案層放。字型、主題、快捷鍵這種個人習慣，就留給自己。線畫清楚，review 就少很多莫名其妙的摩擦。

• 把格式化和執行設定盡量放進專案。
• 把會影響 review 結果的設定當成團隊契約。
• 檢查你們的 bug 是 code 問題，還是本機 IDE 行為不一致。

JetBrains 也提到 real-time collaboration 和 Git integration。Git 這東西本來就是基本盤，我不會為了它鼓掌；但如果即時協作真的已經整合好，至少你不用再為了兩個人同看一份 code 去裝另一套外掛。這種省事，通常比介面好看更值錢。

資料庫工具放進來，省的是切視窗的命

RustRover enhances productivity through built-in database tools sourced from DataGrip.

這段我看得很懂，因為我自己也很討厭一直切 app。寫 Rust service 的時候，最常發生的事就是：程式在 IDE、資料庫在另一個工具、container 在第三個視窗、logs 在終端機。人還沒 debug 完，腦袋先散掉。

JetBrains 這裡的思路是把相關工作收進來，讓你不用每次都跳出 IDE 去查 schema、試 query、看 container 狀態。這不是什麼炫技，這是減少 context switching。只要 database 工具真的好用，這種整合就很實在，尤其是你在做 migration、查 connection issue、驗證資料格式的時候。

實操上，我會把 IDE 內建的 database 工具當快速檢查區，不是唯一工作區。你可以在裡面看 schema、試 query、確認 local DB 連線、順手看 Docker 背後的服務狀態，但正式的資料庫流程還是要照團隊規範走。工具幫你快，不代表流程可以亂。

這裡提到的 DataGrip 不是亂塞的名字。DataGrip 本來就是 JetBrains 的資料庫產品，所以 RustRover 把那套能力借進來，邏輯上很順。對我來說，這種整合的意義很簡單：少開一個 app，少丟一點腦容量。

免費這件事有前提，別看一半就開心

JetBrains offers RustRover for free for non-commercial use.

這句話的意思是，學習、個人實驗、開源貢獻可以先用；一旦進到商業工作，費用就會出現。這很正常，但很多人會只看到前半句「free」，然後把後半句當沒看到。

我覺得這種授權最容易踩雷的地方，是你一開始把它當 side project 工具，後來專案變成接案、內部產品，或者直接進到公司流程，才發現 license 已經不只是背景資訊。那時候再補文件、補預算、補說明，通常都很尷尬。

實操寫法就是提早定義：這個 RustRover 是個人用，還是工作用。如果是學 Rust、玩專案、做自己的 open source，免費 non-commercial license 很合理。如果要拿來做商業開發，就直接把商業授權算進成本，不要裝作之後再說。這種事越早講清楚，越不會在 onboarding 或採購流程裡卡住。

我也覺得這個授權邏輯反過來解釋了產品定位。JetBrains 想賣的不是一個 Rust plugin，而是一個完整 Rust IDE。免費讓人先進來，商業授權支撐產品持續做下去。聽起來很現實，沒錯，本來就該這樣。

我會怎麼把它放進日常工作

如果是我自己要導入 RustRover 2026.2，我不會先搞一份很大張的遷移計畫。我會挑一個真的在跑的 Rust workspace，直接測四件事：從 Cargo.toml 開專案、跑測試、除錯一個失敗案例、碰一下有 macro 的模組。如果專案有 database，再順手測一下內建工具。這樣最容易看出它到底有沒有省時間。

我會特別觀察兩件事。第一是 setup friction 有沒有真的下降，第二是 IDE 在我工作時到底吃多少記憶體。前者決定它值不值得留，後者決定它是不是會把我的機器拖慢到想砸鍵盤。這兩個指標比功能清單誠實多了。

如果你問我這版最值得抄的思路是什麼，我會說：把 Rust 的工作流變成一個可重複、可共享、可直接啟動的環境。你不用把自己訓練成插件管理員，也不用每次進新 repo 都重新組裝一次世界。工具的工作就是把你帶到 code 前面，不是叫你先當半個 IT。

可抄的模板

# RustRover 2026.2 導入檢查清單

## 專案開啟
- 直接從 `Cargo.toml` 開啟 workspace
- 確認 workspace members、examples、tests 都有被辨識
- 檢查 TOML 編輯與補全是否正常
- 對照 `rustfmt` 驗證 formatter 行為

## 日常開發
- 從 IDE 直接跑單元測試與整合測試
- 除錯一個會失敗的測試案例
- 檢查 async 錯誤處理是否能被正確追蹤
- 在 macro-heavy 模組裡測試導覽與查找定義

## AI 使用規則
- 用 AI 產生測試骨架與註解說明
- 先檢查 ownership、lifetime、trait bound 再接受建議
- 對同一段 Rust code 比較不同模型的建議品質
- 不把 AI 輸出直接合併進主分支

## 團隊協作
- 把格式化與 run configuration 放進專案設定
- 將 inspection 與 coding style 規則視為團隊契約
- 檢查每個人的本機 IDE 行為是否一致
- 用 Git integration 處理 branch、diff、commit 流程

## 資料庫與容器
- 在 IDE 內檢查 schema 與 query
- 驗證本機資料庫連線
- 確認 Docker 管理不用跳出工作區
- 觀察是否能少開其他工具完成除錯

## 授權判斷
- 個人學習／開源：可用 non-commercial license
- 商業開發：先確認授權與採購流程
- 把授權規則寫進 onboarding 文件

## 最後判斷
- 如果你最痛的是 setup friction，優先試用
- 如果你最在意記憶體與極簡，先保留
- 如果你要團隊共用設定，值得做一輪實測

來源致謝：我主要拆的是 Warp2Search 這篇整理，內容衍生自 JetBrains 的 RustRover 2026.2 釋出資訊；上面模板與判斷是我自己的整理，不是原文直接貼上。