go mod tidy 不清除本地开发痕迹，因为它只维护依赖图完整性，不修改手动编辑的 replace 等配置行；这些需人工识别删除并执行 go mod tidy 恢复正确版本。
为什么 go mod tidy 不能清除本地开发痕迹
go mod tidy 只处理依赖图的完整性：拉取缺失模块、删掉未引用的依赖，但它完全不碰 go.mod 里那些被手动改写过的行——比如你为调试临时加的 replace、指向本地路径的 replace ./mymodule => ../mymodule，或者用 require mylib v1.2.3 // indirect 这类注释标记的“非直接依赖”。这些都会原样保留在发布包里，导致别人 go build 失败或行为不一致。
真正要清理的，是人手干预留下的“脏标记”，不是依赖本身。
-
replace指向本地路径（如replace github.com/user/pkg => /home/user/pkg）必须删除 -
// indirect注释可保留，但若它出现在require行末且对应模块实际已被移除，说明依赖图已过期，需先go mod tidy再检查 -
exclude和replace块都属于“发布前必须人工审核”的配置项，不能靠自动化跳过
如何安全识别并删除所有本地 replace 行
别靠肉眼扫 go.mod——容易漏。用 grep 直接定位最可靠：
grep -n "^replace " go.mod
输出类似：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
12:replace github.com/example/lib => ../lib 45:replace golang.org/x/net => /tmp/x/net
这些全是危险信号。逐条确认：只要右边是绝对路径（/ 开头）或相对路径（../ 或 ./ 开头），一律删掉；只有右边是标准版本号（如 v0.12.3）或公共仓库 URL（如 https://github.com/...@v1.0.0）才可能保留（通常也不建议在发布版中用 replace）。
- 删完后立刻运行
go mod tidy，让 Go 自动恢复正确版本 - 如果删掉某条
replace后go build报错 “missing required module”，说明该模块本应通过require显式声明，而不是靠本地替换绕过——此时应补上go get正确版本 - 注意 Windows 路径（
C:path omod）同样属于本地痕迹，必须清理
go mod vendor 会把本地路径带进去吗
会，而且很隐蔽。go mod vendor 默认把 go.mod 中所有 replace 指向的本地路径内容复制进 vendor/，但不会警告你——它只管“能 vendoring 出来就行”。结果就是：你的 vendor/ 里混进了开发机上的私有代码副本，CI 构建时却因路径不存在而失败。
- 执行
go mod vendor前，必须确保go.mod里没有本地replace - 检查
vendor/modules.txt：搜索=>符号，凡右侧含/或的行，都是残留痕迹 - 更保险的做法：清空
vendor/，删掉所有replace，再跑go mod vendor
CI 流水线里怎么自动拦截本地配置
不能只靠人眼检查。在 CI 的构建步骤开头加一行校验：
! grep -q "=> .*[/\]" go.mod && ! grep -q "^replace.*[[:space:]]+.[/\]" go.mod
这条命令的意思是：“如果 go.mod 里存在 => 后跟路径分隔符，或者 replace 行末尾跟着 ./ 或 ../，就返回非零退出码，让构建失败”。
- 把它放在
go build或go test之前，作为硬性门禁 - 不要用
go list -m all检查，它不显示replace映射关系，无法发现路径污染 - 如果你用
goreleaser，它的build阶段默认不校验go.mod内容，得额外加beforehook
真正的麻烦往往不在代码逻辑，而在那一行没人想起要删的 replace——它安静地躺在 go.mod 第 37 行，直到发布后第一通报警电话打进来。
