Go函数返回错误的标准写法是error必须作为最后一个返回值，类型为error接口，成功时返回nil；应使用errors.New或fmt.Errorf（%w包装）构造错误，禁止忽略或裸panic，自定义错误需实现Error()方法。
Go 函数返回错误的标准写法
Go 语言要求显式处理错误，函数返回错误必须作为最后一个（或倒数第二个，当有多个返回值时）error 类型值。这不是约定，是标准库和绝大多数 Go 项目强制遵循的规范。
常见错误是把 error 放在前面，或者用自定义结构体包装错误——这会破坏与 if err != nil 惯用法的兼容性，也让调用方无法直接用 errors.Is 或 errors.As 判断。
- 正确顺序：
func DoSomething() (string, error)或func ParseID(s string) (int, error) - 错误值必须是接口类型
error，不能是*MyError或MyError（除非它实现了error接口） - 成功时应返回
nil，而非errors.New("")或空字符串转成的错误
使用 errors.New 和 fmt.Errorf 区分场景
errors.New 适合固定、无上下文的简单错误；fmt.Errorf 用于需要拼接变量、嵌套错误或添加堆栈信息的场景。从 Go 1.13 起，fmt.Errorf("...: %w", err) 中的 %w 是关键——它让错误可被 errors.Unwrap 和 errors.Is 追溯。
容易踩的坑：用 %v 或 %s 替代 %w 包装底层错误，会导致链路断裂，errors.Is(err, io.EOF) 失效。
立即学习“go语言免费学习笔记（深入）”；
func ReadConfig(path string) ([]byte, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("failed to read config file %q: %w", path, err)
}
return data, nil
}
不要忽略 error，也不要裸 panic
Go 不允许未使用的变量，但编译器不会阻止你写 _, _ = someFunc() 来丢弃 error。这是最常被审查工具（如 errcheck）报出的问题。
另一个极端是遇到错误就 panic。仅在程序无法继续运行（如配置加载失败、监听端口失败）时才该 panic；业务逻辑中的错误（如用户输入非法、数据库查不到记录）必须返回 error 并由上层决定重试、提示或降级。
- 禁止：
json.Unmarshal(data, &v) // 忽略 error - 禁止：
if err != nil { panic(err) }（除非在main初始化阶段且明确不可恢复） - 推荐：
if err != nil { return fmt.Errorf("decode request body: %w", err) }
自定义错误类型要实现 Error() 方法
如果需要携带额外字段（如状态码、请求 ID），应定义结构体并实现 Error() string 方法。注意：不要导出 Error() 方法名以外的字段，除非上层明确需要访问；更安全的做法是提供访问器函数，比如 StatusCode()。
同时，避免在 Error() 方法里做耗时操作（如格式化时间、HTTP 请求），因为日志或调试时可能频繁调用它。
type ValidationError struct {
Field string
Message string
Code int
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
}
func (e *ValidationError) StatusCode() int {
return e.Code
}
错误链、日志上下文、测试中对错误的断言——这些都依赖于错误是否正确实现了接口和包装方式。越早统一规范，后续加监控、做错误分类、对接 Sentry 就越省事。
