不会丢原始错误类型，errors.Wrap 和 fmt.Errorf("%w", err) 均支持 errors.Is/As 穿透，但混用非 %w 包装会破坏类型判断；推荐统一用 %w 并避免 pkg/errors。
Go 中用 errors.Wrap 会丢掉原始错误类型吗？
不会丢，但默认行为不保留底层类型断言能力——关键在是否用 errors.WithStack 或 fmt.Errorf("%w", err)。原生 errors.Wrap(err, msg)（来自 github.com/pkg/errors）把原始错误包进新结构体，errors.Is 和 errors.As 仍能穿透多层找到原始错误，前提是没混用标准库 fmt.Errorf 错误构造方式。
常见错误现象：
err := errors.Wrap(io.EOF, "read header failed")
if errors.Is(err, io.EOF) { /* 这里能命中 */ }但换成err := fmt.Errorf("read header failed: %w", io.EOF)
if errors.As(err, &e) { /* e 是 *os.PathError？可能失败，因为 io.EOF 不是 *os.PathError */ }此时 errors.As 要求目标类型与原始错误完全匹配或可转换，而 fmt.Errorf 的包装不改变底层错误实例。
- 推荐统一用
fmt.Errorf("%w", err)（Go 1.13+），它支持%w动词且兼容标准库错误检查函数 - 避免混用
pkg/errors和标准库错误包装，尤其在跨模块传递时，容易导致As失败 - 若需堆栈，用
github.com/go-errors/errors或自己封装带StackTrace()方法的错误类型，而非依赖pkg/errors（已归档）
如何让日志和监控看到完整错误链而不破坏类型判断？
核心矛盾：日志要可读上下文，监控要精确分类；但加太多描述文字会污染 error.Error() 输出，影响 strings.Contains(err.Error(), "timeout") 这类弱匹配逻辑。
实操建议：
type ContextError struct {
Err error
Reason string
Code string // 如 "ERR_DB_CONN_TIMEOUT"
}
<p>func (e *ContextError) Error() string {
return fmt.Sprintf("[%s] %s: %v", e.Code, e.Reason, e.Err)
}</p><p>func (e <em>ContextError) Unwrap() error { return e.Err }
func (e </em>ContextError) Is(target error) bool {
return errors.Is(e.Err, target)
}这样既保留原始错误的可判断性，又让 log.Printf("failed: %v", err) 输出带上下文的字符串。
- 不要重写
Unwrap()返回拼接后的字符串错误，否则errors.Is穿透失效 - 监控报警规则应基于
Code字段或自定义方法（如e.Code()），而非解析Error()字符串 - 日志中间件中调用
fmt.Sprintf("%+v", err)可打印完整链和堆栈（需错误类型实现fmt.Formatter）
HTTP handler 中怎么透传错误上下文又不暴露敏感信息？
典型场景：数据库查询失败 → 包装为业务错误 → 返回给前端时需隐藏 DB 地址、SQL、行号等，但后端日志要保留。
做法是分层构造错误：
// 内部处理层（含敏感上下文）
err := fmt.Errorf("db query failed for user %d: %w", userID, pgErr)
<p>// 转换为对外错误（剥离敏感字段）
publicErr := &PublicError{
Message: "service unavailable",
Code: "INTERNAL_ERROR",
}
log.Error("internal failure", "err", err, "user_id", userID) // 原始 err 记入日志</p><p>http.Error(w, publicErr.Error(), http.StatusInternalServerError)
- 永远不在
http.Error或 JSON 响应体中直接输出err.Error() - 用中间结构体（如
PublicError）控制响应内容，字段显式声明，不依赖错误字符串解析 - 如果用 Gin/Echo，注册全局错误中间件，在
c.Error(err)后统一做脱敏转换，避免每个 handler 重复写
为什么 errors.Join 在 Go 1.20+ 里不能替代链式包装？
errors.Join 是并列关系，不是嵌套关系——它把多个错误“合并”成一个新错误，但所有子错误处于同一层级，errors.Is 会同时匹配任一成员，无法表达“A 导致 B 导致 C”的因果链。
例如：
err := errors.Join(
fmt.Errorf("failed to open file: %w", os.ErrNotExist),
fmt.Errorf("failed to connect db: %w", context.DeadlineExceeded),
)
errors.Is(err, os.ErrNotExist) // true
errors.Is(err, context.DeadlineExceeded) // true
// 但你无法知道哪个错误是根因，也无法获取调用路径
-
Join适合聚合并发操作中的多个独立失败（如批量上传 3 个文件，2 个失败），不适合单路径错误传播 - 需要因果链时，必须用
%w单向嵌套，最多一层Wrap，避免嵌套过深导致堆栈难读 - 超过 3 层嵌套通常说明职责划分有问题，应考虑提前返回或重构错误分类逻辑
实际项目中最容易被忽略的是错误类型的「可测试性」：单元测试里 mock 一个返回 fmt.Errorf("xxx: %w", io.EOF) 的函数，再用 assert.ErrorIs(t, err, io.EOF) 验证，比字符串匹配更可靠；但一旦中间混入 errors.New("xxx") 或非 %w 格式化，整条链就断了。
