https://blog.cpdd.fyi/tags/recover/Recent content in Recover on Zampo BlogHugozh-cnMon, 13 Jul 2026 00:00:00 +0000https://blog.cpdd.fyi/posts/go-defer-panic-recover/Mon, 13 Jul 2026 00:00:00 +0000https://blog.cpdd.fyi/posts/go-defer-panic-recover/<p>你在 HTTP 服务最外层加了 recovery middleware，以为兜底已经做完。后来某个 handler 里随手起了一个 goroutine；它空指针了，整个进程还是退出。</p> <p>这不是 middleware 没挂上，也不是 recover 偶发失灵。是那个 goroutine 从来不在你的 recover 覆盖范围里。</p> <p>很多人把 <code>defer</code> 记成“后进先出”，这句话没错，却少了决定线上行为的半截：<strong>defer、panic 和 recover 都是在当前 goroutine 上完成的。</strong> 你放进一个函数的清理动作，没法替另一个 goroutine 收尾；你放在外层的 recover，也接不住另一个 goroutine 的 panic。</p> <p>这篇不复述语法。只解决几个在代码评审和事故现场会真正出问题的判断：<code>defer</code> 到底放在哪里，循环里为什么危险，recover 为什么看起来写了却没用，以及 panic 到底该不该出现在业务代码里。</p> <h2 id="defer-不是一摞万能清理卡它属于当前-goroutine"><code>defer</code> 不是一摞万能清理卡，它属于当前 goroutine</h2> <p>从语言语义看，<code>defer</code> 把一次函数调用登记下来，外层函数返回时再按后进先出的顺序执行。参数在登记那一刻就已经求值；它也能读写命名返回值。</p> <p>这套规则足够写业务，但解释不了两个现象：为什么循环里的 <code>defer rows.Close()</code> 会拖住资源，为什么父函数的 recover 接不住子 goroutine。</p> <p>把视角往 runtime 推一步，老路径里每次执行 defer，会形成一个 <code>_defer</code> 记录。Go 1.25 的 runtime 源码里，<code>_defer</code> 有 <code>sp</code>、<code>pc</code>、<code>fn</code> 和 <code>link</code> 字段；<code>link</code> 的注释写得很直接：它是 <strong>next defer on G</strong>。这里的 G 就是 goroutine。</p>