為什麼 Go 的發布政策比 LTS 更好
Go 不設 LTS、只維持兩個主要版本支援，反而更適合需要可預測升級與較少舊依賴的團隊。
Go 不設 LTS，改用固定支援兩個主要版本的政策，逼團隊按節奏升級，減少長期停在舊版的風險。
Go 應該維持現行做法：不走 LTS，只有嚴格的兩個主要版本支援窗，迫使團隊按時升級。這不是理論爭辯，現況已經說明一切。以 2026 年 5 月 18 日來看，Go 1.26.3 是最新穩定版，1.26 與 1.25 仍受支援，1.24 已經停止維護。這種節奏不是缺點，而是設計本意。
第一個論點：Go 的節奏本身就是優勢
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Go 大約每六個月推出一次主要版本，期間再補小修版。這種頻率讓語言持續演進，又不至於把每次維護都變成災難級升級。從版本紀錄看，1.26.0 在 2026 年 2 月 10 日發布，1.26.3 在 5 月 7 日跟進，1.25.0 則在 2025 年 8 月 12 日推出。這就是可預測的進步。
對比那些把長期支援當預設的生態，LTS 很容易變成拖延的遮羞布。團隊會因為「還有支援」而停在舊主版本，最後累積的是 runtime 偏移、套件相容性問題與安全債。Go 的政策把這個陷阱縮小到最低。當只有最近兩個主要版本受支援時，升級就會變成日常工程，而不是臨時救火。
第二個論點：兩個主要版本的支援窗已經足夠
Go 的支援規則很直接：最近兩個主要版本可獲得 bug 修正與重大安全更新，更舊的版本一律 EOL。這不是寬鬆，而是夠強。它意味著跑在 production 的服務不會落後主線太遠，也不必等好幾年才看到安全修補。對一個面向後端、微服務、API 與雲端工具的語言來說，這比「LTS」這個行銷名詞更重要。
版本表也證明這套制度能運作。Go 1.24 在 2025 年 2 月 11 日發布，並在 2026 年 2 月 10 日結束支援；1.23 也遵循同樣模式，在 1.24.0 發布後不久停止維護。這代表每個主要版本大約有一年的實際支援時間，前提是團隊維持正常升級節奏。若一個團隊無法在這個窗口內升級，問題通常不在 Go，而在自己的依賴管理。
反方可能怎麼說
支持 LTS 的最強論點是營運舒適度。企業希望更少升級、更少回歸風險，也希望把語言升級和平台改版一起排程，特別是在受監管環境裡，每次變更都要審查。從紙面上看，長期支援版本確實更像安全選項，因為它減少了變動頻率，讓團隊能持續交付，而不用每幾個月碰一次 runtime。
這個說法並不天真。確實有些組織的流程重到六個月一次的節奏會很痛，也有些產品團隊寧可把時間花在功能而不是依賴維護上。對這些團隊來說，LTS 提供了一個熟悉的故事：先凍結在可信版本，等到真的不得不動再說。
但這種舒適是錯覺。Go 的模型承認一個現實限制：團隊必須為定期升級預留資源；換來的是更健康的基線、更少的未支援安裝，以及不依賴某個老舊分支苟延殘喘的安全姿態。版本資料把取捨講得很清楚：一旦版本掉出最近兩個主要版本，就不再獲得更新。這很嚴格，但也正因如此才有效，它避免生態裡堆滿「還能編譯、卻早已不值得信任」的舊版本。
你能做什麼
如果你是工程師，不要把 Go 升級當成可有可無的整理工作。追蹤目前受支援的主要版本，在現行版本接近 EOL 前先對下一版做測試，並把版本檢查納入 CI。如果你是 PM 或創辦人，替 Go 服務預留每年一次的升級窗口，並把它視為可靠性工作的一部分。真正的目標不是逃避變動，而是始終貼近發布線，讓安全性、相容性與效能改善在支援結束前進到 production。