Go无内置错误日志系统，需手动组合或借助库实现上下文、堆栈、时间、级别记录与落盘；标准log包需配合fmt.Errorf(%w)包装、log.SetFlags设置、os.OpenFile持久化；生产推荐zap结构化日志。
Go 本身没有内置的“错误日志系统”，error 类型只是值，不自动打日志；想记录错误上下文、堆栈、时间、级别并落盘，必须手动组合或借助库。
用 log 包 + fmt.Errorf 做基础错误包装与输出
标准库 log 可输出带时间戳的错误，但默认不包含调用栈，且 error 本身不会触发日志——你得显式调用 log.Printf 或 log.Println。
常见错误是直接 log.Println(err)，丢失了原始错误链和位置信息。正确做法是用 fmt.Errorf 带 %w 包装，并在关键入口处统一记录：
err := doSomething(); if err != nil { log.Printf("failed to doSomething: %v", fmt.Errorf("service: %w", err)) }- 避免多次包装：不要在每一层都
fmt.Errorf("xxx: %w", err)，否则堆栈被截断；只在边界（如 HTTP handler、goroutine 入口）做一次有意义的标注 -
log.SetFlags(log.LstdFlags | log.Lshortfile)必须提前设置，否则看不到文件行号
用 github.com/pkg/errors 或 errors（Go 1.13+）加堆栈追踪
Go 1.13 引入的 errors 包支持 errors.Is/errors.As，但原生仍不附带堆栈。要获取 panic 级别的调用链，得靠第三方库或手动捕获。
立即学习“go语言免费学习笔记（深入）”；
github.com/pkg/errors 是最轻量的选择（虽已归档，但稳定可用）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
err := pkgerrors.Wrap(err, "database query failed")会把当前调用点加入堆栈 -
pkgerrors.WithStack(err)可显式插入栈帧，适合在 defer 中捕获 - 注意：它和标准
errors不完全兼容，比如pkgerrors.Cause(err)才能拿到原始 error，不能直接用errors.Unwrap - 若坚持用标准库，可配合
runtime/debug.Stack()手动附加，但性能开销大，仅限调试阶段
将错误写入文件而非控制台：用 os.OpenFile 配合 log.SetOutput
log 包输出目标可动态切换，但默认是 os.Stderr。要持久化到磁盘，需自己管理文件句柄。
关键细节常被忽略：
- 用
os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)，别用os.Create（每次覆盖） - 必须在程序启动时设置
log.SetOutput(file)，且确保该*os.File在整个生命周期内有效 - 不要在每次写日志时
os.OpenFile再Close——频繁打开关闭文件会导致too many open files错误 - 若需按天轮转，得自己检查文件修改时间 + 重命名 + 新建，标准库不提供 logrotate 功能
生产环境推荐：用 zap 替代 log 处理结构化错误日志
log 包是文本导向，难过滤、难聚合。真实服务中，错误日志需含字段如 level=error、trace_id、service=auth、stack，这时 uber-go/zap 是事实标准。
实操要点：
- 初始化用
zap.NewProduction()（JSON 输出 + 自动时间/调用位置），开发期可用zap.NewDevelopment() - 记录错误时用
logger.Error("db insert failed", zap.Error(err), zap.String("user_id", uid))，zap.Error会自动展开堆栈（需搭配github.com/pkg/errors或errors.Join） - 避免用
logger.Fatal直接退出——它会调用os.Exit(1)，跳过 defer 和 cleanup，应改用logger.Error+ 显式return - zap 的
SugaredLogger支持类似printf的语法，但结构化能力弱于Logger，错误场景建议用原生Logger
真正难的不是“怎么记”，而是“记什么”和“什么时候停”。比如一个重试 3 次的 HTTP 请求，是每次失败都记一条 error，还是只记最终失败？堆栈该打多少层？日志文件要不要压缩？这些没标准答案，得根据可观测性需求和磁盘预算来权衡。
