Go 1.13+ 中 errors.Wrap 不兼容标准错误链，因其 Unwrap 返回私有结构体，导致 errors.Is/As 失效；应改用 fmt.Errorf("%w", err) 或自定义错误类型实现 Unwrap/Is/As。
为什么 errors.Wrap 不能直接用在 Go 1.13+ 的标准错误链里
Go 1.13 引入了 errors.Is 和 errors.As，但它们依赖底层错误是否实现了 Unwrap() 方法。而 github.com/pkg/errors.Wrap 返回的错误类型虽然有 Unwrap()，但它返回的是一个私有结构体，和标准库 fmt.Errorf 的行为不完全兼容——尤其当你混用 pkg/errors 和 fmt.Errorf("%w", err) 时，errors.Is 可能失效。
- 如果你项目已升级到 Go 1.13+，优先用标准库的
fmt.Errorf("%w", err)包装，不是errors.Wrap -
pkg/errors的Wrap仍可工作，但无法被errors.As正确识别为“包装错误”，除非你手动实现As方法 - 老项目迁移时，搜索所有
errors.Wrap调用，替换为fmt.Errorf("xxx: %w", err)更安全
如何让自定义错误支持 Is 和 As 并保留上下文字段
纯包装（%w）只能传递错误链，但很多场景你需要附带结构化信息：如 HTTP 状态码、重试次数、请求 ID。这时不能只靠 fmt.Errorf，得自己实现错误类型。
- 定义结构体时嵌入
error字段，并实现Unwrap()返回它 - 实现
Is(target error) bool时，先检查自身是否匹配，再调用errors.Is(wrapped, target) - 实现
As(target interface{}) bool时，若目标是指向你自定义类型的指针，就做类型断言赋值；否则继续委托给包裹的错误 - 不要在
Error()方法里拼接Unwrap().Error()——这会破坏错误链的扁平性，fmt.Errorf已帮你做了
type MyAPIError struct {
Code int
ReqID string
Err error
}
func (e *MyAPIError) Error() string { return fmt.Sprintf("API failed (code=%d, req=%s)", e.Code, e.ReqID) }
func (e *MyAPIError) Unwrap() error { return e.Err }
func (e *MyAPIError) Is(target error) bool {
if t, ok := target.(*MyAPIError); ok {
return e.Code == t.Code && e.ReqID == t.ReqID
}
return errors.Is(e.Err, target)
}
func (e *MyAPIError) As(target interface{}) bool {
if t, ok := target.(*MyAPIError); ok {
*t = *e
return true
}
return errors.As(e.Err, target)
}
在 HTTP handler 中包装错误时，为什么不能直接 return fmt.Errorf("failed to parse: %w", err)
HTTP handler 通常需要返回特定状态码和 JSON 错误体，但 fmt.Errorf 包装后的错误本身不含状态码语义。如果上层统一用 http.Error 处理，会导致所有错误都变成 500，掩盖了本应是 400 的参数错误。
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 不要把原始错误无差别包装后向上抛，尤其跨层（如 handler → service → dao）时
- 推荐做法：handler 层接收 service 返回的错误，用
errors.As检查是否为预定义业务错误（如*ValidationError），再映射为对应 HTTP 状态码 - service 层只负责包装底层错误（如 DB 或网络错误），并添加领域上下文（如 “failed to save user order”），不决定 HTTP 状态
- 避免在 dao 层用
fmt.Errorf("db insert failed: %w", err)—— 这会让 handler 无法区分是约束冲突（409）还是连接超时（503）
日志中打印错误时，%v 和 %+v 的实际差异在哪
%+v 是 github.com/pkg/errors 提供的格式化动词，能显示堆栈；而标准库 fmt 的 %+v 对普通错误没特殊处理。Go 1.17+ 的 fmt.Errorf 支持 %w，但不自带堆栈——堆栈必须由最外层错误主动捕获。
立即学习“go语言免费学习笔记（深入）”；
- 如果要用堆栈，请在最外层错误创建点（比如 handler 入口）用
fmt.Errorf("handler failed: %w", err)并配合debug.PrintStack()或使用github.com/go-errors/errors这类带自动堆栈的包 - 日常调试建议：用
fmt.Printf("err: %+v\n", err)配合pkg/errors；生产环境日志则用slog.With("err", err).Error("something failed")，由日志库决定是否展开 - 注意：
%+v在标准库中对自定义错误类型无效，除非你显式实现fmt.Formatter接口
