Go中nil error是明确的成功信号，需显式、安全、一致处理：用err != nil判断；返回自定义error优先用nil而非空结构体；类型断言后先检查ok；函数所有路径须明确赋值err；测试覆盖nil边界。
在Go中，nil作为error的合法值，常被误认为“没有错误”，但实际可能隐藏类型不匹配、接口未正确实现或指针解引用风险。关键不是避免用nil，而是确保它被**显式、安全、一致地处理**。
明确error接口的nil语义
Go标准库约定：err == nil表示操作成功，非nil才代表出错。但注意：一个实现了error接口的自定义结构体，即使其字段全为零值，只要不是nil指针，就仍是非nil错误（比如&MyError{}）。
- 永远用
if err != nil判断，不要用if err == nil反向推导 - 返回自定义error时，优先返回
nil而非空结构体指针 - 若必须返回结构体实例（如带上下文的错误），确保其
Error()方法对零值有合理输出，且使用者仍需按err != nil检查
警惕类型断言与nil panic
对error做类型断言（
如e, ok := err.(*os.PathError)）时，如果err是nil，断言结果e也是nil，不会panic；但若后续直接解引用e（如e.Err），就会panic。
- 类型断言后务必先检查
ok，再使用断言变量 - 避免写
err.(*MyErr).Field这种无保护的强制断言 - 需要区分错误类型时，优先用
errors.As(err, &target)（Go 1.13+），它能安全处理nil
函数返回error前做显式nil校验
自己写的函数若组合多个子调用，容易因逻辑分支遗漏而返回未初始化的error变量（默认为nil），造成“假成功”。尤其在多err变量、defer中赋值等场景。
- 声明
err error后，在所有return路径上明确赋值（包括成功路径显式写return nil） - 避免在defer中修改命名返回参数并期望覆盖主逻辑的err值，易读性差且易出错
- 用静态检查工具如
errcheck捕获未检查的error返回值，从源头减少忽略
测试nil error边界情况
单元测试不仅要覆盖错误路径，更要验证nil error是否被正确传播和响应。例如mock依赖返回nil时，主逻辑是否真没报错、状态是否更新正确。
- 为每个返回error的函数写至少一个case：输入/依赖返回
nil，验证行为符合预期 - 用
testify/assert等断言assert.Nil(t, err)比assert.Equal(t, nil, err)更清晰 - 对HTTP handler等入口函数，模拟底层服务返回
nilerror，确认响应码、body不含错误信息
基本上就这些。核心是把nil error当成一种**明确的成功信号**，而不是“没想好怎么处理”的占位符。每次写return nil，都确认它是有意为之；每次读err != nil，都信任这个判断足够可靠。
