我用 Go 三年的體會：從別的語言轉過來最有感的幾件事

我不是一開始就寫 Go 的。轉過來之後，有些東西讓我覺得「終於有人把這件事做對了」，也有些東西一開始很不習慣。這篇不是語法教學，而是我實際拿 Go 寫後端服務之後，最有感的幾個體會，給正在考慮或剛轉過來的人參考。

最有感的：部署簡單到不可思議

讓我決定認真用 Go 的，其實是部署。Go 編譯出來是一個靜態的單一執行檔，沒有 runtime 依賴、不用裝一堆環境。丟到伺服器就能跑，塞進一個極小的容器映像檔也輕鬆。

跟我以前需要喬執行環境、套件版本的經驗比起來，這種「編譯完丟上去就好」的乾淨感，對維運的心智負擔降低非常多。一個後端工程師會越來越在意這種事。

語言刻意保持「無聊」，這是優點

Go 的語法少到有點極端：沒有繼承、沒有泛型很久（後來才加）、連三元運算子都沒有。剛開始我覺得綁手綁腳。寫久了才懂這是刻意的——它讓每個人寫出來的 Go 都長得差不多。

接手別人的 Go 專案，我幾乎不需要適應「個人風格」，因為語言沒給你耍花招的空間。對需要長期維護、多人協作的後端來說，「無聊、可預測」比「強大、靈活」更值錢。gofmt 直接終結了所有排版爭論，這點我超喜歡。

並發是內建的，而且好用

goroutine 和 channel 是 Go 最招牌的特色。用一個 go 關鍵字就能開一條輕量的執行緒，初始堆疊只有 2KB，一個程式跑上萬個 goroutine 很正常。

但真正的重點不是「能開很多」，而是它讓「並發」變成你會自然去用的工具，而不是高風險的特技。我在金流和撮合系統裡大量用到，之後有專門一篇講實際的模式。剛入門先記住一句話：不要用共享記憶體來通信，要用通信來共享記憶體。

錯誤處理很囉嗦，但你會感謝它

Go 沒有 try-catch，函式直接回傳 error，你要自己一層層判斷。剛轉過來時，滿螢幕的 if err != nil 真的讓我煩躁。

但寫金流系統之後我改觀了。這種囉嗦強迫你在每一個可能失敗的地方，當下就決定要怎麼處理——是要回傳、包裝、還是記錄。錯誤不會被你不小心忽略、也不會神不知鬼不覺地往上拋穿好幾層。在「不能出錯」的系統裡，這種顯式的麻煩反而是安全感的來源。

interface 是隱式實作，思維要轉個彎

Go 的 interface 不需要明確宣告「我實作了這個介面」，只要方法簽名對上就算數。一開始會不太適應，但這帶來一個很好的習慣：介面由使用方定義，而不是實作方。

你可以在用到的地方定義一個小小的介面，只放你需要的那幾個方法。這讓解耦和寫測試變得很自然——要 mock 一個依賴，只要做一個符合那個小介面的假物件就好，不用拖進一整個龐大的型別。

我會給新手的建議

• 先別急著找框架。Go 的標準函式庫（尤其 net/http）已經能做很多事，先用原生的把概念搞懂
• 把 gofmt、go vet 加進流程，讓工具幫你管風格和低級錯誤
• 認真理解 error 處理與 context 的傳遞，這是寫正式服務的基本功
• 並發很好用，但別濫用 goroutine；先想清楚「誰負責關閉、誰負責等待」

小結

Go 不是最酷、最有表達力的語言，但它在「寫出能長期維護、好部署、並發友善的後端服務」這件事上，做了非常務實的取捨。對我來說，它無聊得恰到好處。如果你的工作是把可靠的服務穩穩地交付出去，Go 很值得認真學。