Go defer 中再次 panic 时怎么保留原始 panic 信息

如果业务函数已经 panic，defer 里的清理动作又 panic，最容易丢掉的是“最初为什么失败”。稳妥的做法不是依赖运行时打印出的两段信息，而是在外层 deferred function 里直接 recover 原始值，再把清理动作放进一个局部 recover 边界；两者同时失败时，重新 panic 一个同时保存两类值的结构。

先捕获原始 panic，再捕获清理 panic，最后按“只有原始、只有清理、两者都有”三种情况决定重新抛出什么。这样调用方拿到的值是稳定可识别的，而不是被清理代码偶然覆盖。

为什么清理阶段的第二次 panic 会让原始信息变得不可靠

Go 的 panic 会沿当前 goroutine 的调用栈展开，相关 defer 按后进先出执行。正常情况下，defer 只负责关闭资源、解锁或写入收尾信息；但如果清理代码本身访问了失效对象、重复关闭了不安全资源，或者主动调用了 panic，就形成了第二个 panic。

这时不要把运行时最终输出当作业务协议。程序日志可能同时出现两条 panic，但调用方真正能通过 recover 消费的是当前 panic 值。更可靠的做法是自己定义组合值，把“业务异常”和“清理异常”放在不同字段里。

先在外层 recover 原始 panic，再隔离清理 panic

关键细节是 recover 的位置。它只有在 panic 展开期间、并且由 deferred function 直接调用时，才能拿到当前 panic 值。因此不能写成 defer recoverOriginal()，也不能在普通函数里间接调用它。

package panicchain

import "fmt"

// PanicChain 同时保存业务阶段和清理阶段的 panic 值。
type PanicChain struct {
	Original any // 业务函数最先抛出的值
	Cleanup  any // 清理函数后来抛出的值
}

// Error 让 PanicChain 也能被日志和 error 处理代码识别。
func (p PanicChain) Error() string {
	return fmt.Sprintf("original panic: %v; cleanup panic: %v", p.Original, p.Cleanup)
}

// capturePanic 只负责隔离一次清理调用，不让它继续向外覆盖原始值。
func capturePanic(cleanup func()) (value any, panicked bool) {
	defer func() {
		if r := recover(); r != nil {
			value, panicked = r, true // 在本层记录清理 panic
		}
	}()
	cleanup()
	return nil, false
}

// Run 在一个 goroutine 内执行 work，并把清理异常纳入同一条 panic 信息。
func Run(work, cleanup func()) {
	defer func() {
		original := recover() // 必须由这个 deferred function 直接调用
		cleanupValue, cleanupPanicked := capturePanic(cleanup)

		switch {
		case original != nil && cleanupPanicked:
			panic(PanicChain{Original: original, Cleanup: cleanupValue})
		case original != nil:
			panic(original) // 只有业务失败时保留原值
		case cleanupPanicked:
			panic(cleanupValue) // 只有清理失败时抛出清理值
		}
	}()

	work()
}

这里的 capturePanic 使用自己的 deferred function 直接调用 recover，所以清理 panic 会被转换成普通返回值。外层 defer 仍然掌握最终决定权，cleanup 不会被重复调用。

根据三种结果决定是否重新 panic

这段代码的分支顺序很重要。业务 panic 存在时，cleanup 必须先执行，但不能让 cleanup 的异常直接冲出当前 defer；只有在两个值都拿到后，才构造 PanicChain。业务正常而 cleanup 失败时，则没有原始值可保留，直接抛出清理值即可。

调用方可以在自己的边界统一记录：

defer func() {
	if r := recover(); r != nil {
		if chain, ok := r.(PanicChain); ok {
			// 两类异常分别记录，避免只看最后一条 panic 文本。
			log.Printf("work panic=%v cleanup panic=%v", chain.Original, chain.Cleanup)
			return
		}
		log.Printf("panic=%v", r) // 兼容普通 panic 值
	}
}()

如果系统不允许 panic 穿过边界，也可以在这里把 PanicChain 转换为显式 error。不要在 Run 内悄悄吞掉异常，否则调用方会误以为清理和业务都成功。

生产代码里还要守住哪些边界

• 能返回 error 的清理函数优先返回 error；只有必须保持 panic 语义的边界，才使用上面的组合值。
• 多个清理动作最好先合并成一个 cleanup 函数，明确执行顺序，避免多个独立 defer 互相覆盖语义。
• 每个 goroutine 都要在自己的入口设置 recover；一个 goroutine 的 defer 无法替另一个 goroutine 接住 panic。
• 测试至少覆盖四个表格分支，并断言 PanicChain.Original 和 PanicChain.Cleanup 的动态类型没有丢失。

还有一个实际取舍：如果清理失败只影响诊断，不影响资源安全，可以记录后继续抛原始 panic；如果清理失败意味着数据可能未落盘，就应该把两者组合后交给上层，而不是为了“保持原始值”把清理问题隐藏掉。

相关问题

为什么不能把 recover 抽成普通函数？

因为 Go 规范要求它由 deferred function 直接调用。普通 helper 中的 recover 不处在这个直接调用位置，通常只能得到 nil。

panic 值一定是 error 吗？

不一定。它可以是字符串、结构体、指针或其他接口值，所以 PanicChain 用 any 保存，不能强制断言成 error。

另一个 goroutine 的 panic 能在这里恢复吗？

不能。panic 和 recover 只在同一个 goroutine 的展开链上生效；启动 goroutine 时应在 goroutine 入口单独设置 defer。