go语言错误处理应以error值为核心，panic/recover仅用于不可恢复的程序崩溃场景；业务错误须用error返回、包装、分类和结构化日志上报，而非滥用recover模拟try/catch。
Go 语言没有传统意义上的“异常捕获”机制，panic/recover 不是 try/catch，强行套用语言学习惯会写出脆弱、难以维护的错误处理逻辑。
为什么不能把 recover 当成 catch 用
很多从 Java/Python 转来的开发者会下意识在 main 函数或 HTTP handler 顶层加 defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }()，以为这就“兜住异常”了。但问题在于：
-
panic是运行时崩溃信号，不是业务错误；它本该用于不可恢复的程序状态（如 nil 指针解引用、切片越界），而非“用户密码错误”这类可预期失败 -
recover只在 defer 中有效，且仅对同一 goroutine 生效；HTTP handler 启动的新 goroutine panic 后，顶层 recover 根本抓不到 - 一旦用了
recover，堆栈已中断，原始调用链丢失，你拿到的只是个 interface{}，无法还原错误类型、字段或上下文
真正健壮的错误处理：用 error 值 + 包装 + 判断
Go 的哲学是“错误是值”，所有可预期失败都应返回 error 类型。关键不是“捕获”，而是“传递+分类+响应”：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 函数签名显式返回
error，调用方必须检查（工具如errcheck可强制） - 用
fmt.Errorf("failed to %s: %w", op, err)包装底层错误（%w触发errors.Is/errors.As支持） - 业务层用
errors.Is(err, ErrNotFound)做语义判断，而不是strings.Contains(err.Error(), "not found") - 日志上报时，用
fmt.Sprintf("%+v", err)打印带堆栈的错误（需基于github.com/pkg/errors或 Go 1.13+ 的fmt.Errorf包装）
panic 只该出现在这三种情况
滥用 panic 是错误上报混乱的根源。它只适合以下明确场景：
- 初始化失败且程序无法继续：比如
flag.Parse()后配置校验不通过，直接panic("missing required flag -db-url") - 断言失败即代表代码逻辑错误：比如
v, ok := i.(MyInterface); if !ok { panic("unexpected type") }—— 这里 panic 表示你写错了类型约束，不是运行时异常 - 第三方库内部 panic 且你无法修改源码：此时才需要在调用点加
defer/recover，并立即转为error返回（例如某些 Cgo 封装库）
错误上报要带上下文，别只扔一个 err.Error()
生产环境最常见问题是：日志里只有 "connection refused"，却不知道是连 Redis 还是 PostgreSQL，发生在哪个 handler，用了什么参数。解决方式很直接：
- 用结构化日志（如
zap或zerolog），在 error 上报时附加字段：logger.Error().Err(err).Str("service", "auth").Str("user_id", userID).Int64("req_id", reqID).Send() - 避免在中间层吞掉错误：不要写
if err != nil { return nil }，至少记录logger.Warn().Err(err).Msg("fallback triggered") - HTTP handler 中，对业务错误统一返回 4xx（如
errors.Is(err, ErrInvalidToken)→ 401），对系统错误返回 5xx 并触发告警，不要让 panic 泄露到响应体
最难的不是写 recover，而是克制住想用它的冲动——绝大多数所谓“异常”，其实只是没设计好 error 类型和分层策略。上线后查不到错误源头，往往是因为 panic 太早打断了流程，或者 error 没包装、没分类、没带上文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
