应使用 errors.Is 和 errors.As 判断错误类型，因其支持多层包装；自定义错误需实现 Unwrap 方法；日志应保留错误链，HTTP 错误需按语义映射状态码。
用 errors.Is 和 errors.As 判断错误类型，别用 == 或 strings.Contains
Go 的错误是值，不是类型，直接比较 err == io.EOF 看似可行，但一旦中间层包装了错误（比如用 fmt.Errorf("read failed: %w", err)），原始错误就被包进去了，== 就失效。同理，靠字符串匹配既脆弱又慢，还容易漏掉大小写或空格变化。
正确做法是用标准库提供的语义化判断：
-
errors.Is(err, io.EOF)检查是否「是」某个底层错误（支持多层包装） -
errors.As(err, &target)尝试把错误解包成具体类型（比如自定义错误结构体），用于提取上下文字段
示例：
if errors.Is(err, os.ErrNotExist) {
log.Printf("config file missing, using defaults")
return defaultConfig, nil
}
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("failed on path: %s, op: %s", pathErr.Path, pathErr.Op)
}
自定义错误要实现 Unwrap 方法，否则 errors.Is/As 失效
如果你写了带额外字段的错误类型（比如含 Code、TraceID 的错误），又希望它能被 errors.Is 或 errors.As 正确识别，就必须显式实现 Unwrap() error 方法，返回被包装的下一层错误。
常见错误写法是只嵌入 error 字段却不实现 Unwrap，导致外层错误无法穿透：
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确：
type AppError struct { Code int Message string Err error // 底层错误 } func (e *AppError) Error() string { return e.Message } func (e *AppError) Unwrap() error { return e.Err } - ❌ 错误：漏掉
Unwrap，errors.Is(err, io.EOF)对*AppError总是返回false
不要在日志里只打 err.Error()，丢失错误链和类型信息
调用 log.Printf("failed: %v", err) 时，如果 err 是包装过的（比如 fmt.Errorf("handle request: %w", io.EOF)），默认 %v 只输出最外层消息，底层错误和调用链全丢了。调试时根本看不出是哪一层出的问题。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
建议按场景选择格式化方式：
- 开发/调试环境：用
%+v（需引入github.com/pkg/errors或 Go 1.19+ 的fmt.Errorf包装 +%w）—— 输出完整堆栈和错误链 - 生产环境：用
%v+ 显式记录关键字段（如errCode、httpStatus），避免敏感信息泄露 - 结构化日志（如
zap）：用zap.Error(err)，它会自动调用errors.Unwrap并保留链式结构
HTTP handler 中的错误响应要区分客户端错误和服务器错误
把所有错误都返回 500 Internal Server Error 是最常见也最危险的健壮性漏洞——它掩盖了本该由客户端修复的问题（比如参数缺失、权限不足），让前端无法做针对性处理，也让监控指标失真。
应该根据错误语义映射状态码：
-
errors.Is(err, ErrInvalidInput)→400 Bad Request -
errors.Is(err, ErrUnauthorized)→401 Unauthorized -
errors.Is(err, ErrNotFound)→404 Not Found - 其他未预期错误（含 panic 恢复）→
500，并记录完整错误链
注意：别在中间件里统一转 500，除非你明确知道每一类错误的语义边界；更安全的做法是在每个业务 handler 内完成分类，或者用错误类型实现接口（如 StatusCode() int）来驱动响应逻辑。
真正难的不是加 if err != nil，而是让每个 err 都携带可操作的语义，并在传播路径上不丢失这些信息。包装错误时少用 fmt.Errorf("%s", err)，多用 %w；暴露错误时少返回裸 error，多提供可识别的哨兵或类型；日志和监控里，永远假设你看到的只是错误冰山一角。
