go mod tidy仅删除既未被任何.go文件import语句引用、也未被其他已保留模块间接依赖的模块；它无法识别反射调用、配置驱动、测试专用、构建标签保护或空白导入无副作用等情况，需人工用go mod why等验证。
Go 项目里残留的旧依赖不会报错，但会让构建变慢、go list -m all 输出膨胀、交叉编译失败、甚至在 CI 中因 go.sum 校验不一致而中断。真正安全的清理，不是只跑一遍 go mod tidy 就完事。
go mod tidy 到底删了什么？哪些它根本看不见
go mod tidy 只基于静态 import 分析做裁剪：它会删掉既没出现在任何 .go 文件的 import 语句中、也没被其他保留模块间接依赖的模块。但它对以下情况完全无感：
- 通过
reflect.Value.Call或plugin.Open动态加载的包（比如插件系统、配置驱动的 handler） - 仅在测试文件中使用的依赖，且没加
-test参数运行go mod why -
import _ "github.com/lib/pq"这类空白导入——若该包没注册init()，或注册了但没被其他代码触发，tidy就当它不存在 - 被
//go:build integration等构建标签保护的 import，在默认构建下不生效，tidy默认忽略 - 注释掉的
// import "net/http"—— 不算引用，对应模块可能被误删
怎么确认一个模块真能删？别信 go.mod，要看依赖路径
直接看 go.mod 里有没有 require 行是误导性的。真正可靠的方式是用 go mod why 查它实际如何进入依赖图：
-
go mod why golang.org/x/sync→ 显示从main到该模块的完整引用链 -
go mod why -m golang.org/x/sync -test→ 加-test才能暴露仅被测试文件引用的情况 - 输出是
(main module does not need module)，才是可删的明确信号 - 如果路径里含
vendor/或internal/子目录，说明它被子模块显式 require，根目录跑tidy不会动它
清理后必须验证的三件事，缺一不可
删完不验证 = 白删，尤其容易在非主构建路径上翻车：
-
go build ./...→ 要带...，确保cmd/下所有子命令、internal/里的工具都参与编译 -
go test ./...→ 测试可能引入独立依赖，且go mod tidy默认不处理_test.go的 import，必须手动验证 -
go list -m all | wc -l对比前后数字；再跑go mod graph | grep your-module-name确认它是否真的从图中消失
目录重构时依赖容易断的两个关键点
把包从 pkg/foo 搬到 internal/foo 或拆出新模块，不只是改 import 路径那么简单：
- 如果旧路径被其他模块
require，直接删会导致下游构建失败——得先用replace做兼容过渡：replace github.com/you/project/pkg/foo => ./internal/foo - 跨模块调用时，若新模块没导出接口（首字母小写），或没定义
go.mod，调用方会报cannot load错误；新模块必须有独立go.mod且路径与仓库 URL 一致
清理和重构的本质不是“删代码”，而是让依赖关系显性化、可验证、可追溯。每次 go mod tidy 后，多花 30 秒跑 go mod why 和 go test，比后期排查 CI 失败省十倍时间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
