有些 bug 能通过编译、通过测试、躲过代码审查，最后在生产环境悄然爆发。本文要讨论的正是这类问题：数据库事务边界泄漏。工程师 Léon H. 在一次线上事故后，选择自己动手写一个 linter 来从根本上解决这类缺陷。这个过程值得所有 Go 开发者参考。
问题本质：事务操作泄漏
在 Go 后端服务中，使用回调模式管理事务是常见做法。以 Gorm 为例，典型的代码结构如下：在一个事务回调中获取事务作用域的 repository（通常命名为 tx），所有数据库操作都必须通过它执行，以保证原子性。然而开发者经常在重构时漏掉某处调用，仍然使用外层的 s.repo 而不是 tx，导致操作实际上跑在了事务之外。
这种错误的可怕之处在于它几乎无法被传统测试发现。代码能够编译，单元测试在隔离环境下通过，只有在生产环境高并发时才会触发数据不一致或竞态条件。更糟糕的是，失败往往是静默的数据损坏，而非程序崩溃，排查难度极高。Léon 在经历多次漫长的调试会话后，意识到必须从工具链层面解决。
为什么静态分析是正确答案
事务泄漏本质上是一个结构性问题，与运行时行为无关。它只关心代码引用了哪个变量 —— 是 s.repo 还是 tx。这类模式完全可以通过源码静态分析检测，不依赖任何运行时信息。go/analysis 框架正是为这类场景设计的，它提供了标准化的 Analyzer 接口，封装了 AST 解析、类型检查和诊断报告的复杂性。
具体来说，这个框架的核心是 analysis.Analyzer 类型。开发者只需定义分析逻辑，框架负责处理解析和遍历。依赖其他分析器（比如 inspect.Analyzer 用于优化的 AST 遍历）可以通过 Requires 字段声明。这种组合式设计让单个分析器可以复用已有的基础设施，同时也便于与 golangci-lint 集成。
核心实现：四步检测逻辑
整个 linter 的实现围绕四个关键步骤展开，每一步都有明确的工程参数可供参考。
第一步是定位事务调用。分析器使用 inspector.Preorder 仅遍历 *ast.CallExpr 节点，大幅减少不必要的 AST 访问。具体判断逻辑是：检查该调用是否为选择器表达式、方法名为 Transaction、接收者是 repository 接口。这部分逻辑需要根据实际项目中的接口名称和包路径进行适配。
第二步是提取事务参数。回调函数的第一个参数即为事务作用域的 repository。这里使用 Go 类型系统的 types.Object 做身份比较而非字符串匹配，因为变量名可能被遮蔽（shadowing）。当两个标识符指向同一个变量时，它们的 types.Object 是全等的，这提供了可靠的追踪基础。
第三步是遍历回调体检测两类违规。第一类是方法调用使用了外层 repository：检测选择器表达式的接收者是否是 repository 接口且不是事务参数。第二类更隐蔽 —— 将外层 repository 作为参数传给辅助函数：当函数调用中存在 repository 类型的实参，且该实参不是事务参数时，即触发警告。
第四步是递归分析辅助函数。仅有调用站点的检查是不够的，因为缺陷可能嵌套在多层函数调用中。当检测到事务参数被传给某个辅助函数时，linter 需要递归进入该函数内部，将传入的参数视为新的事务参数继续分析。为防止无限循环，需要维护一个已访问函数的集合，确保每个函数在同一次事务分析中仅被检查一次。
集成与运行参数
实现完成后，需要决定运行方式。由于这个 linter 高度依赖特定项目的接口定义（repository 接口名称、包路径），不适合作为通用工具发布。最实用的做法是使用 singlechecker 封装为独立可执行文件，然后在项目中通过任务运行器（如 mise）调用。
典型的集成配置如下：先构建 linter 可执行文件，然后通过 bin/transactioncheck ./... 扫描整个代码库。在 CI 流水线中，将 linter 检查放在 golangci-lint 之后执行，确保新引入的违规会直接导致构建失败。从实际效果看，Léon 在首次运行这个 linter 时在代码库中发现了多个真实的潜在 bug，其中虽无金融相关服务，但风险是真实存在的。
关于测试，go/analysis 生态提供了 analysistest 包。测试用例写在 testdata/src/transactioncheck 目录下，使用特殊的 // want 注释声明期望的诊断信息。框架会自动验证带注释的行是否产生了匹配的警告，以及不带注释的行是否保持静默，从而同时排除假阳性和假阴性。
可复用的工程参数
基于这个实践，以下参数可作为类似项目的起点：AST 遍历时仅关注 *ast.CallExpr 和 *ast.SelectorExpr 节点，避免全量遍历；使用 types.Object 而非变量名做参数追踪，防止误报；递归分析时设置函数访问集合上限（如 100 个）防止异常情况下的性能问题；linter 执行超时建议设置为代码库规模的线性时间，单次扫描超过 30 秒需考虑优化或分片。
这个 linter 的维护成本极低。自首次运行至今几乎没有额外改动，因为它检测的是代码结构而非业务逻辑。只要项目的事务管理接口不改变，linter 规则就能持续生效。这正是自定义 linter 的核心价值：用一次性投入换取长期的自动化保障。
如果团队中反复出现某类模式错误，且这些错误具有明显的结构性特征（如本文的变量引用问题），自行编写一个专用 linter 往往是投入产出比最高的解决方案。它不要求深入的形式化证明技术，却能在 CI 阶段就拦截掉潜在的事故。
资料来源：本文核心实现细节参考自 Léon H. 的技术博客文章《I shipped a transaction bug, so I built a linter》（leonh.fr/posts/go-transaction-linter/），该文详细记录了从事故根因到 linter 实现的完整过程。