解释 Go 依赖版本变化
此捆绑工具需要 Go 1.22 或更高版本，并且对于 --base 选项需要 git。它会在每个版本上运行 go mod graph 和 go list -m -mod=readonly -json all，并设置 GOWORK=off。这些命令会读取模块及其依赖项的 go.mod 文件；它们不会构建或运行任何代码，也不会更改 go.mod 或 go.sum。
1. 选择两个版本
- 在拉取请求中，旧版本是合并基础：
git merge-base origin/main HEAD。仅当用户要求时才使用分支名称。 --base REF通过git archive读取该提交的go.mod和go.sum文件，因此工作树中未提交的更改将作为新版本。对两个检出版本，使用--old DIR --new DIR。- 在模块根目录（包含
go.mod的目录）中运行，或者传递--new MODULE_DIR。在包含多个模块的仓库中，每个go.mod发生变化的模块都要运行一次。
2. 运行
go run "${CLAUDE_PLUGIN_ROOT}/scripts/whybumped.go" --base "$(git merge-base origin/main HEAD)" --new MODULE_DIR
- 如果拉取请求说明了它意图更改的内容（例如 Dependabot 标题 "Bump google.golang.org/grpc from 1.63.2 to 1.67.1"），则通过
--expect google.golang.org/[email protected]传递。那么每个其他更改都是 WARN，包括go.mod自行升级的模块。 - 添加
--format json以解析结果。 - 依赖项必须存在于模块缓存中，或者可以通过环境中的模块代理下载。除非用户要求，否则不要更改
GOPROXY、GOFLAGS或GONOSUMDB。
退出码
0 表示没有 WARN（或使用了 --fail-on never）。1 表示至少有一个 WARN。2 表示结果不可信：某一方的 go.mod 缺失、为空、被截断、不是 go.mod 或没有 go 指令；go mod graph 或 go list -m 失败（通常是缺少 go.sum 条目、版本未知或没有网络）；它们的输出不一致；两方属于不同模块；某一方完全没有依赖项；或者 --base 引用不存在。将 2 视为未知，绝不能视为通过，并向用户显示错误。
报告
- 如果存在
go-raised，则首先介绍：旧的和新的 go 行，需要新版本的依赖项以及它如何进入依赖图。如果 go.mod 超过了任何依赖项所需，请说明。 - 按“通过...引入”行对模块更改进行分组：对于
go.mod要求的每个根模块，列出它升级或添加的内容。这些就是该升级的副作用。 requested更改是仅go.mod要求的版本。对于升级到超出任何依赖项所需的// indirect模块，说明它是手动升级或由go get -u升级的，并且如果用户希望进行更小的更改，它可以保持在所需的版本。lowered和removed更改说明哪个请求者曾经需要旧版本以及该请求者的去向。降级的模块是构建中的降级；直接说明。requirement-dropped意味着 go.mod 丢失了一行，而构建通过另一个模块保留了相同的版本。当没有包需要该模块时，go mod tidy会执行此操作。如果用户没有运行 tidy，请检查 go.mod 是否未损坏。- 通过未被选中的版本的依赖链是真实的：在最小版本选择中，图中每个版本的要求都算数，即使这些版本输给了更新的版本。
- 除非用户要求，否则不要编辑
go.mod。如果他们想要更小的更改，通常的修复方法是仅对根模块执行go get module@version，然后执行go mod tidy，并再次运行该工具。