go get 并不将依赖代码提交到你的 Git 仓库中，而是将其下载至 $GOPATH/src（旧式 GOPATH 模式）或模块缓存（Go Modules 模式），因此克隆项目后需重新运行 go get 或启用 vendoring 才能复现构建环境。本文厘清 go get 的底层行为、与 Git 的交互逻辑，并详解现代 Go 依赖可重现性的最佳实践。
`go get` 并不将依赖代码提交到你的 git 仓库中，而是将其下载至 `$gopath/src`（旧式 gopath 模式）或模块缓存（go modules 模式），因此克隆项目后需重新运行 `go get` 或启用 vendoring 才能复现构建环境。本文厘清 `go get` 的底层行为、与 git 的交互逻辑，并详解现代 go 依赖可重现性的最佳实践。
go get 的真实行为：下载 ≠ 提交
当你执行 go get github.com/gorilla/mux 时，Go 工具链实际执行的是一个隐式的 Git 克隆操作：
# 等价于（以 GOPATH 模式为例） cd $GOPATH/src/github.com/gorilla git clone https://github.com/gorilla/mux.git
该命令会：
- 在 $GOPATH/src/github.com/gorilla/mux/ 下创建完整 Git 仓库（含 .git/ 目录）；
- 解析其 go.mod（若存在）或源码 import 语句，递归拉取所有传递性依赖；
- 编译并安装包（如生成 *.a 文件或二进制）；
- 但绝不会将这些文件纳入你主项目的 Git 工作区。
因此，你 git commit 的仅是自己的源码（如 main.go、go.mod、go.sum），而 github.com/gorilla/mux 的源码仍留在 $GOPATH/src —— 这就是 teammate 克隆后“依赖缺失”的根本原因：依赖未随项目一同版本化，也非 submodule，而是独立存在于 Go 环境路径中。
⚠️ 注意：在 Go Modules 模式（Go 1.11+ 默认启用）下，go get 不再写入 $GOPATH/src，而是将依赖缓存在 $GOCACHE 和 $GOPATH/pkg/mod 中，并通过 go.mod 锁定版本。但关键一点不变：这些缓存路径不属于 Git 仓库，也不会被 git add 或 git commit 捕获。
为什么 Git 不感知 go get 下载的代码？
因为 go get 创建的是嵌套 Git 仓库（nested repositories）——每个依赖都是独立的 .git/ 目录。而 Git 默认采用 gitmodules 以外的机制处理子目录中的 .git：
- git status 忽略所有子目录下的 .git，视其为“外部仓库”，不跟踪其文件变更；
- git clone --recursive 仅递归初始化 .gitmodules 定义的子模块，对 go get 生成的目录完全无感；
- 这导致看似“下载了代码”，实则它们游离于 Git 版本控制之外，形成“不可重现的构建陷阱”。
正确的可重现方案：Modules + go mod vendor（推荐）
现代 Go 项目应弃用 GOPATH 模式，统一采用 Modules，并通过 go mod vendor 实现依赖锁定与本地化：
# 1. 初始化模块（若尚未启用） go mod init myproject # 2. 添加依赖（自动写入 go.mod/go.sum） go get github.com/gorilla/mux@v1.8.0 # 3. 将所有依赖复制到 vendor/ 目录（可提交至 Git） go mod vendor # 4. 强制构建使用 vendor/（确保离线/环境一致） go build -mod=vendor
✅ 优势：
- vendor/ 是普通目录，git add vendor/ && git commit 即可将精确版本的依赖源码完整纳入版本控制；
- go build -mod=vendor 优先从 vendor/ 加载，彻底绕过网络和远程仓库状态；
- go.sum 文件已提供校验和，go mod vendor 保证内容一致性；
- 无需第三方工具（如 godep、govendor），Go 原生命令开箱即用。
? 注意：go mod vendor 仅复制 go.mod 中声明的直接/间接依赖，不包含测试依赖（除非显式 go get）。建议配合 CI 流程验证 go mod vendor 后 go build -mod=vendor 能成功编译。
Bonus：何时需要“每次拉最新”？——CI/CD 与实验性开发场景
你提到的“强制每次拉取最新版”并非反模式，而适用于特定场景：
- 持续集成流水线：希望及时发现上游 Breaking Change，可在 CI 中禁用 vendor/，运行 go get -u ./... 更新依赖并跑全量测试；
- 原型/实验项目：快速验证新特性（如 github.com/golang/net@master），牺牲稳定性换取前沿功能；
- 工具链开发：如 CLI 工具依赖 urfave/cli/v3，需紧跟主干修复；
但务必明确：生产环境、发布版本、团队协作项目必须锁定依赖（通过 go.mod 版本号或 vendor/），避免“上周还能编译，今天失败”的灾难。
总结：三步建立可靠依赖工作流
| 步骤 | 命令 | 目的 |
|---|---|---|
| 1. 启用 Modules | go mod init example.com/myapp | 声明模块根，生成 go.mod |
| 2. 精确引入依赖 | go get github.com/sirupsen/logrus@v1.14.0 | 锁定具体版本，更新 go.sum |
| 3. 本地化交付 | go mod vendor && git add vendor/ go.mod go.sum && git commit | 构建可重现、可离线、可审计的代码快照 |
go get 本身不是问题——它是高效获取依赖的入口；真正的挑战在于如何让依赖状态成为 Git 历史的一部分。Modules + vendor/ 组合，正是 Go 社区历经多年演进后给出的优雅答案。
