Go项目不依赖Git构建，但go mod深度集成Git；go get失败而git clone成功因前者默认HTTPS且不复用Git凭据；需配置GOPRIVATE或.gitconfig的insteadOf规则；vendor/通常不提交，仅CI无网时例外；本地replace应配合git submodule而非相对路径；模块路径必须与远程仓库地址严格一致。
Go 项目本身不依赖 Git 进行构建或运行，但 go mod 默认从 Git 仓库拉取依赖，且 Go 工具链深度集成 Git —— 所以「用 Git 管理 Go 开发环境」本质是管好 go.mod、依赖来源、本地开发分支策略和 GOPATH/GOPROXY 配置，而不是像 Java/Maven 那样靠 Git 控制构建流程。
为什么 go get 会失败，而 git clone 成功？
常见现象：go get github.com/some/private/repo@v1.2.0 报 unauthorized: authentication required，但手动 git clone https://github.com/some/private/repo 能正常走 SSH 或 token 认证。
原因在于：go get 默认使用 HTTPS 协议拉取模块，且不复用 Git 的 credential helper；它只认 ~/.netrc 或 GIT_AUTH_TOKEN（仅限部分代理），不读 ~/.gitconfig 中的 [url "git@github.com:"] 重写规则。
- 临时解决：设置
GOPRIVATE=github.com/some/private，让 Go 跳过 checksum 验证并允许走 SSH - 长期方案：在
~/.gitconfig中添加 URL 重写，并确保go命令能触发 Git：[url "git@github.com:"] insteadOf = https://github.com/
- 验证是否生效：
go list -m github.com/some/private/repo应该能解析出版本，而非卡住或报错
go mod vendor 后 Git 提交哪些文件？
执行 go mod vendor 会生成 vendor/ 目录，但不是所有内容都该提交 —— 关键看是否启用 GO111MODULE=on 和团队协作约束。
立即学习“go语言免费学习笔记（深入）”；
- 必须提交：
go.mod和go.sum—— 它们是模块依赖的唯一可信源 - 通常不提交：
vendor/—— Go 官方推荐「不提交 vendor」，因为go build默认从go.mod拉取，且vendor/易与go.sum不一致 - 例外情况：CI 环境无外网、或依赖私有 Git 服务器不可靠时，才提交
vendor/；此时需go mod vendor -v验证完整性，并在.gitignore中显式取消忽略：!vendor/ !vendor/**/*
如何让本地修改的依赖被 Git 正确追踪？
当你 go mod edit -replace 指向本地路径（如 github.com/foo/bar=../bar），go build 会读取本地代码，但 Git 默认不会把 ../bar 当作子模块管理 —— 导致协作者拉代码后直接编译失败。
- 不要用相对路径 replace：它无法被 Git 复现，且
go mod tidy可能自动清除 - 正确做法：用
git submodule add将依赖仓库作为子模块嵌入：git submodule add git@github.com:foo/bar.git vendor/github.com/foo/bar
- 然后 replace 指向子模块路径：
go mod edit -replace github.com/foo/bar=./vendor/github.com/foo/bar - 协作者需执行
git submodule update --init才能同步依赖代码
Git 对 Go 项目最常被忽略的一点：模块路径（module github.com/user/project）必须与仓库远程地址严格匹配，否则 go get 会拒绝解析。哪怕只是少了个 v1 后缀，或用了 gitlab.com 却写成 github.com，都会导致依赖无法加载 —— 这个校验发生在 Git fetch 之前，所以错误信息里甚至看不到 Git 相关字样。
