Go panic 为什么不能用 error 返回给调用方

我在接手一段 Go 代码时，最容易误判的一件事是：函数里已经有了 panic，是不是把它当成 error 交给调用方就够了？答案是否定的。panic 不是另一种返回值，它会停止当前函数的普通执行，沿当前 goroutine 的调用栈展开；只有合适的 defer 中调用 recover，才能在边界处接回控制权。

因此，能预期、能解释、调用方可以决定怎么处理的失败，应当显式返回 error；只有“不应该继续当前路径”的程序异常，才考虑使用 panic。下面按一次完整排查的顺序，把两者的边界说清楚。

先把两个概念放回正确位置

error 是函数签名的一部分。调用方可以读取它、包装它、重试它，或者把它转换成自己的响应。它不会改变函数之外的控制流，调用方仍然可以决定下一步。

panic 则是控制流动作：当前函数在触发点停止，已经登记的 defer 按后进先出执行，然后把异常继续交给上层。它没有“返回给调用方”这个普通返回语义；调用方只有在自己或更外层设置了恢复边界时，才可能继续工作。

沿调用栈看清 panic 到底发生了什么

官方对 panic 的描述可以归纳成四个检查点：触发函数停止；该函数的 defer 仍会执行；调用方接收到的是一次继续展开的 panic；展开到当前 goroutine 顶部且无人恢复时，程序终止。

我通常会先画出“谁负责恢复”的边界，再决定是否保留 panic。下面这个例子只展示机制，不代表所有服务都应该这样写：

func handleField(input string) (value int, err error) {
	// 恢复必须放在 defer 中，并把异常转换成调用方能处理的 error。
	defer func() {
		if recovered := recover(); recovered != nil {
			// panic 的值不一定实现 error，所以先用 %v 保留原始信息。
			err = fmt.Errorf("字段解析异常：%v", recovered)
		}
	}()

	// 这里代表内部已经确认不应继续的状态，而不是用户输入校验失败。
	if input == "" {
		panic("内部字段缺失")
	}
	return len(input), nil
}

这个函数的关键不是“把所有 panic 都吞掉”，而是把恢复放在明确的边界：内部实现遇到不可继续状态，边界层负责记录上下文并转换成稳定的 error。如果没有这个 defer，panic 会继续向上展开，调用方无法像检查返回值一样自然地处理它。

可预期失败为什么应该直接返回 error

文件不存在、参数格式不对、权限不足、远端返回业务拒绝，这些情况都属于调用方可以预先考虑的分支。把它们写成 error，调用方才能明确决定是提示用户、重试、降级还是终止当前请求。

func loadConfig(path string) ([]byte, error) {
	// 文件路径来自调用方，读取失败属于可预期的外部错误。
	data, err := os.ReadFile(path)
	if err != nil {
		// 包装原始错误，让上层既能读懂上下文，也能继续 errors.Is 判断。
		return nil, fmt.Errorf("读取配置 %q：%w", path, err)
	}
	return data, nil
}

这里如果改成 panic(err)，调用方就失去了稳定的返回协议：它必须依赖恢复逻辑才能知道文件为什么没读到。Go 标准库的惯用方式也是让包内部必要时使用 panic 展开，再在对外 API 处恢复并返回显式错误。

什么时候可以在边界处恢复

恢复适合放在明确的边界，例如一个请求处理器、插件调用层或库的顶层入口。边界之外的代码仍然使用普通 error 协议，避免每一层都偷偷捕获异常，导致真正的程序错误被静默隐藏。

判断时可以记住这张表：

最后再提醒一个边界：recover 只能恢复同一个 goroutine 中正在展开的 panic。它不是跨 goroutine 的错误通道，也不会自动把任意 panic 变成安全的业务结果。

常见问题

panic 的值是 error，就能当作 error 返回吗？

不能直接这样理解。即使传入 panic(err)，它仍然先触发 panic 语义；只有恢复函数拿到这个值后，显式赋给命名返回值，才形成调用方可读取的 error。

每个函数都加 recover 是否更安全？

通常不是。过早恢复会隐藏堆栈和程序缺陷。更稳妥的做法是在少量、职责明确的边界统一恢复，并把原始值、调用上下文和处理结果记录清楚。

结论

error 是可预期失败的显式协议，panic 是异常控制流，两者不是可以互换的返回类型。把正常输入和业务问题返回为 error，把不可继续的内部状态限制在清晰边界内；确实需要保护边界时，再用 defer 中的 recover 转成稳定的错误结果，这就是最容易维护的分工。