go mod tidy 是 go 官方推荐的唯一可靠自动清理未使用依赖的方式，它基于 go.mod 与源码 import 的双向比对同步增删依赖，只删除既未被 import 引用、也非传递依赖且未显式声明的模块，并更新 go.sum。
编译时依赖注入 ≠ 代码注入，Go 没有运行时字节码插桩机制
Go 编译器（go build）在编译阶段只做静态链接：它把本地 vendor/ 或 $GOPATH/pkg/mod 中已下载的模块源码“复制粘贴式”地参与编译，不执行任何外部代码、不加载远程 DLL、也不动态解析 import 路径。所谓“注入”，只是开发者误用 replace 或镜像代理导致的源码替换，并非语言或工具链主动注入。
真正危险的是你手动改了 go.mod 里的 replace 指向恶意 fork，或者用了不受信的 GOPROXY （比如非官方镜像返回篡改过的 zip 包）——这时编译进去的，是别人给你塞的源码。
-
replace是显式覆盖，只要没写，就不会生效；但一旦写了，Go 就完全信任你指定的路径 -
GOPROXY=https://proxy.golang.org是默认且安全的，但若设成私有代理或direct，就可能绕过校验 -
go.sum文件记录每个模块的哈希值，每次go build都会校验，不匹配直接报错：verifying github.com/some/pkg@v1.2.0: checksum mismatch
如何确认当前编译用的是哪个版本的源码
别猜，直接查。Go 提供了三重验证路径：
- 看
go list -m -f '{{.Path}} {{.Version}} {{.Replace}}' all | grep your-dep—— 显示模块路径、解析出的版本、是否被replace替换 - 查
go mod graph | grep your-dep—— 看它被谁引入、是否有多版本共存 - 定位实际源码位置：
go list -m -f '{{.Dir}}' github.com/some/pkg，然后ls -la看修改时间与 git commit，比对原始仓库 tag
注意：go build -x 会打印所有编译参数和源文件路径，其中 -I 后面的路径就是实际参与编译的模块根目录 —— 这才是真相所在。
防范恶意依赖：从 go.mod 到 CI 流程的硬性卡点
仅靠开发者自觉不够，必须在流程上堵死。关键动作不是“怎么防”，而是“在哪卡”：
- CI 中强制运行
go mod verify，失败即中断构建；它会重新计算所有模块哈希并比对go.sum - 禁止在生产分支的
go.mod中出现replace—— 它该只存在于开发环境或临时调试分支 - 用
go list -json -m all导出依赖树，在 CI 中扫描已知高危包（如github.com/evil/pkg），匹配go.mod的require行 - 启用
GOSUMDB=off是自毁行为；正确做法是设GOSUMDB=sum.golang.org（默认），且不允许覆盖
一个容易被忽略的事实：go get 默认会更新 go.sum，但 go build 不会。如果你只跑 build 而跳过 mod tidy，旧的、已被撤回的恶意版本可能仍留在 go.sum 里“合法”存在。
第三方库源码被篡改后，Go 编译器根本不会提醒你
Go 编译器只校验 go.sum 哈希，不校验语法、不扫描后门、不检测 init() 函数里的可疑网络调用。它信任你提供的源码，就像信任你写的 main.go 一样。
这意味着：如果攻击者控制了你用的私有 proxy，或者你手动 replace 到一个带后门的 fork，编译产物就含毒 —— 而且 go build 日志里不会有一行警告。
最务实的做法，是把 go.sum 当作不可变契约，每次 PR 都要求 go mod tidy + git diff go.sum 人工复核变更项，尤其关注新增或版本跳变的模块。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
