Golang开发Web应用如何处理错误与异常

Go Web中panic不应忽略也不应滥用recover：业务错误应返回结构化AppError，仅意外崩溃才panic并由顶层中间件统一recover；需区分transient/fatal数据库错误，结合trace ID实现错误可追溯。

Go Web 中 panic 不该被忽略，但也不该用 recover 拦住所有

Go 没有传统意义的“异常”，panic 是程序级崩溃信号，不是业务错误。在 HTTP handler 里直接 panic 会导致整个 goroutine 终止，若没捕获，会返回 500 并打印堆栈到日志——这在生产环境既不安全也不可控。

真正该做的是：把可预期的业务错误（比如参数校验失败、数据库记录不存在）转为 error 值显式返回；只对真正意外的情况（如空指针解引用、未初始化的 map 写入）让

panic 发生，并在顶层 middleware 中统一 recover，记录日志并返回 500。

• 不要在每个 handler 里写 defer func() { if r := recover(); r != nil { ... } }() ——重复且易漏
• 推荐在路由层加一层 wrapper，例如 http.HandlerFunc 包装器，统一 recover + 日志 + 状态码设置
• recover 只对当前 goroutine 有效，HTTP server 启动的每个请求都是独立 goroutine，所以它能生效

HTTP handler 返回 error 的标准姿势：用自定义 error 类型 + status code

Go 标准库的 http.Error 只能返回字符串和状态码，没法携带结构化信息（如错误码、trace ID、重试建议）。实际项目中应定义自己的错误类型，实现 error 接口，并附带 HTTP 状态码字段。

type AppError struct {
    Code    int
    Message string
    Cause   error
}

func (e *AppError) Error() string {
    if e.Cause != nil {
        return fmt.Sprintf("%s: %v", e.Message, e.Cause)
    }
    return e.Message
}

func (e *AppError) StatusCode() int {
    return e.Code
}

• handler 中遇到业务错误时，直接 return &AppError{Code: http.StatusBadRequest, Message: "invalid user ID"}
• 中间件统一检查返回值是否为 *AppError，调用 StatusCode() 设置响应头，再写入 JSON 错误体
• 避免把底层错误（如 sql.ErrNoRows）直接暴露给前端；应转换为语义清晰的上层错误

数据库操作出错后，如何区分 transient error 和 fatal error

像 PostgreSQL 的 connection refused、MySQL 的 Lock wait timeout 或网络抖动导致的 i/o timeout，属于可能自动恢复的 transient error；而 invalid SQL syntax 或约束冲突（如唯一键重复插入）是确定性的 fatal error。

区分它们决定了要不要重试、要不要告警、前端要不要提示“请稍后重试”。

• 用 errors.Is(err, sql.ErrNoRows) 判断常见确定性错误
• 对 net.OpError、driver.ErrBadConn、PostgreSQL 的 pgconn.PgError（SQLSTATE = '08006'）等做类型/值匹配，识别 transient 场景
• 不要依赖错误字符串匹配（如 strings.Contains(err.Error(), "timeout")），不稳定且易破
• ORM 如 GORM 提供了 errors.IsRecordNotFound()，优先用这类封装

日志 + trace ID 贯穿请求生命周期，错误才能被定位

单靠 log.Printf 打印错误，在并发请求下根本分不清哪条日志属于哪个用户、哪个请求。必须让每个请求携带唯一 trace ID，并在所有日志、错误包装、下游调用中透传。

最轻量的做法是在 middleware 中从 header（如 X-Request-ID）读取或生成 ID，存入 context.Context，后续所有 handler、service、repo 层都通过 ctx.Value() 或更推荐的 context.WithValue 派生上下文来获取。

• 错误发生时，把 trace ID 加进 AppError.Cause 或额外字段，而不是拼进 Message
• 日志库（如 zerolog 或 zap）支持 ctx 注入字段，比手动拼接更可靠
• 如果用了 OpenTelemetry，直接用 span.RecordError(err)，trace ID 自动关联

没有 trace ID 的错误日志，就像没有经纬度的报警——你知道炸了，但不知道在哪炸的。