Go依赖版本由go.mod的require行与go.sum校验和共同锁定；改import路径或硬编码无效，必须通过go get @vX.Y.Z、go mod edit -require配合go mod tidy等模块系统流程操作。
Go 依赖版本不是靠手动写死在代码里，而是由 go.mod 中的 require 行 + go.sum 校验和共同锁定的；直接改 import 路径或硬编码版本号没用，必须走模块系统流程。
怎么让 go get 真正拉到你想要的版本
很多人执行 go get github.com/some/lib@v1.2.3 后发现 go.mod 里写的还是 v1.3.0，甚至根本没变——这是因为 go get 默认行为是“升级到满足当前 import 的最小兼容版本”，不是“精确覆盖”。
- 确认你要的 tag 确实存在：用
curl -I https://proxy.golang.org/github.com/some/lib/@v/v1.2.3.info检查 HTTP 状态码是否为 200 - 如果 tag 存在但没生效，可能是已有更高主版本（比如
v2.0.0+incompatible）阻断了降级，此时需强制指定 commit：go get github.com/some/lib@abc123def - 更稳妥的做法是绕过自动解析：用
go mod edit -require=github.com/some/lib@v1.2.3手动写入，再跑go mod tidy - 避免用
@latest：它不等于最新 tag，而是 MVS 算法选出的最高 patch 版本，可能跳过预发布或带 breaking change 的版本
go.mod 里版本号的三种写法，效果完全不同
Go 只认特定格式的版本字符串，其他写法会被忽略或转成伪版本。常见错误是把 Git 分支名、裸 commit hash 直接塞进 require 行。
-
v1.2.3：必须对应真实存在的 Git tag（且带v前缀），否则 go build 会 fallback 到伪版本 -
v0.0.0-20240501123456-abc123def456：伪版本，由 Go 自动生成，含时间戳和 commit hash；手动写极易出错，不建议 -
master或main：不推荐。Go 会拉 HEAD，完全绕过 SemVer，CI 构建结果不可预测
为什么 go.sum 必须提交，且不能随便删
go.sum 不是锁文件，是每个模块版本的 SHA256 校验快照。每次 go build 都会校验下载内容是否匹配——它才是构建一致性的最终依据。
立即学习“go语言免费学习笔记（深入）”；
- Git 忽略
go.sum→ 不同机器拉代码后go build可能拉到被篡改或缓存污染的包，报checksum mismatch - CI 中执行
go mod download后提交生成的go.sum→ 开发者本地go mod tidy会重写它，导致校验失败 - 手动编辑
go.sum→ 下次go mod tidy会覆盖，且破坏完整性验证逻辑 - 正确做法：开发者运行
go mod tidy后，把生成的go.mod和go.sum一起提交
私有库或 fork 的版本控制要额外配置
默认情况下，go get 对私有域名（如 git.internal.company.com）会走 proxy.golang.org，直接 403 或 timeout，根本不会尝试 Git 协议。
- 必须设置
GOPRIVATE=git.internal.company.com/*，告诉 Go “这些不走 proxy” - 若用 SSH 地址（
git@git.internal.company.com:user/repo.git），还要在~/.gitconfig加[url "git@git.internal.company.com:"] insteadOf = https://git.internal.company.com/ -
replace指令只能临时替换，比如本地调试：replace github.com/some/lib => ./local-fix；生产环境禁止用replace替代真实版本号 -
module path必须与仓库根路径完全一致，比如git.internal.company.com/group/repo，否则go mod download找不到对应 commit
最容易被忽略的是：版本控制的有效性不取决于 Git tag 是否打了，而取决于 go.mod 里写的版本号是否被 go.sum 正确校验；一次没提交 go.sum，就可能让整个团队的构建失去可重现性。
