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 状态码和安全的响应体，同时保留原始错误供日志或监控使用。
