go mod tidy 默认按最小版本选择算法升级依赖，要锁定版本需显式用 replace 或修改 require 并运行 go mod tidy；replace 私有模块时需确保 go.sum 有对应校验和，CI 中需配置 GOPROXY 和 SSH。
go mod tidy 会自动升级依赖，怎么阻止它回退不到想要的版本
默认情况下 go mod tidy 不会“降级”已有依赖，但它会根据 go.mod 中声明的最小版本要求（require）和模块的 go.sum 快照，拉取满足条件的最新兼容版本——这常导致你本地用着 v1.2.3，运行 go mod tidy 后变成 v1.2.5。这不是“回退”，而是“意外升级”。真要锁定旧版本，必须显式覆盖。
- 在
go.mod中用replace强制指定路径和 commit 或 tag：replace github.com/some/pkg => github.com/some/pkg v1.2.3
- 或直接修改
require行并加// indirect注释不顶用，必须配合go mod edit -require或手动编辑后运行go mod download - 执行
go mod vendor后再go mod tidy可能触发重新解析，建议先go mod graph | grep pkgname确认谁在间接拉高版本
使用 replace 替换私有模块时，为什么 go build 报错 missing go.sum entry
replace 只改路径/版本，不自动更新校验和。如果替换目标是私有 Git 仓库或本地路径，go.sum 里没有对应条目，go build 就会失败。
- 确保
replace指向的模块本身可被go list -m识别（即含go.mod文件） - 运行
go mod download -x查看实际 fetch 的 URL 和 hash 计算过程 - 手动补全
go.sum：先go mod download github.com/your/private@v0.1.0，再检查是否生成对应行；若仍缺失，可临时删掉go.sum并重跑go mod tidy - 注意：用本地路径替换（如
./local/pkg）时，go.sum不记录 hash，但要求该目录下go.mod存在且版本为latest或显式module github.com/xxx v0.1.0
go get -u 升级后想回退到某 commit，但 go mod why 显示无引用
go get -u 会升级直接和间接依赖，有时某个旧 commit 实际已被其他模块“带进来”，但 go mod why 查不到，是因为该版本未出现在最终依赖图中——可能被更高版本覆盖，或只存在于缓存未写入 go.mod。
- 先查真实依赖树：
go list -m all | grep pkgname，确认当前解析出的版本 - 强制指定版本并下载：
go get github.com/some/pkg@3a7f2e1（commit hash），再go mod tidy - 如果该 commit 没打 tag，Go 默认不信任其版本号，需配合
-dirty或改用replace指向本地 clone 目录 - 注意：
go get后若没修改go.mod，下次go mod tidy可能又清掉它——务必确认require行已持久化
CI 环境中 go mod download 失败，提示 version not found，但本地能切
常见于私有模块或企业 proxy 缓存了过期索引。本地因有 module cache 或 GOPROXY=direct 生效，而 CI 使用默认 GOPROXY=https://proxy.golang.org,direct，可能无法访问内部仓库。
- CI 中显式设置
GOPROXY：比如export GOPROXY="https://goproxy.io,https://proxy.golang.org,direct"，并在前面加上公司镜像 - 若用
replace指向 Git SSH 路径（如git@git.company.com:pkg），CI 需配置 SSH key，并设GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no" - 避免在
go.mod中写死不可达的 commit —— 可用go mod edit -replace在 CI 步骤中动态注入，而非提交到代码库
go list -m all 的输出，比反复 go mod tidy 更有效。
