errcheck 能发现漏掉的 error 检查，因为它基于 AST 静态分析识别未显式处理（如 if err != nil、赋值或传递）的 error 返回值，不运行代码、速度快、误报少，但对泛型和深层链式调用支持有限。
errcheck 工具为什么能发现漏掉的 error 检查
Go 编译器不强制你处理 error 返回值，只警告未使用的变量。而 errcheck 是基于 AST 静态分析的工具，它识别所有函数调用中返回 error 类型却没被显式检查（比如没跟 if err != nil、没赋给变量、没传给其他函数）的语句。
它不运行代码，也不依赖类型推导以外的上下文，所以速度快、误报少，但对泛型或嵌套过深的链式调用支持有限。
- 只扫描
.go文件，默认跳过_test.go和 vendor 目录 - 对
fmt.Printf、log.Println这类“消费”错误但不算“处理”的写法，errcheck仍会报错——它认的是显式判断或赋值，不是日志输出 - 如果函数返回多个值且最后一个为
error，但你只解构了前几个（如a, b := fn()），errcheck会标记为遗漏
怎么安装和运行 errcheck 才不踩坑
最常用方式是用 go install，注意路径和 Go 版本兼容性：
- Go 1.21+ 推荐：
go install github.com/kisielk/errcheck@latest；安装后二进制在$GOBIN/errcheck（通常为$HOME/go/bin），需确保该路径在$PATH中 - 若提示
command not found: errcheck，别直接go run，那会每次编译，慢且无法复用缓存 - 默认扫描当前目录及子目录所有包，想限定范围就加路径参数，例如：
errcheck ./internal/... ./cmd/... - 遇到
cannot find package错误，大概率是模块未初始化（缺go.mod）或GO111MODULE=off，先go mod init或确认环境变量
常见误报和必须忽略的场景
errcheck 不是万能的，有些地方它“看不懂”，硬加检查反而破坏逻辑清晰性：
立即学习“go语言免费学习笔记（深入）”；
- 调用
os.Exit、log.Fatal等终止程序的函数后，后续语句不可达，但errcheck仍可能报上一行的err未检查——此时应加//nolint:errcheck注释 - 测试文件里调用
t.Fatal或require.NoError，错误已被断言框架处理，无需再写if err != nil；但errcheck默认不跳过_test.go，得手动加-exclude=_test.go - 某些接口方法约定返回
error但实际永不失败（如bytes.Buffer.Write），可加//nolint:errcheck并附简短说明，避免后人误改
和 linter 集成时的关键配置点
在 golangci-lint 中启用 errcheck 很方便，但默认行为容易掩盖真实问题：
- 务必关掉
check-all模式（即不要设check-all: true），否则它会对所有函数返回值都检查，包括不返回error的函数，导致大量误报 - 推荐显式启用并限制作用域：
enable: [errcheck]+settings.errcheck.check-blank: false（避免检查_, err := ...这种已明确丢弃错误的写法） - 如果项目用了
errors.Is或errors.As做错误匹配，errcheck本身不关心这些，但它要求你至少先把err变量拿住——所以不能写if errors.Is(fn(), os.ErrNotExist)，必须先err := fn(); if errors.Is(err, ...)
真正难的不是跑通 errcheck，而是分辨哪些 error 必须立刻响应、哪些可以静默丢弃、哪些该记录但不中断流程。工具只能标出“没写”，决定“要不要写”还得看业务语义。
