在使用时直接扫描全部代码

写代码一时爽，维护代码火葬场。这几乎是所有 Go 开发者的共识。与其在 Code Review 时为了一个 `fmt.Sprintf` 的参数错误争论半天，不如把这种低级错误扼杀在摇篮里。今天不聊那些高深的并发模型，也不聊眼花缭乱的架构设计，咱们就脚踏实地，聊聊每个 Go 项目都应该立刻用起来的两个基础武器：`go vet` 和 `staticcheck`。

防线一：go vet，官方自带的贴身保镖

如果说 Go 语言的类型系统是一道严密的防火墙，那么 `go vet` 就是防火墙后面的内审员。它是 Go 官方工具链自带的静态检查工具，当你的代码能通过编译时，它能用“上帝视角”帮你看穿潜在的问题。

之前我就在生产代码里埋过雷。当时为了拼接 SQL，打了个 `log.Printf("User query: %s %s", query)`，自以为天衣无缝。结果 `go vet` 直接报错，说格式字符串和参数数量对不上。这种错误如果不查出来，线上日志里全是乱码，排查问题的时候哭都来不及。

`go vet` 的核心价值在于检测那些编译能通过，但在逻辑上就是错误的代码。它擅长抓的问题包括：

- `Printf` 格式串匹配错误：这是一个极其高频的坑。`%d` 对应了 string，`%s` 却塞了个 int，编译器不管，但 `vet` 管。
- `lock` 复制：在你 `go vet ./...` 时，如果它发现你把 `sync.Mutex` 这种带锁对象直接按值复制了，会立刻红牌。锁一旦被复制，锁就“锁了个寂寞”，并发安全直接没了。
- `unreachable code`：检测到 `defer` 后面的代码，或者 `return` 后的逻辑。这些隐藏的未达代码，很可能就是某次重构时的残留垃圾。

最良心的是，`go vet` 是随官方工具链分发的，不需要额外安装。在 CI 流程里加上一条 `go vet ./...` 的命令，成本极低，收益却极高。这就像吃饭前洗手一样，属于成本极低但捍卫生命线的基础卫生习惯。

防线二：staticcheck，敏锐的代码侦探

如果说 `go vet` 是“保底”，那 `staticcheck` 就是“拔高”。这个第三方工具（源码在 `github.com/dominikh/go-tools` ），在 `vet` 的基础上，把检查维度提升到了代码包袱和性能隐患的高度。

有一次 review 代码，看到同事写的这段：

for i := 0; i < len(s); i++ {
    b, _ := json.Marshal(s[i])
    // 用 b 做些什么
}

`go vet` 对此毫无反应，因为语法正确。但 `staticcheck` 会一眼看穿：你在循环里反复分配临时对象。它会提示你 `S1025` (可以使用 `fmt.Sprintf` 或 prealloc 优化) 或者建议直接移动 `Marshal` 到循环外——这类问题不立即炸，但在高并发下就是纯纯的 GC 压力与延迟来源。

`staticcheck` 是个庞大的武器库，它的检查规则非常丰富，涵盖了：

- 不必要的复杂表达式：比如能用 `strings.ReplaceAll` 却还在手写 RegExp，`staticcheck` 会温和地告诉你“有更好的选择”。
- 无效的 nil 检查：`if x == nil` 但 `x` 其实是不可为 nil 的类型，这段代码纯属白写。
- 疑似断言的错误用法：在类型断言时忽略 `, ok` 返回，导致 panic 的隐患。
- 变量遮蔽（shadowing）：这在 Go 里非常经典，`:=` 用多了，一个不小心就在内层作用域重新声明了一个变量，导致外层赋值失效，排查起来极其痛苦。

在项目中运行 staticcheck 的标准姿势是：

# 安装
go install honnef.co/go/tools/cmd/staticcheck@latest


staticcheck ./...

对比 `go vet`，`staticcheck` 更像是一位有点“唠叨”但关键时刻能救命的前辈。它会告诉你问题在哪，甚至通过 `S`, `SA` 开头的错误码能查到对应的官方 Wiki 解释，让你知其然并知其所以然。

一线实践的黄金组合

很多同学会在 IDE 里装了插件就以为万事大吉。但你写好代码后，保存触发的那一下检查，跟 CI 跑的未必是同一套标准。作为强制防线，我们应该在 CI Pipeline 的最早期阶段，就把这两把剑祭出来。

伪代码如下：

go-verification:
  stage: lint
  script:
    - go vet ./...
    - staticcheck ./...

为什么要同时用二者？

因为它们相互补充。`go vet` 主攻正确性，解决“代码跑起来是错的”；`staticcheck` 主攻健壮性，解决“代码跑起来没问题，但迟早会炸/性能差/难维护”。这两者的侧重点完全不同。单靠其中任何一个，都无法拦住全部风险。

另外，建议每经过几次较重大的重构，都用上述命令跑一遍。你会发现，很多隐藏多年的“屎山”代码，在重锤之下会原形毕露。

总结：防线永远比补牢重要

代码质量不是靠追忆，而是靠预防。在 Go 的生态里，进行“Code Review”的成本是很高的，尤其是面对同事那几百行的 Diff 时，人的精力是最不可靠的约束。而 `go vet` 与 `staticcheck` 是廉价的、高效的、不眠不休的守夜人。

养成习惯，在提交 PR 之前，先运行一遍 `go vet ./...` 和 `staticcheck ./...`。用几分钟的扫描时间，节省几小时的 debug 时光，这笔账怎么算都划算。毕竟，作为开发者，我们不追求写出没有 bug 的代码，我们追求的是，在 bug 爆发前，就已经用工具堵住它们的去路。