Go 错误处理强调显式返回 error 值、统一错误分类与传播路径；优先用 fmt.Errorf("%w") 包装以保留错误链，定义可判断的自定义错误类型，HTTP handler 层负责安全映射而非暴露敏感信息。
Go 的错误处理不是靠 try/catch，而是显式返回 error 值并由调用方决定如何响应——这意味着“清晰的流程”不在于语法糖，而在于错误的分类、传播路径和上下文携带是否一致。
什么时候该用 errors.New，什么时候该用 fmt.Errorf？
直接用 errors.New 只适合无上下文、静态的底层错误（比如 errors.New("invalid state")）。一旦涉及变量、调用栈信息或需要区分错误类型，必须用 fmt.Errorf 配合 %w 包装。
-
fmt.Errorf("failed to open file: %w", err)—— 保留原始错误链，支持errors.Is/errors.As - 避免
fmt.Errorf("failed to open file: %s", err.Error())—— 这会切断错误链，丢失类型信息和原始堆栈 - 如果只是加日志而不打算恢复逻辑，优先用
log.Printf单独记录，而非把日志塞进错误消息里
如何让自定义错误可判断、可提取、不污染业务逻辑？
不要靠字符串匹配（如 strings.Contains(err.Error(), "timeout")），而应定义带方法的错误类型，并实现 Unwrap() 和/或 Is() 方法。
type TimeoutError struct {
Op string
Err error
}
func (e *TimeoutError) Error() string { return e.Op + ": timeout" }
func (e *TimeoutError) Unwrap() error { return e.Err }
func (e *TimeoutError) Is(target error) bool {
_, ok := target.(*TimeoutError)
return ok
}
- 调用方用
errors.Is(err, &TimeoutError{})判断，而非字符串比较 - 用
errors.As(err, &target)提取原始错误结构，用于重试、降级等分支逻辑 - 避免在每个函数里都定义新错误类型；按模块或错误域（如 network、storage）集中定义
HTTP handler 中的错误怎么一层层透出又不暴露敏感信息？
handler 层是错误“翻译层”，不是错误源头。它应该把底层错误映射为 HTTP 状态码和安全的响应体，同时保留原始错误供日志或监控使用。
立即学习“go语言免费学习笔记（深入）”；
- 不要在 handler 里写
if err != nil { http.Error(w, err.Error(), 500) }—— 可能泄露路径、SQL、token 等 - 推荐模式：
if errors.Is(err, sql.ErrNoRows) { writeJSON(w, 404, map[string]string{"error": "not found"}) } - 所有未预期错误统一 fallback 到 500，但通过中间件记录完整
err（含errors.Unwrap后的根因）到日志系统 - 用
http.StripPrefix或中间件统一处理 panic，避免 500 页面显示 runtime stack
真正难的不是写出能跑的错误处理，而是让团队成员在新增一个数据库查询函数时，本能地用 %w 包装、用 errors.Is 判断、不在 handler 拼接原始错误信息——这需要从第一个 go.mod 初始化就约定好错误策略，而不是等线上出现 500 错误码却查不到 root cause 时再补。
