go mod tidy 不会清理 go.sum 中的孤儿条目，因其设计上保留历史哈希以防范包篡改风险；这些残留条目虽不影响构建，但会增大文件、拖慢 CI 和引发误报；安全清理需手动比对 go list -m all 与 go.sum 中的模块名差集。
go mod tidy 为什么会让 go.sum 越来越大
因为 go mod tidy 不会自动清理 go.sum 中的“孤儿条目”——那些曾经被依赖过、但当前 go.mod 已彻底移除的模块版本，其校验和仍顽固留在 go.sum 里。这不是 bug，是设计：Go 保留历史哈希是为了防止“某天突然换源导致下载到篡改包”的风险，但它确实会让 go.sum 膨胀、git diff 变长、CI 检查变慢。
- 执行
go mod tidy后go.sum增加了几十行？大概率是旧间接依赖残留，比如你之前用过github.com/some/lib v1.0.0，后来升级到v2.0.0，但v1.0.0的哈希没被删 -
go.sum不影响构建或运行，但会影响可审计性——安全扫描工具（如govulncheck）可能对已下线的旧版本误报 - 它不等于“冗余依赖”，别和
go.mod里的// indirect混淆：后者是当前仍被需要的传递依赖，前者是纯历史快照
如何安全清理 go.sum 中的孤儿条目
没有一键命令，但有可靠手动流程。核心原则：只删那些在 go.mod 和当前所有构建变体中都完全找不到引用路径的条目。
- 先确保依赖干净：运行
go build ./（覆盖默认构建标签）+go build -tags=dev ./（如有自定义 tag）+go test ./，再跑一遍go mod tidy - 生成当前实际依赖列表：
go list -m all | cut -d' ' -f1，这输出的是此刻真正参与构建的所有模块路径 - 提取
go.sum中所有模块名：awk '{print $1}' go.sum | sort -u - 对比二者差集：用
comm -13 找出只在 <code>go.sum出现的模块名 - 逐个确认后，用
go mod edit -dropsum=module@version删除（例如：go mod edit -dropsum=golang.org/x/net@v0.18.0）
哪些情况不能删，否则会构建失败
删错 go.sum 条目不会让 go build 报错，但可能让后续 go mod download 或 CI 环境拉不到包——尤其当模块代理不可靠或私有仓库权限受限时。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果你用了
replace或exclude，对应被替换/排除模块的原始版本哈希必须保留，否则 Go 无法验证替换来源的完整性 - 任何带
+incompatible后缀的条目，代表非语义化版本（如 commit hash），删掉后下次go get可能拉到不同 commit - 私有模块（如
git.internal.company/foo）的哈希一旦删除，又没配置好 GOPROXY，本地构建可能卡在 “verifying …”
长期减少 go.sum 膨胀的实操习惯
与其频繁清理，不如从源头控制增长节奏。重点不是“删得更狠”，而是“引得更准”。
立即学习“go语言免费学习笔记（深入）”；
- 避免无意义的
go get：不要直接go get github.com/xxx/yyy，而要用go get github.com/xxx/yyy@v1.2.0锁定最小必要版本 - 拆分子 module：HTTP server、CLI 工具、migration 脚本分属不同
go.mod，各自go.sum就互不污染 - 定期运行
go mod graph | grep 'unwanted'+go mod why -m unwanted/module，搞清一个间接依赖到底是谁带进来的，再决定是否要升级/替换上游 - CI 中加检查：
git diff --exit-code go.sum配合go mod tidy -v日志，快速发现意外引入
最常被忽略的一点：go.sum 的“多”，往往不是 tidy 太懒，而是项目长期没做构建变体覆盖（比如忘了 -tags=integration），导致 tidy 始终看不到某些条件依赖的真实状态——它以为那些模块还活着，就一直留着它们的哈希。
