本文介绍在 go 中优雅处理 panic 并对引发 panic 的同一参数进行自动重试的两种主流方案：一是将 panic 改为 error 返回并使用递归/循环重试；二是保留 panic 但通过 defer+recover 将其转为 error，再封装重试逻辑。
本文介绍在 go 中优雅处理 panic 并对引发 panic 的同一参数进行自动重试的两种主流方案：一是将 panic 改为 error 返回并使用递归/循环重试；二是保留 panic 但通过 defer+recover 将其转为 error，再封装重试逻辑。
在 Go 开发中，panic 是一种严重的运行时错误机制，一旦触发即中断当前函数执行流，并向上冒泡直至被 recover 捕获。然而，原始代码中仅用 defer/recover 捕获 panic 后直接继续外层循环，导致“失败即跳过”，无法对失败参数（如 i == 3）重试——这在重试敏感场景（如网络请求、临时资源竞争）中是不理想的。
要实现「对引发 panic 的同一参数自动重试」，核心思路是：将不可控的 panic 转化为可控的 error，并围绕 error 构建重试逻辑。以下是两种推荐实践：
✅ 方案一：推荐 —— 使用 error 替代 panic（首选）
将可能失败的操作设计为返回 error，而非触发 panic。这样可天然兼容 Go 的错误处理生态，并便于构建健壮的重试机制：
package main
import (
"errors"
"fmt"
)
func test(i int) error {
if i == 3 {
return errors.New("operation failed for i=3")
}
return nil
}
func retryWrapper(i int, maxRetries int) {
for try := 1; try <= maxRetries; try++ {
fmt.Printf("i: %d try: %d\n", i, try)
if err := test(i); err == nil {
return // success, exit retry loop
}
if try < maxRetries {
fmt.Printf("retrying i=%d (attempt %d/%d)...\n", i, try+1, maxRetries)
} else {
fmt.Printf("giving up on i=%d after %d attempts\n", i, maxRetries)
}
}
}
func main() {
for i := 1; i < 5; i++ {
retryWrapper(i, 3) // 最多重试 3 次
}
}该方案清晰、可测试、无栈溢出风险，且符合 Go 的惯用法（Don’t panic, handle errors）。
⚠️ 方案二：兼容遗留 panic 代码 —— recover + error 转换
若无法修改原始 test 函数（例如第三方库或遗留代码），可在其外围加一层包装，用 defer/recover 捕获 panic 并统一转为 error：
func testWithRecover(i int) error {
var err error
defer func() {
if r := recover(); r != nil {
switch v := r.(type) {
case string:
err = errors.New(v)
case error:
err = v
default:
err = fmt.Errorf("panic: %v", r)
}
}
}()
test(i) // 原始可能 panic 的函数
return err
}然后复用上述 retryWrapper，传入 testWithRecover 即可：
func main() {
for i := 1; i < 5; i++ {
retryWrapper(i, 3) // 此处调用的是 testWithRecover(i)
}
}? 重要注意事项：
- 永远限制重试次数（如 maxRetries=3），避免无限循环或雪崩；
- recover() 只在 defer 函数中有效，且仅捕获当前 goroutine 的 panic；
- 避免在 recover 后继续执行可能依赖失败状态的逻辑，应明确失败路径；
- 若需异步重试或指数退避，建议引入 time.Sleep 和更完善的重试库（如 github.com/cenkalti/backoff/v4）。
综上，Go 中的重试不应依赖 panic 恢复流程，而应以 error 为中心设计。将 panic 视为开发阶段的调试信号（如断言失败），生产逻辑中的可恢复故障请统一使用 error 处理——这既是 Go 的哲学，也是构建高可靠服务的基石。
