每次Go版本发布，开发者心里都悬着同一个问题：这次有没有不小心破坏用户的编译依赖？

一个PR看起来人畜无害。几行代码改动，一个类型迁移，某个方法开始返回error，某个结构体字段消失。提交历史干干净净，更新日志言之有理。

打开网易新闻 查看精彩图片

但用户根本不关心你的commit message。他们只关心一件事：你公开的Go API还能不能用。

这就是relimpact存在的意义。这个小巧快速的工具专门干一件事：对比两个Git引用，精准报告导出API的变化。

不是每份文件。不是每次提交。不是每行代码。只关注用户能导入、调用、实现或编译的公开API表面。

原始git diff适合检查实现细节。更新日志适合向人类解释发布内容。但回答"这两个引用之间哪些公开Go符号变了"这个问题，它们都不是最佳工具。

举个例子，发布前真正重要的是这种变化：

- func Load(path string) *Config
+ func Load(path string) (*Config, error)

这不是"改了一行"那么简单。这是破坏性API变更。

而这种变化有用但不破坏：

+ func FromEnv(prefix string) (*Config, error)

这是新增公开API。relimpact把这两类变化分得清清楚楚。

最终生成一份报告，PR里好 review，发版时好附注。

工具设计得极其克制。不取代git diff，不生成原始changelog，不总结提交，不关心两个引用之间有多少次提交。它只是在一个引用处快照导出API，在另一个引用处再快照一次，然后对比API表面。

报告基于引用之间的API变化，而非提交信息。这个区别很关键。混乱的提交历史可能产出干净的API报告。小小的提交也可能造成破坏性公开API变更。

Markdown报告专为PR评论设计。开头是简短的兼容性摘要，破坏性变更排在最前面。

还有HTML报告供CI产物和发版review，但Markdown通常是PR场景的最佳格式。

一份简单的GitHub Actions工作流就能跑起来：安装relimpact、生成Markdown报告、以置顶评论形式发到PR里。fetch-depth设0确保能拿到完整历史，Go 1.25环境，ubuntu-latest运行器，权限只开contents读和pull-requests写。

核心就一行安装命令：go install github.com/hashmap-kz/relimpact

对于维护公开库的团队，这工具把"有没有破坏API"从人工猜测变成了自动化检查。版本号语义化之前，先让机器把把关。