Go错误需显式传递，不可自动冒泡；必须每层检查err并用%w包装以保留错误链，避免丢失上下文或覆盖错误。
Go 中错误不能自动向上冒泡，必须显式返回
Go 没有异常机制，error 是普通返回值。如果中间某层函数没把 err 返回给上层，错误就“消失”了——不是被忽略，而是彻底丢失上下文。常见表现是程序静默失败，日志里只看到 nil，但业务逻辑已出错。
实操建议：
- 每层调用后立即检查
err != nil，不写if err != nil { return err }就等于埋雷 - 避免在中间层做“吞掉错误 + 打日志 + 返回
nil”，这会让调用方无法决策重试、降级或告警 - 若需补充上下文，用
fmt.Errorf("failed to %s: %w", action, err)包装，保留原始错误链
使用 %w 格式动词保留错误链，别用 %v 或字符串拼接
%w 是 Go 1.13 引入的关键字，它让 errors.Is() 和 errors.As() 能穿透多层包装定位原始错误。用 %v 或 + " failed" 会切断链路，导致无法判断是否是 os.ErrNotExist 这类特定错误。
示例对比：
立即学习“go语言免费学习笔记（深入）”；
err := os.Open("config.json")
if err != nil {
// ✅ 正确：保留原始 error 类型
return fmt.Errorf("loading config: %w", err)
// ❌ 错误：丢失类型信息，errors.Is(err, os.ErrNotExist) 永远为 false
// return fmt.Errorf("loading config: %v", err)
// return errors.New("loading config failed: " + err.Error())
}
在 HTTP handler 或 CLI 命令入口统一处理错误，避免每层都写日志
错误日志只应在最外层（如 main()、HTTP HandlerFunc）打一次。中间层加日志会导致重复输出，还可能因 panic 捕获顺序混乱而漏记关键错误。
典型结构：
- 底层函数（如
ReadFile()）只返回error，不打印 - 业务层（如
ProcessOrder()）用%w包装并传递 - 入口层（如
http.HandlerFunc）检查最终err，统一记录、返回 HTTP 状态码或 CLI exit code
这样既保证错误可追溯，又避免日志爆炸。
注意 defer 中的错误覆盖问题
当函数有多个 return，且 defer 里调用了可能失败的操作（如 Close()），容易发生错误被覆盖：前面的业务错误还没返回，就被 defer 里的 Close() error 覆盖了。
安全写法：
- 对必须关闭的资源，用
if r != nil { _ = r.Close() }忽略关闭错误（除非关闭失败本身需要处理） - 若关闭错误关键（如写文件后
Close()失败可能意味着数据未落盘），应单独捕获并合并到主错误中：err = fmt.Errorf("write and close failed: %w; close error: %v", err, closeErr) - 避免在
defer中直接return或修改命名返回值
错误逐层传递不是靠技巧，而是靠每一步都明确“这个错误该不该继续往上交”。最容易被忽略的是：包装错误时忘了 %w，以及在 defer 里不加区分地把关闭错误当成主错误返回。
