Go 语言强制显式处理 error，必须作为最后一个返回值；应使用 %w 包装错误以支持上下文展开；避免中间层 panic 或 log.Fatal；自定义错误仅在需额外字段或行为时引入。
Go 语言中没有异常机制，error 是一等公民，函数返回错误必须显式检查——这不是风格偏好，而是类型系统强制要求的协作契约。
函数签名里必须把 error 作为最后一个返回值
这是 Go 社区强共识，也是标准库、go fmt 和静态分析工具（如 errcheck）依赖的约定。不遵守会导致调用方无法用 if err != nil 统一处理，且易被误认为“无错误”。
常见错误现象：
- 把
error放在中间或开头，例如func ReadConfig() (error, *Config) - 用自定义结构体包装错误并忽略标准
error接口，导致无法和fmt.Errorf、errors.Is等协同
正确写法示例：
func OpenFile(name string) (*os.File, error) {
f, err := os.Open(name)
if err != nil {
return nil, fmt.Errorf("failed to open %s: %w", name, err)
}
return f, nil
}
用 %w 包装错误而非 %v 或字符串拼接
%w 是 Go 1.13 引入的动词，它让错误具备“可展开性”，支持 errors.Is、errors.As 和 errors.Unwrap。不用 %w 就等于丢弃原始错误上下文，调试时只能看到顶层提示。
使用场景：
- 跨包调用时需要保留底层错误类型（比如判断是否是
os.IsNotExist） - 日志中需区分“业务失败”和“基础设施失败”
错误示范：
return nil, fmt.Errorf("open failed: %v", err) // ❌ 丢失原始 error 类型
正确示范：
return nil, fmt.Errorf("open failed: %w", err) // ✅ 可用 errors.Is(err, os.ErrNotExist)
不要在每个函数里都 log.Fatal 或 panic
Go 的错误处理模型是“向上冒泡”，由最外层（如 main 函数或 HTTP handler）决定如何响应：重试、降级、记录、返回 HTTP 500，还是直接退出。中间层调用者不掌握上下文，强行终止会破坏可控性。
容易踩的坑：
- 在工具函数里写
log.Fatal("DB connect failed")，导致单元测试无法捕获错误而直接崩溃 - 用
panic替代error，绕过类型检查，让调用方无法防御
HTTP handler 示例（错误应传递给上层统一处理）：
func handleUser(w http.ResponseWriter, r *http.Request) {
user, err := getUserFromDB(r.URL.Query().Get("id"))
if err != nil {
http.Error(w, "user not f
ound", http.StatusNotFound)
return
}
json.NewEncoder(w).Encode(user)
}
自定义错误类型要实现 error 接口且避免过度设计
只有当需要携带额外字段（如错误码、追踪 ID）或支持特定行为（如重试判定）时，才定义结构体错误。多数情况用 fmt.Errorf + %w 足够。
性能与兼容性影响：
- 实现
Unwrap()方法才能被errors.Is正确识别 - 导出字段（如
Code int）会让包 API 变重，后续难以修改 - 若只用于日志，字符串方法
Error()返回足够信息即可，不必加字段
轻量自定义错误示例：
type ValidationError struct {
Field string
Msg string
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation error on %s: %s", e.Field, e.Msg)
}
func (e *ValidationError) Unwrap() error { return nil } // 不包装其他 error，无需 unwrap
真正难的是错误分类粒度：太粗（全用 fmt.Errorf）导致无法区分处理；太细（每个业务路径一个 error 类型）又增加维护成本。建议从 HTTP 状态码映射或重试策略出发反推错误边界，而不是一开始就设计继承树。
