Go代码审查自动化需分层使用gofmt、go vet、staticcheck和revive，CI仅纳入确定性高、无误报的检查，如gofmt -l、go vet和staticcheck默认规则；revive替代golint需定制配置，关闭主观规则、启用deep-exit等语义检查；go vet专注语言级零误报陷阱，staticcheck则深入类型与控制流发现隐蔽问题；规则须随团队共识和高频bug动态收敛。
Go 代码审查自动化不是靠人工加个 CI 脚本就能解决的，核心在于选对工具链、明确检查边界、并把 gofmt、go vet、staticcheck 和 golint（或 revive）按职责分层使用——混用或漏掉任意一层，都会让审查流于形式。
哪些检查必须进 CI，哪些只能本地跑
CI 中只放「确定性高、无误报、不依赖上下文」的检查：比如 gofmt -l（格式差异）、go vet（死代码、反射 misuse、printf 参数错位等）、staticcheck（最严的静态分析，默认规则集已覆盖绝大多数低级错误）。这些工具输出稳定，失败即阻断。
以下检查不适合进主 CI 流程：
-
revive的 style 类规则（如函数长度、嵌套深度）——主观性强，易引发 PR 争议 - 自定义 AST 分析脚本（如“禁止硬编码超时值”）——需先统一团队认知，再灰度启用
-
go test -race——应单独跑在 nightly job，避免拖慢 PR 反馈
如何配置 revive 替代已弃用的 golint
golint 自 Go 1.21 起已被官方归档，revive 是目前最主流的替代方案，但默认配置太松。关键是要关掉模糊规则、打开语义检查：
立即学习“go语言免费学习笔记（深入）”；
- 用
--config revive.toml指定配置文件，而非依赖默认 - 禁用
exported、var-naming等风格类规则（除非团队已达成命名共识） - 强制开启
deep-exit（检测 os.Exit 在 defer 中被忽略）、time-naming（time.Duration 字面量未带单位）等高价值规则 - 示例片段：
failures-only = true severity = "warning" rules = [ { name = "deep-exit" }, { name = "time-naming" }, { name = "empty-block" } ]
为什么 go vet 有时不报错，但 staticcheck 会报
go vet 是 Go 官方维护的轻量级检查器，设计目标是「零误报、极快、只覆盖语言级陷阱」；而 staticcheck 是独立项目，深度介入类型系统和控制流图，能发现更隐蔽问题：
-
go vet不检查if err != nil { return } defer f()中 defer 是否会被跳过 ——staticcheck的SA5001会报 -
go vet对 map 并发读写仅在极简 case 下提示 ——staticcheck的SA1018能识别跨函数传递 map 的风险 - 两者都支持
-tags，但staticcheck的--go-version参数必须显式设为项目实际版本，否则可能漏掉新语法相关检查（如泛型约束误用）
真正难的是规则收敛：不同人对「什么算可接受的技术债」理解不同，自动化审查的价值不在发现所有问题，而在把团队共识固化成不可绕过的门禁。别指望一个配置文件一劳永逸，每季度要根据最近 merge 的 PR 里高频出现的 bug 类型，反向调整检查项权重。
