Go 1.17+ 引入 module graph pruning，会修剪未被构建路径实际使用的模块分支；只要某模块的包未被任何 import 直接或间接引用，该模块及其子依赖就不参与构建、下载或校验，但可能仍显示在 go mod graph 中。
go mod graph 显示的依赖为什么会被修剪？
因为 Go 1.17+ 的 module graph pruning（依赖图修剪）机制会主动忽略那些“未被构建路径实际使用”的模块分支。它不是 bug，而是设计行为：只要某个模块的某个 package 没被任何 import 语句直接或间接引用到当前构建目标中，该模块及其子依赖就不会参与构建，也不会被 go build 或 go test 加载。
典型场景是 multi-package module：比如 module a 同时提供 package x 和 package y，而你的代码只 import "a/x"，那么即使 a/y 依赖了 module c，c 也不会进入构建图 —— 即使 go mod graph 仍显示它，go build 也完全不关心它是否存在。
- 修剪发生在构建阶段，不是
go mod tidy阶段；tidy只管go.mod与import的一致性，不管 runtime 是否真用得上 - 被修剪的模块不会触发下载、校验或编译，但它们仍保留在
go.mod中（除非你手动删或tidy判定为 unused） -
go list -m all默认列出所有出现在go.mod中的模块（含被修剪的），加-f '{{if .Indirect}} {{.Path}} {{end}}'可筛选出真正未被引用的
module graph pruning 会影响 go.sum 吗？
不影响。被修剪的模块如果已在 go.sum 中，其 checksum 条目依然保留；如果从未被加载过，它根本不会写入 go.sum —— 因为 go.sum 记录的是“实际下载并参与构建的模块”的哈希值，不是 go.mod 的镜像。
这意味着：即使你 require 了一个庞大 module（比如 github.com/xxx/biglib），只要代码里没 import 它的任何包，它的所有子依赖都不会出现在 go.sum 中，也不会占用校验开销。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
go mod verify只检查当前构建图中实际用到的模块，被修剪的模块不参与验证 - 如果你用
go mod download手动拉取整个go.mod，那些被修剪的模块也会被下载并写入go.sum—— 这是显式动作，和自动修剪无关 - CI 构建时若出现 checksum mismatch，优先查是否有人手动改了
go.sum或误用了go mod download -json等命令，而不是怀疑修剪机制
如何确认某个 module 是否真的被修剪了？
最可靠的方法是观察构建过程是否触发它的下载和编译。运行 go build -x ./...（带详细日志），搜索输出中是否有该 module 路径的 cd 或 compile 行；没有，基本就是被修剪了。
更轻量的方式是结合两个命令：
-
go list -f '{{.Deps}}' ./... | grep 'target-module'—— 查看它是否出现在任何包的直接依赖列表中 -
go mod graph | grep 'target-module' | grep -v '=>'—— 如果只出现在右侧（被依赖方），且左侧无当前模块路径，说明它只是图中悬空节点，大概率被修剪 - 临时删掉它的
require行，再跑go build；如果不报错，证明它确实未被使用（注意：这一步要小心，别删掉间接但必要的依赖）
replace 规则会绕过依赖修剪吗？
不会绕过，但会改变修剪边界。replace 只影响“模块路径解析”，不改变“导入图分析”。也就是说，如果你 replace github.com/a => ./local/a，而 ./local/a 里有未被引用的 package，它照样被修剪。
真正容易踩坑的是：replace 后本地模块的 go.mod 里可能声明了额外依赖（比如 require github.com/c v1.0.0），而这些依赖在主模块中又没被 import —— 它们会被修剪，但你可能误以为“既然 replace 了，就该全量生效”。
- 修剪始终以主模块的
import语句为起点，逐层向下展开；replace 只是把某条边的终点从远程换成本地路径 - 本地被 replace 的模块如果自身有未使用的
require，那些模块不会自动进主模块的go.mod，也不会进构建图 - 调试时建议用
go list -m all看实际解析路径，确认 replace 是否生效，再用-x看构建行为
go mod tidy 是两套逻辑，一个管构建时的加载路径，一个管声明文件的整洁度；混用这两个概念，就会误判“为什么这个 require 还在，却没效果”。 
