staticcheck 需正确配置才能有效发现运行时隐患：用 curl 安装脚本而非 go install，确保在 go.mod 目录下运行，合理开关规则（如必开 SA1019/SA9003），CI 中固定版本、Go 版本和缓存路径，并禁用并发扫描。
staticcheck 能直接发现大量运行时才暴露的隐患，但默认配置下容易漏报、误报甚至 CI 失败——关键不在“装没装”，而在“怎么配、怎么跑、怎么防翻车”。
怎么装才不会踩 Go module 和 PATH 的坑
别用 go install，它会污染 GOPATH、拉错版本、且不保证二进制可执行。官方明确推荐 curl 安装脚本：
- 运行
curl -sSfL https://staticcheck.io/install.sh | sh，它会把二进制放进$HOME/bin - 确认
$HOME/bin在$PATH里（macOS zsh 用户检查~/.zshrc，Linux bash 检查~/.bashrc） - 执行
staticcheck --version验证；若报 command not found，八成是 PATH 没生效，别 reload shell，直接source ~/.zshrc或重启终端
为什么 staticcheck ./ 报 “no Go files in directory”
这不是路径写错了，而是 staticcheck 依赖 Go modules 的上下文来加载类型信息。它不是单纯扫文件，而是要解析整个模块。
- 必须在项目根目录（即有
go.mod的目录）下运行 - 确保
GO111MODULE=on（Go 1.16+ 默认开启，但某些 CI 环境或旧 shell 可能关着） - 如果项目是 vendor 模式或无模块，staticcheck 无法工作——它不支持 GOPATH mode
- 第一次运行慢是正常的，它在构建类型图谱；后续会缓存，速度明显提升
哪些规则该开、哪些该关、怎么配
默认启用 90+ 条规则，但多数项目只需聚焦几条高价值、低误报的检查项。配错规则比不配更危险。
立即学习“go语言免费学习笔记（深入）”；
- 必开：
SA1019（调用已弃用 API）、SA9003（无用的return）、SA4006（重复赋值） - 谨慎开：
SA1006（未使用的 fmt 参数）——模板字符串多的项目（如 HTML 渲染层）极易误报 - 建议关：
SA4022（比较函数是否相等）、SA5008（struct 字段未导出却带 JSON tag）——除非团队强约定字段导出规范 - 禁用单条：用
-checks=-SA1006；只开几条：用-checks=SA1019,SA9003 - 配置文件优先用
.staticcheck.conf（TOML 格式），比命令行参数更易维护和 CI 复用
CI 里跑 staticcheck 总失败，本地却正常？
这不是工具问题，而是环境漂移——Go 版本、模块路径、并发分析触发竞态，三者任一不一致都会导致结果不同。
- CI 脚本中必须固定 staticcheck 版本，例如用
curl ... | sh -s -- -b $GOPATH/bin v0.15.0，别用latest - 确保 CI 使用的 Go 版本 ≥ 本地版本（尤其 Go 1.21+ 对泛型分析更稳）
- 加
--cache-dir指向 CI 工作区内的可写路径，避免默认缓存被多个 job 冲突 - 避免并发扫描：CI 中统一用
staticcheck -j1 ./，防止类型信息加载竞态 - 如果用
golangci-lint包裹 staticcheck，注意它默认启用unused，而unused和staticcheck对未使用变量的判断逻辑略有差异，可能造成“一个报、一个不报”
真正难的不是让 staticcheck 跑起来，而是让它在 PR 提交那一刻就精准指出那行不该写的 if *p != 0，而不是等 panic 发生在生产环境。规则开关、缓存路径、并发控制——这些细节不显眼，但每一条都卡在“有没有效”和“敢不敢信”的边界上。
