从零构建Go语言代码检查器：只花半小时就能让团队风格统一

你有没有遇到过这种场景：团队里每个人都在写Go，但是命名的习惯各不相同，有人喜欢用下划线，有人偏爱驼峰，每次代码审查都要在这些细节上浪费口舌。通用的代码检查工具能发现最常见的错误，但它不理解你们项目里自己定下的规矩。如果有一个办法，不用安装复杂的工具链，只靠Go标准库里的现成轮子，就能写一个只检查你们自己规则的检查器，你会不会立刻动手试一试？

代码检查器（Linter）本身并不神秘，它是一种不运行源代码的静态分析工具，通过扫描源文件来标示编程错误、潜在缺陷、安全漏洞和风格不一致的地方。对于Go语言来说，这个流程建立在抽象语法树（AST）之上：源文件被解析成一棵节点树，检查器在这棵树上遍历，发现不符合预期的地方就记录下来。今天我们就要用手把手的方式，从空文件夹开始，完成一个能挂载到golangci-lint上的自定义检查模块，规则直接参考Uber的Go风格指南——未导出的全局常量必须以下划线开头。

先聊一聊“为什么要自己写检查器”这件事。业界对这个问题其实一直有两种声音。支持复用通用检查器的人认为，像golangci-lint这样的工具已经内置了几十种规则，覆盖了bug、性能、安全等绝大多数场景，额外定制是过度设计，投入产出比太低。但另一方面，每一个长期维护的Go项目最终都会形成自己特有的惯用法和架构约定，这些约定通用的检查器永远无法覆盖。例如，某个团队可能强制要求错误处理的特定顺序，或者要求所有数据库查询必须经过一层封装。把这些规则变成自动检查，可以显著降低代码评审者的认知负担——人脑从重复的模式检查中解放出来，才能关注真正复杂的逻辑。这一次Uber的规范只是一个引子，它背后是一种更务实的态度：用最小的代码量解决最具体的问题，而不是试图制造一个包含所有规则的复杂系统。这恰恰是Go语言通过golang.org/x/tools暴露AST和分析框架给我们带来的便利。

具体动手之前，先把工具链摆清楚。我们需要两个核心的依赖库，一个是golang.org/x/tools，它提供了go/analysis框架和AST检查的一系列实用函数；另一个是github.com/golangci/plugin-module-register，这个模块让golangci-lint能够动态加载我们的检查器作为插件。go.mod文件长这个样子：

module github.com/{yourusername}/unexportedconstantcheck
go 1.25.0
require (
github.com/golangci/plugin-module-register v0.1.2
golang.org/x/tools v0.45.0
)
require (
golang.org/x/mod v0.36.0 // indirect
golang.org/x/sync v0.20.0 // indirect
)

模块路径你可以换成自己的仓库地址，版本号随发布可能会有变化，但核心思路就是这样：依赖两个分析相关的顶层库，再附带它们自己的间接依赖。一旦go mod tidy跑通，工具层面的准备就算完成了。

在开始写检查逻辑之前，最好亲眼看看一个Go源文件的AST长什么样，这对理解后续的节点遍历很有帮助。我们建一个简单的分析器，名叫astexample，它的唯一任务就是把传入的每一个文件的AST打印到标准输出。分析器的主体函数会拿到一个analysis.Pass对象，遍历其中的Files切片，对每个文件调用ast.Print。运行命令就一行：go run . ./...，输出出来的庞大文本就是当前目录下所有Go文件的AST层级结构。你会在里面看到Ident、ValueSpec、ConstSpec这些节点，后面我们在遍历常量声明时会反复遇见它们。

到这一步，就可以着手实现我们自己的规则了。要做的检查非常直白，按照Uber的规范：所有未导出（即首字母小写）的全局常量，名字必须以下划线开头；唯一例外是那些以“err”开头的常量，它们可以不加下划线。这是典型风格型检查，逻辑简单，却足以展示分析器框架的所有基本概念。

在golang.org/x/tools的分析模型中，有四个绕不开的概念：Node、Analyzer、Pass和Diagnostic。Node就是AST中的任意节点，比如一个文件、一个函数声明或者一个常量定义。Analyzer是对检查器本身的抽象，它包含名字、文档、依赖的其他Analyzer，以及一个Run函数。Pass则是单次分析过程的上下文，它携带了依赖分析器的结果、当前检查的文件集合和报告问题的方法。Diagnostic就是我们最终要输出的问题信息，包含位置和消息。实现过程实际上是：注册一个Analyzer，在Run函数里利用Pass提供的便利遍历需要的节点，每发现一次违规就调用Pass.Report。

遍历节点的方法有两种：可以直接遍历Pass.Files，手动访问File.Decls等字段，也可以用go/analysis/passes/inspect提供的便利功能，用ast.Inspector做深度优先遍历。对于我们的常量检查，只要在遍历过程中找到所有*ast.ValueSpec节点，检查其Names列表，判断名字是导出还是未导出，如果是未导出且不以“err”开头，进一步检查是否以“_”开头，不满足就报告。整个逻辑不到五十行，但这五十行代码背后是Go编译器前端和静态分析工具的完整生态。

把检查器跑起来的方式也很简单，用singlechecker.Main包装我们的Analyzer，再执行go run . ./...，就能在标准输出看到所有违规的常量位置和提示信息。后续如果要集成到golangci-lint，只需依赖plugin模块的注册机制，编译成一个.so插件，就能被主工具直接调用。这种架构把通用性和定制化完美分开了：团队维护一个通用规则池，同时每个项目只编译自己需要的定制规则，既不臃肿也不缺失。

回到最初那个团队风格不统一的问题，其实解决方案的思路已经摆在眼前：不要指望一种工具能解决所有问题，也不要觉得定制的成本高不可攀。Go语言把解析代码的能力做成了标准库的一部分，我们花半小时写出的检查器也许只有一条规则，但它截住的那种“这次就这样吧，下次再改”的妥协，正是很多项目代码腐败的开始。从下划线常量起步，你完全可以把同样的模式套用在结构体字段顺序检查、特定包导入限制或者错误处理链验证上，一步一步把手动评审变成自动化守护，让团队的时间用在更值得的地方。