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。
立即学习“go语言免费学习笔记（深入）”；
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
区分它们决定了要不要重试、要不要告警、前端要不要提示“请稍后重试”。
- 用
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 的错误日志，就像没有经纬度的报警——你知道炸了，但不知道在哪炸的。
