Go 1.26 讓 slice 更少上 heap

Go 1.25 和 Go 1.26 做了一件很務實的事。它們讓更多 slice 留在 stack 上。這代表 GC 要掃的 heap 變少，服務延遲也可能更穩。

更有趣的是，Go 1.26 甚至能把一些最後會逃逸的 slice 先放在 stack。這種編譯器調整不會吵著要你升級架構。它只會默默省掉一些背景工作。

這週的 Golang Weekly 也很有料。GoLand 2026.1、pgx 5.9，還有 go-sqlite3 更新，都在同一週冒出來。說真的，這很像 Go 圈子在集體做體質管理。

Go 1.26 把更多 slice 留在 stack

先講重點。Go 的 GC 壓力，很多時候不是大物件造成的。反而是大量短命 slice，像 request handler、parser、JSON 轉換、字串切片，這些小東西一直生一直死。數量一多，GC 就得跟著忙。

Go 1.25 和 1.26 的改進，就是把更多 slice 直接放在 stack。這樣一來，heap allocation 變少，GC 要追的東西也少。對高流量服務來說，這種變化通常比「平均 latency 降了幾毫秒」更有感。因為 tail latency 才是使用者會抱怨的地方。

Go 1.26 還多做了一步。某些最後會 escape 到 heap 的 slice，也能先在 stack 上完成前段工作。講白了就是，編譯器先幫你做便宜的事，再把需要活更久的資料搬走。這不是魔法，是編譯器對生命週期判斷更準了。

如果你有在看 pprof，這種優化很容易對上症狀。allocation count 下降，GC CPU 下降，request 尖峰時的抖動也可能變小。當然，實際效果還是要看你的程式型態。不是每個專案都會賺到同樣幅度。

• Go 1.25 和 1.26 都強化了 slice 的 stack allocation。
• Go 1.26 連部分會 escape 的 slice 也能先放 stack。
• heap allocation 少，GC 背景工作通常也少。
• 這類優化對 tail latency 常比平均值更有感。

名字、錯誤訊息，還有那些省時間的小事

這週我也想提一下 Alex Edwards 的 Go naming guide。這篇不是什麼炫技內容，但很實用。它談 identifier、檔名、package 名稱，還有他說的 avoiding chatter。意思就是把名字縮到只剩必要資訊。

你可能會想問，名字真的有那麼重要嗎？有，而且很煩。爛名字會拖慢 code review，讓 API 看起來像亂碼，還會把本來 5 分鐘能懂的程式，拖成 30 分鐘的考古。對團隊來說，這就是隱形成本。

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton

這句話老到不行，但還是很準。因為命名不是一次性的工作。每個人讀 code、改 code、寫文件，都會再付一次代價。名字取得爛，成本就一直滾。

同一週還有一個很實際的 compiler 修正。Go 1.26 的 type checker，現在能更早抓到 incomplete type 被拿去做需要完整定義的事情。這種錯誤以前可能會冒出很怪的訊息，現在會更接近真正原因。少走幾次彎路，對大型 codebase 很有差。

• Alex Edwards 的文章涵蓋 identifier、檔名、package 名稱。
• 他提的 avoiding chatter，很適合團隊 code style。
• Go 1.26 改善 incomplete type 的錯誤偵測。
• 更好的錯誤訊息，能少掉很多 debug 時間。

工具鏈也在跟著變強

Go 的有趣之處，在於它不是只靠語言本身撐場。工具鏈和套件庫也一直往前走。像 GoLand 這次的 2026.1 版本，就加入 Go 1.26 的 guided syntax updates，還支援 git worktrees。對大 repo 團隊來說，worktree 比一直 stash 來得乾淨很多。

再看資料庫這邊，pgx 5.9 加了 SCRAM-SHA-256-PLUS、OAuth authentication、Postgres protocol 3.2，還有 tsvector 支援。這些更新很像是給 production 團隊的實用補丁，不是展示用功能。

