golangci-lint本身不检查运行时空指针panic，但通过集成staticcheck和errcheck可捕获高危指针用法模式；需在.golangci.yml中显式启用二者，并配置SA5011等规则。
golangci-lint 本身不检查空指针解引用
它不会报 panic: invalid memory address or nil pointer dereference 这类运行时错误——因为那发生在程序执行阶段，而 linter 只做静态分析。golangci-lint 能捕获的是「可能导致空指针 panic 的高危用法模式」，比如函数返回指针但调用方没检查 error、嵌套指针访问前无判空、接口断言后直接解引用等。
真正能提前揪出这类问题的，是它集成的两个关键 linter：
-
staticcheck：会警告json.Unmarshal传入nil指针、time.Now().UTC()冗余调用（虽不直接相关，但说明它关注 API 使用合理性） -
errcheck：强制你处理所有返回error的函数调用，避免像db.QueryRow(...).Scan(&v)前没检查db是否为nil或QueryRow返回的err
注意：go vet 对空指针逻辑也基本无感，它只抓明显类型/语法错误（如 fmt.Printf 参数不匹配）。
用 golangci-lint 检查指针安全的关键配置
默认配置下，errcheck 和 staticcheck 往往是关闭或弱启用的。必须显式打开并微调：
立即学习“go语言免费学习笔记（深入）”；
- 在
.golangci.yml中启用：errcheck（检查所有error返回值）、staticcheck（推荐全开） - 禁用
gosimple的S1039规则（禁止fmt.Sprintf拼 SQL），这属于业务层约束，和指针安全无关 - 确保
staticcheck启用了SA5011（检测对可能为nil的 map、slice、channel 的操作）和SA1019（检测已弃用 API，部分弃用项与指针生命周期相关）
示例片段：
linters-settings:
errcheck:
check-type-assertions: true
check-unused: true
staticcheck:
checks: ["all"]
为什么 interface{} == nil 不等于底层指针为 nil
这是最常被 golangci-lint 漏掉、但 runtime 一定会 panic 的点：一个 interface{} 变量即使动态值是 *User 且该指针为 nil，它自身也不等于 nil。代码写成 if data != nil { u := data.(*User); _ = u.Name }，一旦 data 是 nil *User，u.Name 就直接 panic。
- 正确写法必须两步：
if u, ok := data.(*User); ok && u != nil -
staticcheck在某些场景下能识别这种模式（如从map取值后直接断言），但不是 100% 覆盖 - 更稳妥的做法是封装工具函数：
SafeDereference[T any](p *T) (T, bool)，把判空逻辑收口
排查 nil 指针 panic 的实际顺序比工具更重要
遇到 invalid memory address or nil pointer dereference，别急着改 linter 配置。先按这个链路快速定位：
- 看 panic 栈顶行：是不是在
db.QueryRow、u.Profile.Name、m["k"] = v这类操作上？确认崩溃点是哪一层解引用 - 回溯上一行：那个变量（
db、u.Profile、m）是怎么来的？是sql.Open返回？结构体字段赋值？make(map[string]int)？ - 重点查三处：
NewEngine("dm", dsn)是否忽略err导致db为nil；var u User后直接访问u.Profile.Name（Profile字段未初始化）；map或slice本身为nil就写入
工具只能帮你拦住一部分隐患，真正的防御靠的是每次解引用前那一行 if p != nil —— 它不优雅，但有效，且被 staticcheck 明确认可。
