Go 1.17起module graph pruning默认启用，它不删除go.mod中require行，而是让工具链在解析时跳过未参与当前构建路径的模块分支；go mod tidy本身不触发修剪，仅同步go.mod与导入图。
Go 1.17 起，go mod tidy 默认启用 module 依赖图修剪（module graph pruning），但它不是“自动删掉所有没用的 require 行”——它只修剪那些**既未被 import、也不参与构建路径的模块节点**。关键判断依据是：该模块是否出现在当前构建标签启用的导入图中。
什么是 module graph pruning？
它不是删除 go.mod 中某一行那么简单，而是让 Go 工具链在解析依赖时，跳过那些“存在但不参与编译”的模块分支。比如：
- 模块
a的package x被 main 导入，而它的package y没被任何代码引用 -
package y又依赖模块c，但c对 main 的构建毫无贡献 - 在 Go 1.16 及以前，只要
c找不到，go build就会失败；Go 1.17+ 则直接忽略它
这种“忽略”就是修剪——c 仍可能保留在 go.mod 的 require 列表里（尤其当它是 a 的 // indirect 依赖），但不会被加载、校验或参与版本选择。
go mod tidy 不会修剪的情况
修剪只发生在模块图解析阶段，go mod tidy 本身不触发修剪逻辑，它只是同步 go.mod 与当前导入图。以下情况它不会删掉模块：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
require行被显式标记为// indirect，且该模块仍是某个已保留依赖的传递依赖 - 模块被
//go:build条件编译块引用（如//go:build ignore或_test.go文件中的 import）——tidy默认扫描所有构建标签启用的代码，但若你用GOOS=js go mod tidy，它就只看 js 兼容部分 - 模块出现在
replace中，即使本地路径下没有对应 import，tidy也不会删它（因为 replace 优先级高于 import 是否存在）
如何验证是否发生了修剪？
最直接的方式是对比 go mod graph 输出的变化：
- 执行
go mod graph | wc -l，记录边数 - 删掉某个疑似冗余模块的
replace或注释掉对应 import 后再运行go mod tidy - 再次执行
go mod graph | wc -l，如果边数减少，说明该模块之前虽在图中，但属于可修剪分支
注意：go list -m all 显示的是“被解析出的模块”，不等于“参与构建的模块”。真正反映修剪效果的是 go build -x 日志里是否还出现对那个模块的 load 或 download 动作。
容易被忽略的细节
修剪行为依赖 Go 版本和构建配置，不是一劳永逸的：
- Go 1.17+ 默认开启，但如果你项目
go.mod声明的go 1.16，某些修剪逻辑可能不生效 - CI 环境若未统一 Go 版本，同一份代码在本地能成功构建，在 CI 却报
unknown revision，很可能是修剪未触发导致工具链尝试加载本该被跳过的模块 -
go mod verify仍会检查所有go.sum中记录的模块，哪怕它们已被修剪——所以go.sum不会因修剪而自动变小
