Go错误处理应拆分检查、用%w包装、显式处理Close错误、定义错误变量。错误是控制流一部分，需全程保持错误链完整。
错误检查别堆在一行里
很多人写 if err != nil 时习惯把错误处理逻辑和上一行函数调用挤在一起，比如：
if err := json.Unmarshal(data, &v); err != nil { return err } 这样写短期看着省行，但调试时很难加断点、难插日志、难判断 data 或 &v 是否有问题。更清晰的做法是拆开：err := json.Unmarshal(data, &v)
if err != nil {
return fmt.Errorf("failed to unmarshal JSON: %w", err)
} 拆开后你能单独 inspect data 和 &v，也能在 err 赋值后加 log.Printf 观察原始输入。
用 %w 包装错误而不是 %s
错误链（error wrapping）是 Go 1.13 引入的关键机制，但很多人仍用字符串拼接：
return errors.New("failed to open config: " + err.Error()) 这会丢失原始错误类型和堆栈。正确方式是用 %w：return fmt.Errorf("failed to open config: %w", err) 这样下游可用 errors.Is(err, fs.ErrNotExist) 或 errors.As(err, &pathErr) 做类型判断。注意：%w 只能出现在格式字符串末尾，且只能包装一个错误；多个错误要嵌套或用自定义 error 类型。
避免在 defer 中忽略 Close() 错误
常见反模式：
f, _ := os.Open("file.txt")
defer f.Close() // 忽略 Close 可能返回的 error 文件系统满、磁盘损坏、NFS 挂载异常时，Close() 真的会返回错误。更安全的写法是显式检查：f, err := os.Open("file.txt")
if err != nil {
return err
}
defer func() {
if closeErr := f.Close(); closeErr != nil {
log.Printf("warning: failed to close file: %v", closeErr)
}
}() 如果业务要求 Close() 必须成功（比如写临时文件后需确保落盘），那就不能 defer，而应在主流程末尾同步检查并返回。
自定义错误类型比字符串判断更可靠
当需要区分“用户不存在”和“数据库连接失败”这类语义错误时，别用 strings.Contains(err.Error(), "not found") —— 一旦错误信息微调（比如加了时间戳或字段名），逻辑就崩。应该定义明确的错误变量：
var ErrUserNotFound = errors.New("user not found")
// 使用
if errors.Is(err, ErrUserNotFound) {
return handleUserNotFound()
} 更进一步，如果需要携带上下文（如用户 ID），可实现 Unwrap() 和 Error() 方法，让 fmt.Errorf("loading user %d: %w", id, ErrUserNotFound) 依然能被 errors.Is 正确识别。
Go 的错误不是装饰品，它是控制流的一部分。越早把错误当作值来传递、包装、判断，后续加监控、重试、降级就越自然。最容易被忽略的是：**错误链的完整性依赖每一层都用 %w，漏一次，下游就断链**。 
