go mod tidy不能代替发版依赖修剪，因为它仅做静态import分析，不识别构建标签、测试专用依赖、反射调用、embed引用等运行时或条件性依赖；发版需以目标命令为锚点，用go list -deps精确提取真实依赖并手动构建最小go.mod。
go mod tidy 为什么不能代替发版时的依赖修剪
它只做静态 import 分析，不考虑构建标签、测试专用依赖、反射调用或 embed 引用。发版时若直接拿开发态的 go.mod 打包，很可能带入大量“编译期不需要但存在 require 行”的模块——比如仅在 //go:build integration 下才启用的 client，或只用于 go:generate 的工具链依赖。
常见表现：go build -o bin/app ./cmd/app 能成功，但 go list -deps ./cmd/app | grep xxx 显示某模块根本没出现在依赖路径里，而它仍在 go.mod 中被 require —— 这就是发版前必须修剪的冗余。
- 仅被
*_test.go文件 import 的模块，默认不会进入主构建图 -
import _ "github.com/mattn/go-sqlite3"这类空白导入，若驱动未被实际注册（如没调用sql.Open），运行时也不需要 - 通过
reflect.Value.Call或配置文件名动态加载的包，go mod tidy完全不可见
用 go list -deps 精确提取目标命令的真实依赖
发版前应以最终构建目标为锚点，而非整个 module。例如你要发布 ./cmd/api，就该只保留它真正需要的依赖：
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./cmd/api | sort -u > deps-of-api.txt
这个命令输出的是所有非标准库的 import 路径（不含版本），比 go mod graph 更贴近实际编译行为，且自动跳过未启用构建 tag 的分支。
注意两点：
- 必须显式指定子目录（如
./cmd/api），否则./会包含测试和工具代码 - 输出不含版本号，需配合
go mod graph或go list -m all对照确认具体版本
手动构造最小 go.mod 的安全方式
别删完再补，而是从零开始收敛。步骤是：
- 备份原
go.mod，新建空go.mod并执行go mod init your.module.name - 把
deps-of-api.txt里的路径逐个go get path@version（版本号从原go.mod或go list -m all查） - 运行
go mod tidy -compat=1.21（按你发版目标 Go 版本设兼容性） - 最后执行
go build -o bin/api ./cmd/api和go test ./cmd/api验证
这样生成的 go.mod 几乎没有间接依赖残留。如果发现缺失，说明某个包确实被 runtime 依赖（比如 init 注册），那就得保留在 import 中——哪怕静态分析没抓到。
交叉编译和 vendor 场景下的陷阱
发版常要跨平台构建（GOOS=linux GOARCH=arm64 go build），而 go mod tidy 默认按当前环境分析。某些模块（如 golang.org/x/sys/unix）在 Windows 上不参与构建，但 Linux 发版时必须存在。
vendor 不是解药：运行 go mod vendor 会把 go.mod 全量拷进去，包括那些“发版不需要但开发需要”的模块。真要精简 vendor，必须先完成上一步的最小 go.mod 构建，再 go mod vendor。
容易被忽略的一点：如果你用了 replace 指向本地路径，发版时这些 replace 必须去掉或替换为真实 commit hash，否则 CI 构建会失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
