Go 没有 error 全局捕获机制，因为 error 是显式返回值而非异常，不触发栈展开；全局错误处理依赖架构约定而非语言特性，核心是标准化错误构造与传播路径。
Go 语言没有类似 Python 的全局异常捕获机制，panic 可以用 recover 拦截，但普通错误（error 类型）根本不会“抛出”，也就谈不上“全局捕获”。所谓“全局错误处理”，本质是约定 + 架构设计，不是语言特性。
为什么 Go 没有 error 全局捕获
Go 的 error 是一个接口类型，是函数显式返回的值，不是运行时抛出的异常。它不触发栈展开，也不中断控制流 —— 调用方必须主动检查、处理或传递。这决定了它无法被“兜底”拦截。
-
if err != nil是强制的协作契约，不是可忽略的警告 - 任何试图在 HTTP handler 外层统一 check
error的 wrapper，都只能捕获自己封装的那一层返回的 error，对内部未返回、未传递、被忽略的 error 完全无效 - 滥用
panic模拟异常再 recover，会混淆真正意外（如空指针解引用）和业务错误（如用户输入格式错），破坏可观测性和调试路径
HTTP 服务中常见的“伪全局错误处理”陷阱
很多项目写一个中间件，用 defer + recover 捕获 panic，并认为这就是“错误统一处理”。但它对以下情况完全无能为力：
- handler 里写了
if err != nil { log.Println(err); return }却没返回 HTTP 错误码 —— 响应体为空，状态码仍是 200 - goroutine 中发生的错误（如异步写 Kafka 失败）根本不在 HTTP 请求生命周期内，中间件看不见
- 数据库查询返回
sql.ErrNoRows，被当成业务逻辑正常分支处理了，但调用方其实期望返回 404
真正有用的不是“捕获”，而是**标准化错误构造与传播路径**：
type AppError struct {
Code int
Message string
Err error // 底层原始 error，用于日志和 debug
}
func (e *AppError) Error() string { return e.Message }
// 在 handler 中统一返回
func jsonError(w http.ResponseWriter, err error) {
var appErr *AppError
if errors.As(err, &appErr) {
http.Error(w, appErr.Message, appErr.Code)
return
}
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
panic/recover 只该用于真正的程序异常
recover 不是错误处理工具，是最后防线。只应在明确知道某段代码可能 panic（如 json.Unmarshal 解析不可信输入、反射调用未知方法），且你有能力安全恢复时使用。
- 不要在顶层 goroutine（如
http.ListenAndServe）外直接 defer recover —— 它会吞掉本该让进程崩溃的致命错误 - recover 后必须记录完整堆栈：
log.Printf("panic recovered: %v\n%v", r, debug.Stack()) - recover 之后不能继续执行原逻辑，必须返回错误响应或关闭连接 —— 已 panic 的 goroutine 状态不可信
示例（仅限可信子流程）：
func safeUnmarshal(data []byte, v interface{}) error {
defer func() {
if r := recover(); r != nil {
log.Printf("json.Unmarshal panic: %v", r)
}
}()
return json.Unmarshal(data, v)
}
真正有效的“全局性”控制点
不是靠 runtime 拦截，而是靠工程约束：
- 所有外部调用（DB、RPC、HTTP Client）封装成返回
error的函数，并禁止裸用底层库（如直接调db.QueryRow） - 定义错误码常量集（如
ErrUserNotFound = &AppError{404, "user not found", nil}），禁止字符串拼接错误信息 - 日志打点强制包含
error字段：log.WithError(err).Info("failed to send email") - CI 阶段用
errcheck工具扫描未处理的 error 返回值
这些加起来，比幻想一个“全局 catch error”要可靠得多。Go 的错误处理不是缺陷，是把责任交还给开发者 —— 而责任一旦被推脱，问题只会更难定位。