另一個很妙的是 go-sqlite3 v0.33.0。它從早期的 WebAssembly 路線，轉向用 wasm2go 把 SQLite 轉成 Go。這種做法很有工程味。你少了一些跨語言 runtime 的包袱，但底層實作方式也完全不同。

如果你在做 TUI，Bubble Tea 也有更新。Bubbles 2.1 加了自動調整大小的 textarea。Fantasy v0.17.0 則加入 Anthropic Computer Use support。Go 生態圈現在真的橫得很廣。

• GoLand 2026.1 支援 Go 1.26 與 git worktrees。
• pgx 5.9 加入 SCRAM-SHA-256-PLUS、OAuth、protocol 3.2。
• go-sqlite3 v0.33.0 改用 wasm2go。
• Bubbles 2.1 加入自動調整 textarea。
• Fantasy v0.17.0 支援 Anthropic Computer Use。

這些更新對 production Go 代表什麼

我覺得這週最值得看的，不是單一功能，而是整體方向。Go 一直在把「少做無謂工作」這件事做得更細。編譯器更會省 allocation，type checker 更早報錯，IDE 也更懂新語法。這些都很務實。

如果你是跑 production 的團隊，這類改善通常比新語法更有感。因為你每天面對的是成本、延遲、錯誤率，不是 demo。少一點 heap allocation，就可能少一點 GC 抖動。少一個難懂的錯誤，就可能少一小時排查。

競品面也可以順手比一下。Rust 很強，但學習成本高。Java 的 GC 工具很成熟，但 runtime 複雜度也高。Go 的路線一直很明確，就是讓編譯器和標準工具替你省事。這次的 stack allocation 改進，就是這條路線的延伸。

如果用數字來看，差異通常會出現在 allocation 次數、GC CPU、以及 p95 / p99 latency。很多團隊在升版前後做 benchmark，常常會看到 allocation 減少 10% 到 30%。實際數字還是要看程式本身，但這已經夠讓人想升了。

• Go 走的是低心智負擔路線。
• Rust 偏向嚴格控制與高學習成本。
• Java 偏向成熟 runtime 與複雜 GC 調校。
• Go 這次的收益，多半會出現在 allocation 和 tail latency。
• 升版前後跑 benchmark，才知道有沒有吃到紅利。

Go 為什麼一直在修這些細節

Go 不是那種常常丟大招的語言。它比較像一直在磨刀。這次的 slice stack allocation、type checker 修正、IDE 支援，都是同一種思路。把日常開發裡最常卡住的地方，一點一點磨平。

這也很符合 Go 的使用場景。很多團隊用它做 API server、worker、資料處理管線、CLI 工具。這些東西不需要花俏。它們需要的是穩、快、好維護。編譯器和工具鏈只要能少出一點怪事，團隊就能少花很多時間救火。

另外，Go 社群現在也很成熟。像 Golang Weekly 這種整理，會把語言、工具、套件、文章一起串起來。對開發者來說，這比只看 release note 更接地氣。你可以直接看到哪些更新真的會碰到工作流。

我會怎麼看這波更新

如果你有在維護 Go 服務，我會建議你盡快測 Go 1.26。先看 allocation benchmark，再看 p95、p99 latency。不要只看平均值，平均值很會騙人。真正影響使用者的，常常是尾端那幾筆。

如果你的程式有很多短命 slice、JSON 轉換、字串切片、或 request-level 的資料整理，這次很可能有收穫。反過來說，如果你的瓶頸在 I/O、SQL、外部 API，這次改善可能沒那麼明顯。但至少你會得到更好的錯誤訊息和更順的工具鏈。

我的預測很直接。接下來幾個 Go release，還會繼續往 allocation、診斷、工具整合這三個方向磨。你現在該做的，不是等別人告訴你有沒有差，而是自己先跑一輪 benchmark。真的有差，才知道這波更新值不值得你排進升版時程。