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 serv
er 启动的每个请求都是独立 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 派生上下文来获取。