go要求error作为返回值最后一个，以支持errors.is/as、工具链检查及可读性；应使用%w包装错误链，仅在需扩展字段或方法时定义自定义错误类型。
Go 语言中函数不抛异常，错误必须显式返回并由调用方检查——这不是限制，而是强制你面对失败场景的设计选择。
为什么 error 类型必须作为返回值最后一个（或之一）？
这是 Go 的约定，也是 errors.Is、errors.As 和 defer+recover 模式能协同工作的基础。编译器不强制，但标准库、linter（如 errcheck）和团队协作都依赖这个位置惯例。
- 如果把
error放在中间或开头，if err != nil检查会破坏多值赋值的可读性，例如：val, err, ok := doSomething()让人困惑哪个是错误 - 标准库所有 I/O、JSON、HTTP 函数（如
json.Unmarshal、os.Open）都遵循(T, error)形式，保持一致性才能降低认知负担 - 工具链（如
go vet）默认只检查最后一个返回值是否为error并未被检查，放错位置等于绕过静态检查
如何正确包装底层错误而不丢失上下文？
直接返回 err 会让调用方无法区分“文件不存在”和“解密失败”，用 fmt.Errorf 带 %w 动词才能保留原始错误链。
// ✅ 正确：保留错误因果链
func ReadConfig(path string) (string, error) {
data, err := os.ReadFile(path)
if err != nil {
return "", fmt.Errorf("failed to read config file %q: %w", path, err)
}
return string(data), nil
}
// ❌ 错误：丢失原始 error 类型和堆栈（除非用 %+v 打印）
return "", fmt.Errorf("read failed: %s", err)
- 只有带
%w的fmt.Errorf才支持errors.Is和errors.As向下匹配，比如判断是不是os.ErrNotExist - 避免多次包装同一错误（如两层都用
%w），会导致errors.Unwrap需要调用多次，增加判断复杂度 - 不要在包装时拼接空格或标点到
%w前面，否则errors.Is可能失效（它只看错误值，不看字符串）
什么时候该用自定义错误类型而不是 fmt.Errorf？
当你需要携带额外字段（如状态码、重试次数）、实现特定方法（如 Timeout()）、或参与策略判断（如熔断、降级）时，才定义结构体错误。
立即学习“go语言免费学习笔记（深入）”；
type ValidationError struct {
Field string
Code int
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on %s (code %d)", e.Field, e.Code)
}
func (e *ValidationError) Timeout() bool { return false }
- HTTP handler 中返回不同状态码时，自定义错误能让中间件统一转换：
if e, ok := err.(*ValidationError); ok { http.Error(w, e.Error(), e.Code) } - 普通业务逻辑（如“用户未登录”“余额不足”）用
fmt.Errorf+%w足够，过度设计错误类型反而增加维护成本 - 注意：自定义错误类型要导出字段或提供访问方法，否则外部包无法安全提取信息；也不要让
Error()方法 panic
最常被忽略的一点：错误不是日志。别在 fmt.Errorf 里写 “log: user x failed”，那是 log.Error 的事；也别因为怕漏检就全用 _= 忽略错误，Go 的错误返回机制只有在每处都决定“怎么处理”时才真正起作用。
