Go中统一错误日志的核心是错误上下文传递、集中处理与标准化输出：底层返回原始错误，上层用%w包装语义化上下文，自定义AppError嵌入traceID，仅在HTTP handler等边界层结构化日志。
Go 中实现多层函数调用的统一错误日志，核心在于错误传递时保留上下文 + 集中处理 + 标准化输出。不靠 panic/recover 全局兜底，而是在 error 生成、传播、捕获三个环节做设计，让每一层都“知情”但不“越权”，最终由顶层或中间特定 handler 统一日志落盘。
用 fmt.Errorf 或 errors.Wrap 带上下文包装错误
底层函数只返回原始错误（如 io.EOF、sql.ErrNoRows），不加日志；上层调用时用 fmt.Errorf("read config: %w", err) 或 errors.Wrap(err, "validate user input") 添加语义化上下文。这样 error 链完整，又不重复打日志。
- 推荐用
%w（Go 1.13+）而非%s，保持 error 可判定性（errors.Is/As仍有效） - 避免在每层都
log.Printf("failed at X: %v", err)—— 日志会爆炸且无法区分层级责任
定义统一 Error 类型并嵌入 traceID / requestID
自定义一个可扩展的 error 结构，例如：
type AppError struct {
Code int `json:"code"`
Message string `json:"message"`
TraceID string `json:"trace_id,omitempty"`
Cause error `json:"-"`
Time time.Time `json:"time"`
}
func (e *AppError) Error() string { return e.Message }
func (e *AppError) Unwrap() error { return e.Cause }
在 HTTP middleware 或 RPC 入口处生成 traceID，通过 context 透传到各层；遇到错误时，用 &AppError{TraceID: ctx.Value("trace_id").(string), ...} 构造，确保一次请求的所有错误日志可关联。
顶层统一拦截 & 日志输出（非 panic 场景）
HTTP handler、CLI 命令入口、定时任务主函数等“边界层”，是唯一该打日志的地方：
- 检查返回 error 是否为
*AppError，若是则结构化打印（含 code、traceID、Message、stack） - 若只是普通 error，用
errors.PrintStack()或第三方库（如 github.com/pkg/errors）提取栈帧，补全调用链 - 日志格式建议：
[ERROR] [trace:abc123] [user:u456] validate user input: invalid email format: "foo@"
可选：用中间件/装饰器自动包装调用栈
对关键业务函数，可用函数式装饰器自动注入位置信息：
func WithTrace(fn func() error) func() error {
return func() error {
err := fn()
if err != nil {
// 获取当前函数名和行号（用 runtime.Caller）
_, file, line, _ := runtime.Caller(1)
return fmt.Errorf("%s:%d: %w", filepath.Base(file), line, err)
}
return nil
}
}
适用于工具函数、DAO 方法等不易手动 wrap 的场景，但不宜滥用——易掩盖真实语义，优先靠人工 wrap + review。
基本上就这些。统一错误日志不是靠一个库搞定，而是靠约定（谁该 wrap、谁该 log）、结构（带 traceID 的 error 类型）、边界（只在入口打日志）三者配合。不复杂但容易忽略细节。
