Go 错误处理核心在于可追溯的错误链：必须用%w包装以支持errors.Is/As，DB层只包装不判状态码，HTTP层映射业务错误码并隔离日志与用户提示，避免冗余包装。
Go 语言本身不支持异常（try/catch），错误必须显式传递和判断；真正的难点不在“怎么返回 error”，而在于「错误上下文是否可追溯」「调用链中哪一层该包装、哪一层该透传」「日志与用户提示如何分层隔离」。
什么时候该用 fmt.Errorf 包装错误，什么时候该用 errors.Wrap 或 fmt.Errorf(": %w")
Go 1.13 引入了错误链（error wrapping）机制，核心是 %w 动词。只要你想保留原始错误以便后续用 errors.Is 或 errors.As 判断，就必须用 %w；否则用 %s 就只是字符串拼接，原始错误丢失。
-
fmt.Errorf("failed to open config: %w", err)✅ 可用errors.Is(err, fs.ErrNotExist)检查底层原因 -
fmt.Errorf("failed to open config: %s", err)❌ 原始错误被转成字符串，无法类型断言或精确匹配 -
errors.Wrap(err, "loading config")是旧库（github.com/pkg/errors）写法，Go 1.13+ 推荐统一用%w
HTTP handler 中如何分层返回错误：底层 DB 错误不该直接暴露给前端
典型误区是把 sql.ErrNoRows 或 context.DeadlineExceeded 直接 return 给 HTTP 响应，既泄露实现细节，又难统一处理状态码。
- 定义业务错误码枚举（如
ErrUserNotFound,ErrInvalidInput），每个对应明确的 HTTP 状态码和用户友好的消息 - 在 handler 入口用中间件或 defer 捕获 error，用
errors.As匹配具体错误类型，再映射为响应结构体 - DB 层错误只做包装（
fmt.Errorf("query user by id: %w", err)），绝不在此层决定 HTTP 状态码 - 日志记录时用
errors.Unwrap或fmt %+v打印完整错误链，方便排查
errors.Is 和 errors.As 的实际使用边界在哪里
这两个函数不是万能的——它们只对用 %w 包装的错误有效，且只能向上遍历直接包装者，不能跨多层间接包装（除非每一层都用了 %w）。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is(err, io.EOF)✅ 能穿透fmt.Errorf("read body: %w", io.EOF) -
errors.As(err, &target)✅ 可以提取任意一层包装的自定义错误类型（如*ValidationError） - 如果中间某层用了
%s拼接，链就断了，Is/As查不到下游错误 - 不要在循环里反复调用
errors.Is做条件分支——先用errors.As提取一次，再 switch 类型更清晰
最常被忽略的一点：错误包装不是越多越好。每加一层 %w 都意味着额外的内存分配和栈信息捕获开销；高频路径（如 JSON 解析、简单校验）若无调试或分类需要，直接返回原始错误更轻量。分层的价值在于「可诊断性」，不是「看起来很规范」。
