错误应先返回再统一日志：底层函数只返回错误，业务入口层检查后用结构化日志记录并附加上下文，确保错误链完整、日志不重复、可观测性与错误处理分离。
错误发生时先记录日志还是先返回错误？
Go 中典型的错误处理模式是 if err != nil 后立刻处理。但「处理」具体指什么？很多团队默认先 log.Printf 或调用日志库，再 return err。这看似合理，实则埋下隐患：日志可能重复、上下文丢失、或掩盖真实错误流向。
核心原则是：**日志不是错误处理的终点，而是可观测性的补充；错误值必须原样向上传递，由真正能决策的地方决定是否重试、降级或告警。**
- 在底层函数（如数据库查询、HTTP 调用）中，只返回错误，不打日志——它不知道调用方是否重试、是否静默容忍
- 在业务入口层（如 HTTP handler、CLI 命令执行点），先检查错误，再统一记录结构化日志，此时可附加 trace ID、用户 ID、请求路径等上下文
- 若需调试底层失败原因，用
fmt.Errorf("read config: %w", err)包装并保留原始错误链，而非直接log.Fatal
用 log/slog 还是第三方日志库记录错误？
Go 1.21+ 内置的 slog 已足够支撑大多数工程场景，且与 errors.Unwrap 和 fmt.Errorf(...%w) 天然协同。盲目引入 zap 或 logrus 反而增加配置复杂度和错误链截断风险。
关键差异点：
-
slog.With("err", err)会自动调用err.Error()，但不会展开嵌套错误；如需完整错误链，显式传入slog.Any("error_chain", err) -
zap.Error(err)默认只记录Error()字符串，需手动调用zap.NamedError或封装辅助函数才能保留%w链 - 所有日志库在 defer 中记录错误时都容易漏掉 panic 恢复后的错误值，建议统一用
recover()+slog.Error捕获顶层 panic
HTTP handler 中错误日志和响应状态码怎么对齐？
常见错误是：http.Error(w, "internal error", http.StatusInternalServerError) 却没记录日志，或日志里写了 "user not found" 却返回了 500。这导致排查时无法从日志快速定位响应异常。
推荐做法：
- 定义错误类型（如实现
interface{ StatusCode() int }），让 handler 根据错误类型决定状态码，同时日志中输出status_code字段 - 避免在中间件里无差别记录所有
5xx错误——有些是预期的临时失败（如下游超时），应由业务逻辑判断是否值得告警 - 对
4xx错误（如参数校验失败）也记录日志，但级别设为Debug或Info，并标注is_client_error: true，便于后续过滤
func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
err := h.doSomething(r.Context())
if err != nil {
status := http.StatusInternalServerError
if appErr, ok := err.(interface{ StatusCode() int }); ok {
status = appErr.StatusCode()
}
slog.Error("request failed",
slog.String("path", r.URL.Path),
slog.Int("status_code", status),
slog.Any("error", err),
)
http.Error(w, http.StatusText(status), status)
return
}
}
defer 中 recover 并记录 panic，为什么还是看不到完整堆栈？
直接 slog.Error("panic recovered", slog.String("msg", string(debug.Stack()))) 看似能打印堆栈，但实际常被截断——因为 debug.Stack() 在 goroutine 退出前调用才可靠，而 defer 执行时机受调度影响。
更健壮的做法：
- 用
recover()捕获 panic 值后，立即调用runtime/debug.PrintStack()输出到 stderr（确保不被缓冲丢弃） - 若需写入结构化日志，改用
runtime.Caller获取 panic 发生位置，并结合errors.Is判断是否为已知 panic 类型（如context.DeadlineExceeded） - 禁止在 defer 中启动新 goroutine 记录日志——panic 时 goroutine 可能已处于不可靠状态
最易忽略的一点：全局 panic 恢复必须放在 main() 函数最外层，而不是某个 handler 内部。否则子 goroutine panic 仍会导致进程退出。
