Go项目依赖版本控制核心是go.mod+go.sum文件，Git仅托管不参与解析；私有仓库需配置GOPRIVATE和URL重写，模块版本由go.mod内容、时间戳及哈希算法共同决定。
Go 项目依赖版本控制的核心不是 Git，而是 go.mod 文件 + go.sum 文件；Git 只负责托管它们，不参与依赖解析或版本锁定。
为什么不能靠 Git tag 或 branch 直接管理依赖版本
Go 的模块系统（从 Go 1.11 起默认启用）通过 go.mod 显式声明依赖的精确版本（如 v1.2.3），而非靠 git checkout v1.2.3 手动切换。Go 工具链会自动下载对应 commit 的归档（.zip），并校验 go.sum 中的哈希值。直接改 Git 分支名、打新 tag 却不更新 go.mod，会导致本地 go build 仍用旧版本——Git 变了，但 Go 不认。
-
go get github.com/some/pkg@main会写入go.mod为github.com/some/pkg v0.0.0-20240501123456-abc123def456（伪版本），不是main分支本身 - 手动编辑
go.mod中的版本字符串后，必须运行go mod tidy才真正生效 - Git submodule 或 subtree 方案在 Go 模块时代已过时，且破坏
go list -m all的可预测性
go mod vendor 和 Git 提交的关系
go mod vendor 把依赖代码复制到 vendor/ 目录，但它只是可选优化——Go 官方不推荐常规提交 vendor/ 到 Git，除非你有离线构建、审计或确定性 CI 的强需求。现代 Go 项目更依赖 go.mod + go.sum 的组合来保证可重现构建。
- 若决定提交
vendor/，需确保go mod vendor后git add vendor/，且后续go get后重新生成并提交 -
go.sum必须提交，否则不同机器go build可能因 checksum 不匹配失败（错误信息：checksum mismatch） - CI 中禁用 vendor（即不运行
go mod vendor）时，需确保GO111MODULE=on且网络可达 proxy.golang.org 或私有 proxy
私有仓库依赖如何让 go mod 正确识别 Git 版本
Go 默认通过 HTTPS 克隆模块，但私有 Git 仓库（如 GitHub Enterprise、GitLab Self-Hosted）常需配置 GOPRIVATE 和 Git URL 重写规则，否则 go get 会尝试走公共 proxy，导致 403 或 timeout。
立即学习“go语言免费学习笔记（深入）”；
- 设置
GOPRIVATE=git.example.com/*（支持通配符），避免 Go 将私有域名转发给 proxy - 若私有仓库用 SSH 地址（
git@git.example.com:user/repo.git），需在~/.gitconfig中配置[url "git@git.example.com:"] insteadOf = https://git.example.com/ - 在
go.mod中声明依赖时，module path 必须与仓库根路径一致（例如git.example.com/user/repo），否则go mod download找不到对应 commit - 使用
go get git.example.com/user/repo@v1.0.0后，检查go.mod是否写入了正确路径和语义化版本，而非伪版本
真正容易被忽略的是：Go 模块版本号不是 Git tag 名的简单映射，而是由模块根目录下的 go.mod 文件内容、commit 时间戳、以及 Go 工具链的哈希算法共同决定的。一个 tag 对应多个伪版本、或同一 commit 被不同 Go 版本解析出不同伪版本，都是可能的。所以别猜，用 go list -m -versions github.com/user/pkg 查真实可用版本，用 go mod graph | grep pkg 看实际加载路径。
