nilerr检查器用于检测go函数中未赋值error导致静默返回nil的问题；需在.golangci.yml中显式启用，可识别if分支遗漏、defer覆盖命名返回err及自定义错误误返回nil三类隐患。
当你在 Go 项目中写完一个返回 error 的函数，却忘了在某条分支里给 err 赋值，golangci-lint 的 nilerr 检查器能立刻发现这个隐患——它专盯那些本该返回非 nil error 却静默返回了 nil 的路径。
启用 nilerr 检查器
在 .golangci.yml 配置文件中添加 nilerr 到 linters-settings → nilerr 下，或直接在 linters 字段中显式启用：
linters:
- nilerr
这一步必须做，否则 golangci-lint 默认不运行 nilerr；它不属于默认启用的 linter 列表。
识别典型漏赋值模式
nilerr 主要捕获三类问题：if 分支未设 err、命名返回参数被 defer 覆盖、以及自定义错误类型误返回 (*MyError)(nil)。
方法一：if/else 中遗漏 err 赋值
func fetchConfig(name string) (string, error) {
var err error
if name == "" {
return "", errors.New("name required") // ✅ 显式返回 error
}
if name == "prod" {
return "prod.conf", nil // ❌ 这里没设 err，但函数签名含命名返回 error，实际返回零值 nil
}
return "dev.conf", err // err 仍是零值，造成假成功
}
nilerr 会报错：“error is nil on return path”，因为它检测到该分支未对 err 做任何赋值，而函数又声明了 error 返回值。
方法二：命名返回 + defer 导致 err 被意外覆盖
func processFile(f *os.File) (data []byte, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panic during processing: %v", r) // ⚠️ 这里覆盖了原本的 err
}
}()
data, err = io.ReadAll(f)
return // 此处 err 可能是 nil，也可能被 defer 改写，语义模糊
}
【命名返回 + defer 修改 err 是 nilerr 的高危雷区】——它让 err 的最终值不可静态推断，nilerr 会标记该函数为“unpredictable error return”并告警。
修复并验证 nilerr 报告
第一步：运行检查命令
golangci-lint run --disable-all --enable nilerr ./...
第二步：定位报告中的 first line of function 定位点，找到对应函数名和文件行号
第三步：检查所有 return 语句前是否都明确设置了 err 变量（包括 if、else if、else、for 循环末尾、switch default 等）
第四步：将命名返回改为普通返回参数，消除 defer 对 err 的副作用。例如把 func foo() (int, error) 改为 func foo() (int, error)，内部用 var err error + 显式 return val, err
第五步：保存后重新运行上述命令，确认 nilerr 不再报错
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
