Go中返回nil error却行为异常，表明存在假成功：错误被静默吞掉、状态未更新或逻辑分支遗漏err赋值；所有return路径必须显式设置err，避免命名返回+defer误改，禁用(*MyError)(nil)，类型断言须检查ok。
Go中返回 nil error 表示“操作成功”，但程序行为却异常——这说明你正在面对一个**假成功（false success）**：错误被静默吞掉、状态未更新、资源未初始化，或逻辑分支遗漏了 err 赋值。这不是 nil 本身有问题，而是它被当作“无需处理”的默认值，掩盖了真正的控制流缺陷。
函数所有 return 路径必须显式赋值 err
最常见原因：声明了 err error，但在某些分支（尤其是 if 或 else if 块）里没给它赋值，导致返回的是零值 nil，而非真实错误。
常见错误现象：
- mock 测试时依赖返回
nil，主逻辑却该失败却没失败 - HTTP handler 返回 200，但数据库没写入、缓存没刷新
- 日志里看不到报错，但下游系统收不到数据
实操建议：
- 每个
return前检查err是否已被明确设置（包括成功路径） - 避免用命名返回参数 +
defer修改err，易读性差且覆盖逻辑难追踪 - 启用
errcheck工具：它能自动发现未检查的 error 返回值，也能反向帮你揪出“漏赋值”问题
func processUser(id int) (string, error) {
var err error
var name string
if id == 0 {
// ❌ 错误：这里没设 err，函数返回默认 nil
return "", nil // 实际应 return "", errors.New("invalid id")
}
name, err = fetchName(id)
if err != nil {
return "", err
}
// ✅ 正确：所有路径都明确控制 err
return name, nil
}
别把 (*MyError)(nil) 当成 nil error
当你定义了自定义错误类型并返回其指针时，nil 指针 ≠ nil interface。Go 的接口比较要求 Type 和 Value 同时为 nil，而 &MyError{} 或 (*MyError)(nil) 都是非 nil 接口值。
常见错误现象：
- 函数明明想表示“无错误”，却返回
var e *MyError = nil，调用方if err != nil永远为 true - 单元测试断言
assert.Nil(t, err)失败，但fmt.Printf("%v", err)却打印
实操建议：
- 自定义错误只在需要时才返回非 nil 实例；绝大多数成功路径直接
return nil - 绝不要写
return (*MyError)(nil)或return &MyError{}来“假装成功” - 如果必须返回结构体错误，确保它的
Error()方法对零值有合理输出，但仍需使用者按err != nil判断
type ValidationError struct {
Field string
Msg string
}
func (e *ValidationError) Error() string {
if e == nil {
return "" // 零值不 panic，但注意：这仍是非-nil error！
}
return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Msg)
}
// ❌ 危险写法：返回 (*ValidationError)(nil) → 接口非 nil
func badValidate() error {
return (*ValidationError)(nil)
}
// ✅ 正确写法：真成功就 return nil
func goodValidate() error {
return nil
}
类型断言后忘记检查 ok 导致 panic
对 error 做类型断言（如 err.(*os.PathError)）时，若 err 是 nil，断言结果变量是 nil，但不会 panic；一旦你直接解引用（如 e.Path），就会立即崩溃。
常见错误现象：
- 日志刚打出
err=，下一行就 panic：invalid memory address - CI 环境偶尔失败，本地却复现不了——因为某些路径恰好返回了
nilerror
实操建议：
- 永远用双变量形式做断言：
e, ok := err.(*os.PathError)，且 先检查ok再用e - 优先使用
errors.As(err, &target)（Go 1.13+），它内部已安全处理nil边界 - 禁用
err.(*MyErr).Field这类无保护强制断言
// ❌ 危险：nil err 断言后直接解引用
if pathErr := err.(*os.PathError); pathErr.Op == "open" { ... } // panic!
// ✅ 安全：显式检查 ok
if pathErr, ok := err.(*os.PathError); ok && pathErr.Op == "open" {
log.Printf("open failed on %s", pathErr.Path)
}
// ✅ 更推荐：用 errors.As
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("open failed on %s", pathErr.Path)
}
真正棘手的不是 nil error，而是它被当成“可忽略的占位符”。每次你写 return nil，都要确认这是有意为之的成功信号；每次你看到 err != nil，都要信任它足够可靠——这种确定性，来自对每一条执行路径的显式控制，而不是对零值的侥幸依赖。
