Go recover 在 defer 中返回后 named result 如何避免静默成功

遇到 Go 函数内部 panic，最容易留下一个“看起来成功”的 bug：defer 里确实调用了 recover，日志也打印出来了，但函数的 err 仍然是 nil。原因通常不是 recover 没生效，而是延迟函数没有把异常写回 named result。

为什么 recover 后会静默返回成功

Go 规定，函数返回时先设置结果参数，再执行 defer。named result 本质上是函数体内的局部变量，所以延迟闭包可以在返回前修改它。若函数签名是 func run() (err error)，进入函数时 err 默认就是 nil；panic 被恢复后，如果 defer 只记录日志，函数结束时仍会把这个 nil 返回给调用方。

func run() (err error) {
	defer func() {
		if r := recover(); r != nil {
			// 只记录日志不会改变 err，调用方仍可能看到成功。
			log.Printf("panic: %v", r)
		}
	}()

	panic("decode failed")
}

这个函数确实停止了 panic 继续向上冒泡，但“停止异常传播”和“给业务返回失败状态”是两件事。后一件事必须显式完成。

用 named result 把恢复结果写回返回值

最小可用的修复是把 panic 值统一转换成 error，并在恢复时清理已经写入的结果。未知类型的 panic 也要保留原始信息，避免排查时只得到一个空错误。

func run() (value string, err error) {
	defer func() {
		if r := recover(); r != nil {
			// recover 必须直接出现在被 defer 的函数中。
			switch v := r.(type) {
			case error:
				err = fmt.Errorf("run panic: %w", v)
			default:
				err = fmt.Errorf("run panic: %v", v)
			}
			// 失败时不要把半成品继续当作成功结果交给调用方。
			value = ""
		}
	}()

	value = loadValue() // 这里可能触发运行时 panic
	return value, nil
}

这里的 return value, nil 会先把两个结果参数设好，然后 defer 才有机会把 err 改成非 nil，并把 value 清空。恢复函数正常结束后，run 直接返回修改后的结果。

先查 recover 的作用域，再查返回状态

如果上面的写法仍然没有恢复，按下面的边界排查。第一，recover 必须是 defer 直接调用的函数体中的调用；把它藏在另一个普通函数里，调用时通常已经不处于有效的恢复位置。第二，panic 和 recover 必须属于同一个 goroutine；主 goroutine 的 defer 不能接住 worker goroutine 的 panic。

func worker(done chan

第三，确认 defer 没有被条件分支跳过，也没有在恢复后再次 panic。生产代码通常把 panic 转成带上下文的 error，再由上层决定重试、降级或记录；不要只依赖一行日志来表达失败。

用反向验证确认不会再“静默成功”

至少覆盖四个场景：正常返回、panic 一个 error、panic 一个字符串、以及 worker goroutine 发生 panic。正常返回要求 err == nil；后三类都要求调用方收到非 nil 错误。若结果值和错误同时出现，优先按本文示例在恢复分支清理结果，避免上层误用。

还要留意 named result 的遮蔽：函数体中用 err := 声明了新的局部变量后，defer 修改的仍是外层 named result。需要把中间错误明确赋给 named result，或使用不同名称，避免“日志里有错误、返回值却成功”的第二种变体。

常见问题

recover 调用后为什么拿到 nil？

通常是没有处于 panic 状态，或者 recover 不是由当前 defer 直接调用。先把调用放回同一延迟闭包中，再检查 panic 是否发生在同一 goroutine。

不使用 named result 能不能恢复？

可以恢复 panic，但不方便在 defer 中改写返回值。若要把 panic 转为 error，named result 是最直接的边界；否则应把恢复逻辑放在明确的包装函数中统一返回状态。

恢复后还需要重新 panic 吗？

只有当前层无法承担错误语义时才重新 panic。对普通业务入口，更稳妥的做法是转换为带上下文的 error，让调用方决定后续动作。