Go 1.17+ 引入模块依赖图剪枝，go mod graph 输出完整可达图，而构建时仅加载实际被 import 路径引用的依赖子树；未被任何编译路径导入的包（如 module A 的未使用 package y 及其依赖 module C）会被静态剪枝，不再参与构建或校验。
go mod graph 显示的依赖，为什么 build 时不真正加载？
因为 Go 1.17+ 引入了模块依赖图剪枝（module graph pruning），go mod graph 输出的是“完整可达图”，而构建时只加载**实际被 import 路径引用到的包所触发的依赖子树**。比如 module A 有两个包：x 和 y，你的 main 只 import A/x，即使 A/y 依赖 module C，只要 C 没被任何已编译路径实际导入，它就不会参与构建。
这和旧版本（Go ≤ 1.16）行为完全不同：那时只要 go.mod 里出现 require C v1.0.0 // indirect，哪怕完全没用到，go build 就会检查 C 是否存在、go.sum 是否匹配，否则直接报错：
go: example.com/a@v0.1.0 requires example.com/c@v0.1.0: missing go.sum entry
- 剪枝不是“忽略”，而是按 import 图做静态可达性分析
-
go list -m all在 Go 1.17+ 默认也只显示剪枝后的有效模块（加-deps才能看到全图） - 剪枝发生在
go build、go test、go run等所有构建命令中，不是可选开关
哪些依赖会被剪掉？关键看 import 路径是否真实存在
剪枝判断依据是：从主模块的 main 包开始，沿着所有 import 语句递归展开，只保留能被实际 import 字符串解析到的 package 所引入的依赖。以下情况会被剪掉：
-
module A的package y未被任何已编译代码 import，哪怕它在A里定义了，也不算 -
replace或exclude规则指向的模块，若其内容未被 import，同样不加载 - 测试专用依赖（如
_test后缀包里的 import）在非go test场景下不参与主构建图 -
build tag排除的文件中 import 的包，不会触发对应依赖加载
注意：indirect 标记本身不决定是否剪枝——它只是说明该依赖没被主模块直接 import，但只要某条 import 链最终经过它，就不会被剪。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
go build 时如何验证剪枝是否生效？
最直接的方式是故意删掉一个“理论上间接但实际未使用”的模块，然后运行 go build：
- 删掉
$GOPATH/pkg/mod/cache/download/example.com/c/@v/v1.0.0.zip（或清空整个 module cache） - 确保项目里没有任何地方 import
example.com/c或其子包 - 执行
go build ./...—— 如果成功，说明该模块已被剪枝；失败则说明仍有隐式引用
也可用 go list -f '{{.Deps}}' ./... 查看每个包的实际依赖列表，比 go mod graph 更贴近构建真实视图。如果某个模块没出现在任何 .Deps 中，它大概率就是被剪掉的。
剪枝对 go.sum 和 vendor 有影响吗？
有，但方式不同：
-
go.sum文件仍保留所有出现在go mod graph中的模块校验和（包括被剪枝的），因为go.sum记录的是“曾经解析过的依赖”，不是“本次构建用到的依赖” -
go mod vendor默认只 vendoring 剪枝后实际用到的依赖（Go 1.17+ 行为），不会把indirect但未使用的模块拉进vendor/ - 若需强制包含某模块（比如为 future import 预加载），可用
go get example.com/c显式添加到require，或写个 dummy import（不推荐）
真正容易被忽略的是：剪枝让 go mod tidy 的行为更保守——它现在只清理“既没被 import、也没被 require 显式声明”的模块，不再盲目删除所有 indirect 条目。
