前言
脫離了 Flutter 的光環，Dart 到底還剩下什麼？在嘗試將它用來撰寫核心邏輯與後端工具後，我們總結了五個核心觀察。
這不是一篇盲目推廣的文章，而是對於技術選型的冷靜思考。
語法成熟度：足以支撐穩健開發
Dart 在 3.0 之後引入了完全的 Null Safety，這對程式碼的穩健性有著本質上的提升。
- 開發體驗 (DX)：它的語法融合了 Java 的嚴謹與 TypeScript 的靈活性。
- 現代特性：Pattern Matching 與 Records 等新特性，讓邏輯撰寫變得非常現代且直覺。
就語法本身而言，Dart 已經是一門非常成熟且文明的語言。
定位：不需要密集運算時的「高級 Shell」
對於不需要大量 CPU 運算的工具程式來說，Dart 展現了極強的競爭力：
- 超越 POSIX sh：在傳統 Shell 腳本中，我們常被迫在各種命令列工具間用 Pipe 傳遞字串，並在正則表達式（RegEx）中奮戰。
- 資料結構優勢：Dart 內建豐富的資料結構，讓我們不需要跟字串死磕。
- 內建 EXE 編譯：
dart compile exe提供的單一執行檔分發能力，讓它成為撰寫開發者工具（DevTools）與 CLI 的絕佳選擇。
FFI：優雅與現實的拉鋸點
當開發者需要透過 FFI (Foreign Function Interface) 調用 C 庫時，Dart 封裝出的「美顏濾鏡」便會開始消散，直面底層的粗獷：
- 開發成本提升：開發者必須手動重寫 Function Prototype、處理指標運算，並親自管理記憶體分配。
- 複雜度上限：若僅是為了效能將少量關鍵程式碼移交給 C，尚在可接受範圍；但這也揭示了現狀：Dart 的 FFI 僅止於「能用」，而非「優雅」。
實務上，常見做法是以 Docker 封裝 C 函式庫，並僅針對核心需求撰寫 Partial Binding，避免為了少數功能去維護一整套 Binding 的維護負擔。
此外，Dart FFI 目前無法直接處理 C++ 庫，必須先包裹一層 C Wrapper 作為橋樑，這無疑又增加了一層轉換成本。
後端戰場：當 Dart 遇上 Kotlin
對於不需要介接外部語言的純 Dart 後端，雖然具備「可用性」，但生態系的匱乏仍是難以忽視的硬傷。
- 與 Kotlin 的競爭優勢缺位：在後端領域，Kotlin 的強大來自於 Spring Boot 框架以及背後海量的 Java 生態庫。
- 選型邏輯的侷限：除非專案的核心訴求在於與 Flutter 前端高度共用邏輯（Code Sharing），否則在後端生產環境中，很難找到捨棄 Kotlin 或 Java 而轉向 Dart 的決定性動機。
警訊：當 Sidecar 出現，代表已偏離軌道
這是一個關鍵的體悟：當開發者必須透過 Sidecar 模式來橋接其他語言的邏輯時，往往意味著 Dart 已在系統架構中成為了「贅肉」。
- 拒絕低效的強行膠合：這種硬湊的架構不僅引入了額外的序列化（Serialization）開銷，更大幅提升了維護成本。
- 回歸架構決策本質：此時不應繼續在語言層面掙扎，而應考慮將重型邏輯拆分為獨立的 Microservice（微服務），透過標準協定進行通訊，而非強行維護一層脆弱且低規律的 Glue Code（膠水層）。
結語
Dart 在 Flutter 之外最好的位置，是一個 「語法現代化、且自帶編譯優勢的高級 Shell」。
它能讓你優雅地調度系統資源、撰寫工具，但不該強迫它去承載它生態系還扛不動的重型核心。看清技術的邊界，才能發揮它真正的價值。