Go 错误处理核心是构建可追溯的错误链并增强语义：用 %w 包装错误、定义结构化自定义错误类型、关键节点添加上下文、出口处脱敏降级，确保语义清晰、链路完整、边界可控。
Go 语言中向上层返回详细错误，核心在于保留原始错误上下文、添加语义化信息、支持错误链追溯。从 Go 1.13 开始，errors.Is 和 errors.As 配合 %w 动词，让错误链（error wrapping）成为标准实践；而语义增强则依赖结构化错误类型与清晰的错误消息设计。
用 %w 包装错误，构建可追溯的错误链
使用 fmt.Errorf("xxx: %w", err) 是构造错误链最直接的方式。它把底层错误“包裹”进新错误中，上层可用 errors.Unwrap 或 errors.Is/As 向下检查原始错误类型或值。
- 必须用
%w（不是%v或%s），否则丢失包装关系 - 每层只加一层上下文，避免过度包装导致堆栈模糊
- 示例：
return fmt.Errorf("failed to open config file: %w", os.Open(path))
定义自定义错误类型，承载业务语义
仅靠字符串包装不够——当需要区分“配置缺失”、“权限不足”、“格式错误”等不同失败原因时，应定义实现了 error 接口的结构体，并嵌入原始错误或实现 Unwrap() 方法。
- 字段可包含：错误码（如
ErrConfigNotFound）、HTTP 状态码、trace ID、时间戳等 - 重写
Error()方法，输出人类可读且机器可解析的信息 - 实现
Unwrap()返回底层错误，保持链式可查性
在关键节点添加上下文，但避免冗余日志
错误传递 ≠ 每一层都打日志。应在错误首次发生处或边界处（如 HTTP handler、CLI 命令入口）记录完整上下文；中间层专注包装，不重复打印。
立即学习“go语言免费学习笔记（深入）”；
- 推荐模式：handler 层捕获 error → 补充请求 ID / 用户 ID → 记录日志 → 返回给客户端
- 中间 service 层只需
return fmt.Errorf("validate user: %w", err) - 避免：
log.Printf("in validateUser: %v", err); return err—— 这会重复且丢失链
对外暴露错误时做降级与脱敏
面向用户（尤其是 API）返回的错误不能暴露内部路径、数据库名、敏感字段。需在出口处统一处理：
- 对已知业务错误（如
*ValidationError），映射为简洁友好的 message + code - 对未知 panic 或系统错误，返回泛化提示（如 "internal server error"），同时服务端保留完整错误链用于排查
- 可借助中间件或封装的
ErrorResponse(err)函数统一处理
基本上就这些。错误链不是越深越好，关键是每一层都回答清楚：“这里出了什么问题？为什么重要？谁该负责修复？” —— 语义清晰 + 链路完整 + 边界可控，才是 Golang 错误处理的落地要点。
