你的旧 Go 代码，Go 1.26 能一键救回来

Mon, 13 Jul 2026 00:00:00 +0000

你有没有这种代码——

1
2
3


for i := 0; i < n; i++ {
 ...
}

Go 1.22 之后可以写成 for range n。你知道，但三年了，你还没改。

或者这种——

1
2


eq := strings.IndexByte(pair, '=')
result[pair[:eq]] = pair[1+eq:]

Go 1.18 就有 strings.Cut 了。你知道怎么用，但一直没动手。

我猜你的项目里不止一处这种「知道有更好的写法，但优先级排不上号」的代码。你甚至列过 Refactoring 工单，然后排到了下周，再然后就没有然后了。

这不是你的问题。这是大多数 Go 项目的真实状态：

知道该改，但没人专门花时间去改。

但从 Go 1.25 开始，情况变了。不是因为你变勤快了，而是工具链开始替你动手了。

真正的主角不是新特性，是 `go fix`

每到一个新版本，我们习惯先把 release notes 扫一遍，看有没有好用的新语法、新标准库。

但 Go 1.25 和 1.26 真正重要的变化，不在新特性本身，而在一个你可能忽略的子命令：

1

$ go fix ./...

go fix 不是什么新东西。它从 Go 1 就有了，以前只是偶尔用来修一下 build tag 格式之类的小补丁。但在 Go 1.26 里，它被彻底重写了——底层不再是独立代码，而是和 go vet 共用了同一个分析框架。

一个 goroutine 崩了，为什么你的 recover 根本接不住？

Mon, 13 Jul 2026 00:00:00 +0000

你在 HTTP 服务最外层加了 recovery middleware，以为兜底已经做完。后来某个 handler 里随手起了一个 goroutine；它空指针了，整个进程还是退出。

这不是 middleware 没挂上，也不是 recover 偶发失灵。是那个 goroutine 从来不在你的 recover 覆盖范围里。

很多人把 defer 记成“后进先出”，这句话没错，却少了决定线上行为的半截：defer、panic 和 recover 都是在当前 goroutine 上完成的。 你放进一个函数的清理动作，没法替另一个 goroutine 收尾；你放在外层的 recover，也接不住另一个 goroutine 的 panic。

这篇不复述语法。只解决几个在代码评审和事故现场会真正出问题的判断：defer 到底放在哪里，循环里为什么危险，recover 为什么看起来写了却没用，以及 panic 到底该不该出现在业务代码里。

`defer` 不是一摞万能清理卡，它属于当前 goroutine

从语言语义看，defer 把一次函数调用登记下来，外层函数返回时再按后进先出的顺序执行。参数在登记那一刻就已经求值；它也能读写命名返回值。

这套规则足够写业务，但解释不了两个现象：为什么循环里的 defer rows.Close() 会拖住资源，为什么父函数的 recover 接不住子 goroutine。

把视角往 runtime 推一步，老路径里每次执行 defer，会形成一个 _defer 记录。Go 1.25 的 runtime 源码里，_defer 有 sp、pc、fn 和 link 字段；link 的注释写得很直接：它是 next defer on G。这里的 G 就是 goroutine。

Golang on Zampo Blog

你的旧 Go 代码，Go 1.26 能一键救回来

真正的主角不是新特性，是 go fix

一个 goroutine 崩了，为什么你的 recover 根本接不住？

defer 不是一摞万能清理卡，它属于当前 goroutine

真正的主角不是新特性，是 `go fix`

`defer` 不是一摞万能清理卡，它属于当前 goroutine