Go错误处理需在首次出错处用errors.WithStack加栈，后续用%w包装；HTTP请求注入trace ID到error中；用slog.Any("error", err)统一日志格式；对高频panic如"context canceled"做白名单过滤和限流。
Go 程序出错了，但日志里只看到 panic: runtime error 或一行模糊的 error: failed to write file，没调用栈、没请求 ID、没服务上下文——这意味着你根本没法快速定位是哪个 API、哪个用户、哪台实例、哪个中间件环节出了问题。
用 errors.WithStack + fmt.Printf("%+v") 快速补全调用栈
标准库 errors.New 和 fmt.Errorf 不带堆栈，一出错就丢失上下文。直接换用 github.com/pkg/errors（或 Go 1.13+ 的 errors.Join/%w 配合自定义包装）。
常见错误是只在最外层加一次堆栈，结果深层函数返回的 error 已被多次包装，%+v 输出重复栈帧。正确做法是：只在**错误首次产生处**（如数据库查询失败、文件打开失败）加堆栈，后续传递时用 %w 包装，不重复调用 errors.WithStack。
-
err := errors.WithStack(fmt.Errorf("read config failed: %w", os.ErrNotExist))✅ return errors.WithStack(err) // 在上层函数里再套一次 ❌- 打印时务必用
fmt.Printf("%+v", err)，仅%v不显示栈
给每个 HTTP 请求注入唯一 trace ID 并透传到 error 日志
没有 trace ID，你就无法把一条 error 日志和某次具体请求关联起来。别依赖中间件自动打日志——要让 error 本身携带上下文。
立即学习“go语言免费学习笔记（深入）”；
推荐在入口 middleware 中生成 X-Request-ID，存入 context.Context，所有下游 error 都通过 fmt.Errorf("db timeout: %w; req_id=%s", err, reqID) 显式拼接，或用结构体 error 封装：
type RequestError struct {
Err error
ReqID string
Path string
}
func (e *RequestError) Error() string { return fmt.Sprintf("[%s] %s: %v", e.ReqID, e.Path, e.Err) }
关键点：
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 不要用
log.Printf单独打 trace ID 日志，而要把 ID 写进 error 字符串或字段里 - 避免在 defer 中 recover 后丢弃原始 error，必须保留
cause并合并 trace ID - 如果用了 OpenTelemetry，优先用
span.SpanContext().TraceID().String()替代手动生成 ID
用 log/slog（Go 1.21+）统一 error 字段输出格式
老项目混用 log.Printf、zap.Error、slog.String("err", err.Error())，导致日志字段名不一致（error / err / errmsg），监控系统无法统一提取。
Go 1.21 起，用 slog 定义规范字段名：
- 固定用
slog.Any("error", err)输出 error 类型值（支持自动展开 stack） - 搭配
slog.Group("request", slog.String("id", reqID), slog.String("path", r.URL.Path))组织上下文 - 自定义
slog.Handler时，在Handle方法中检测Attr.Value.Kind() == slog.KindGroup && Attr.Key == "error"，对 error 值额外调用%+v提取栈
注意：slog.Any 对非 error 类型会 panic，务必确保传入的是 error 接口。
上报 error 到远程监控时过滤高频低价值 panic
不是所有 panic 都值得告警。比如 http: server closed、context canceled、net/http: request canceled 这类由客户端主动断连触发的 panic，每秒可能上千次，塞满 Sentry 或 Prometheus。
在 recover 阶段做轻量级过滤：
- 用
strings.Contains(err.Error(), "context canceled")拦截已知可忽略错误 - 对 panic 的
reflect.TypeOf(p).Name()做白名单（如只上报*url.Error、*os.PathError） - 加计数器限流：同一 error message 5 分钟内超过 10 次才上报，避免雪崩式告警
真正难处理的是那些不抛 error、也不 panic，却静默返回空结果或默认值的逻辑分支——这类问题不会出现在 error 监控里，得靠业务埋点和黄金指标（如成功率突降）反向发现。
