如何在Golang中设计可维护的错误体系_Golang长期错误治理思路_技术教程

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 全部原样吐给客户端。

定义错误分类映射表：比如 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),
	})
}