errors.Join 不保留嵌套错误调用栈，仅保留最外层位置；日常链式包装应使用 fmt.Errorf("xxx: %w", err)，聚合多错误时才用 errors.Join。
用 errors.Join 和 fmt.Errorf 包装错误时，为什么堆栈总在最外层断掉
Go 1.20+ 的 errors.Join 不保留嵌套错误的原始调用栈，只保留最外层 fmt.Errorf 的位置。这会让日志里看不到真实出错点，排查时反复跳转。
- 只对需要聚合多个错误（如并发任务批量失败）的场景用
errors.Join；日常链式包装一律用fmt.Errorf("xxx: %w", err) - 若必须用
errors.Join，后续日志打印前先调用errors.Unwrap手动展开，或改用第三方库如github.com/pkg/errors（注意它已归档，仅作兼容参考） - 验证方法：在包装后打印
fmt.Printf("%+v", err)—— 带+v才能看到完整栈帧
自定义错误类型该不该实现 Unwrap 方法
只有当你希望上层能用 errors.Is 或 errors.As 精确识别这个错误，并且它确实包裹了另一个底层错误时，才实现 Unwrap。否则就是干扰判断。
- 典型场景：数据库操作封装错误
type DBError struct { Err error; Query string }，此时应返回return e.Err - 反例：业务逻辑错误如
ErrInsufficientBalance是纯标识型错误，不应实现Unwrap，否则errors.Is(err, ErrInsufficientBalance)可能因误包而误判 - 如果错误同时含状态码和原始错误，建议拆成两个字段：
Code int+Wrapped error，Unwrap只返回后者
errors.Is 匹配失败，但 errors.As 却能取到值
这是因为 errors.Is 只比对错误值是否相等（或实现了 Is 方法），而 errors.As 是按类型断言并解包。常见于你用 fmt.Errorf("%w", err) 包装后，原始错误被“压扁”了。
- 确保所有自定义错误类型都实现
Is(target error) bool方法，尤其当它可能被多次包装时 - 避免在中间层用
fmt.Errorf("failed: %v", err)（丢弃%w），这会切断错误链 - 测试技巧：写单元测试时，用
errors.Is(err, yourErr)和errors.As(err, &target)双重校验，不只依赖一个
HTTP handler 中统一错误响应，怎么避免把内部错误细节暴露给前端
直接 json.NewEncoder(w).Encode(map[string]string{"error": err.Error()}) 是危险的——数据库连接失败、SQL 注入尝试、空指针 panic 全部原样吐给客户端。
立即学习“go语言免费学习笔记（深入）”；
- 定义错误分类映射表：比如
map[error]HTTPStatus，将*sql.ErrNoRows映射为404，validation.ErrInvalidInput映射为400 - 内部错误（如
io.EOF、context.DeadlineExceeded）统一转为500，但日志里记录完整原始错误（含栈） - 对外响应体只包含
code（业务码）、message（用户友好文案）、request_id（用于日志追踪），绝不含err.Error()
func writeErrorResponse(w http.ResponseWriter, err error) {
status := http.StatusInternalServerError
msg := "Internal server error"
if errors.Is(err, sql.ErrNoRows) {
status = http.StatusNotFound
msg = "Resource not found"
}
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(status)
json.NewEncoder(w).Encode(map[string]interface{}{
"code": status,
"message": msg,
"request_id": getReqID(r),
})
}
长期维护的关键不是建多复杂的错误树，而是守住两条线：错误链不被意外截断，错误语义不被随意透传。每次加一层包装前，先问自己：这一层是真要参与决策（Is/As），还是只为日志可读？答案不同，写法就完全不同。
