Go 模块 graph pruning 后为什么 go mod graph 变短

graph pruning 后 go mod graph 变短，通常是因为模块要求图不再展开一部分无须参与当前版本选择的传递要求。少的是图中的部分 require 边，不等于源码依赖被随意删除，也不能直接推导二进制变小。主模块与依赖的 go 指令、实际 go.mod 内容以及命令上下文，都影响看到的图。

官方文档：https://go.dev/ref/mod

问题：图变短了，是不是漏掉了依赖？

不应仅按行数判断。go mod graph 描述模块版本之间的最低版本要求，每行表达一条关系；它不是某个 main 包的完整编译文件清单。一条模块节点的传递要求被裁剪，不代表该节点没有选中版本或从此不可使用。

裁剪机制从 Go 1.17 对应的模块语义开始发挥作用。较完整的主模块 require 声明，为所需依赖提供版本信息，从而减少对无关传递关系的展开。结果可能是 go.mod 中 indirect 声明更多，而图中的深层关系更少，这两种现象并不冲突。

常见误区：图中的边不是最终编译的包

同一个模块路径可能在要求图中带有不同版本，这些要求共同参与版本选择，不能把每个 path@version 都解释成最终同时编译的多份依赖。比较行数前，先确认比较的到底是边、模块还是包。

正确理解：裁剪与延迟加载解决不同问题

裁剪决定模块要求图需要保留哪些关系；延迟加载则使工具在尚不需要完整图时，避免立即加载它。两者相互配合，但不能简单说成“只是命令懒得显示”。go mod graph 本身就是观察要求图的工具，图中关系减少应按裁剪规则和实际声明解释。

裁剪也不是按“业务源码有没有直接 import”把所有 indirect 依赖删掉。传递提供包的模块仍可能需要稳定版本。擅自清空 indirect 区域，只为让 go.mod 更短，可能导致工具重新补回声明或报告不一致。

正确做法：先保存上下文，再按问题查看

下面命令是读者在项目内观察的示例，本文没有在本地执行它们。将示例目标路径和模块路径换成项目实际值，不要把示例名称当成存在的依赖。

# 记录工具链、模块文件与工作区上下文，避免比较不同项目视图
go version
go env GOMOD GOWORK

# 分别保存要求边与所选模块；两份文件的行数不能直接互相比较
go mod graph > module-edges.txt
go list -m all > selected-modules.txt

# 将路径替换成真实目标包与待解释的模块
go list -deps ./cmd/service
go mod why -m example.com/library

如果是迁移前后比较，应连同 go.mod 的 go 指令、require 及 replace 变动一起看。只安装新工具链，与同时修改模块声明并整理依赖，不是同一种操作。优先找出消失的是哪一类要求边，再判断是否符合所用规则。

go mod graph 的 -go=version 可以按指定 Go 版本的图加载语义报告，但它不会启动那个历史编译器，也不是回滚项目的方式。含较新最低版本要求的项目，未必允许拿任意旧版本作为比较条件；不要把参数被拒绝误认为网络故障。

边界情况：相同命令也需要相同环境

老依赖可能仍要求保留更完整的传递闭包。因此主模块启用裁剪后，不能预期所有依赖的图都同幅度缩小。若某模块还被较旧语义的依赖链要求，其关系仍可能需要展开。

工作区 go.work 和主模块模式也可能给出不同根集合，replace 会影响实际采用的模块内容。若两台机器的图不同，先对齐这些条件，再查看依赖变动。不要为了获得更短输出而降级模块要求或移除替换配置。

图变短，是否就能证明下载量减少？

不能直接证明。图边数量、实际下载请求和本地缓存命中是不同指标，不能用一项代替另一项。

为什么 go.mod 更长了，graph 却更短？

更显式的所需模块声明，能够支持减少无关传递关系的展开；文件长度与图规模没有固定同步关系。

是否应运行 tidy 来恢复旧图？

tidy 的用途是让声明与源码需求一致，不是还原旧的边数量。执行前应明确目标并审阅它带来的声明变化。

参考：模块图裁剪与延迟加载；go mod graph 命令定义。