本文系统解析 go get 的底层行为机制，阐明其与 Git 仓库的交互本质，指出传统 go get 导致依赖不可复现的根本原因，并重点介绍现代 Go 模块（Go Modules）下的标准化 vendoring 方案（如 go mod vendor），帮助开发者构建可重现、可版本锁定、可离线构建的稳健项目。
本文系统解析 `go get` 的底层行为机制，阐明其与 git 仓库的交互本质，指出传统 `go get` 导致依赖不可复现的根本原因，并重点介绍现代 go 模块（go modules）下的标准化 vendoring 方案（如 `go mod vendor`），帮助开发者构建可重现、可版本锁定、可离线构建的稳健项目。
go get 究竟做了什么？——不是“复制”，而是“克隆到 GOPATH”
当你执行 go get github.com/sirupsen/logrus，Go 工具链并不会将代码直接写入你的项目目录，而是按以下逻辑操作：
- 解析导入路径：识别 github.com/sirupsen/logrus 对应的 Git 仓库地址（通常为 https://github.com/sirupsen/logrus.git）；
- 克隆到 $GOPATH/src/：在 $GOPATH/src/github.com/sirupsen/logrus 下执行 git clone，完整保留 .git 目录；
- 构建并安装：编译该包（如有 main），并将生成的 .a 文件或二进制放入 $GOPATH/pkg/ 或 $GOBIN。
这意味着：你的项目源码中根本不存在依赖代码——它只存在于全局 $GOPATH 中。因此，你 git commit 时，Git 根本看不到这些文件（它们不在项目工作区），队友 git clone 后自然也无法运行 go build，除非他本地也执行 go get。
⚠️ 这正是你遇到问题的根源：go get 创建的是全局共享、非项目内嵌、无版本快照的依赖，与 Git 子模块（.gitmodules）的精确 commit 锁定形成鲜明对比。
为什么 Git 不跟踪 go get 下载的依赖？——“双重 Git”困境
当依赖被克隆至 $GOPATH/src，其内部包含完整的 .git 目录。若你曾尝试将 $GOPATH 设置为项目子目录（如 ./src），再 go get，就会出现典型的 “双重 Git”（double-git）困境：
- 主项目根目录有 .git/（父仓库）；
- 依赖目录下也有 .git/（子仓库）；
- Git 默认忽略所有嵌套 .git 目录及其内容 —— 即使物理路径在项目内，也不会被 git add 或 git commit 纳入版本控制。
结果是：你看似“把依赖放进了项目”，实则 Git 完全无视它，构建完全依赖网络与远程仓库状态，严重损害可重现性（reproducibility）。
现代解法：Go Modules + go mod vendor（推荐方案）
自 Go 1.11 起，Go Modules 成为官方标准依赖模型，彻底取代 $GOPATH 依赖管理模式。它通过 go.mod 和 go.sum 文件实现声明式、可锁定、可验证的依赖管理。
✅ 正确初始化与使用流程如下：
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
# 1. 初始化模块（自动创建 go.mod） go mod init example.com/myapp # 2. 获取依赖（自动写入 go.mod & go.sum） go get github.com/gin-gonic/gin@v1.9.1 # 3. 【关键】将所有依赖复制到项目内 vendor/ 目录（可复现构建核心） go mod vendor # 4. 提交 vendor/ 目录到 Git（含全部依赖源码） git add go.mod go.sum vendor/ git commit -m "vendor dependencies for reproducible build"
此时，vendor/ 目录成为项目的一部分，结构如下：
myapp/ ├── go.mod ├── go.sum ├── vendor/ │ └── github.com/ │ └── gin-gonic/ │ └── gin/ │ ├── gin.go │ └── ... ├── main.go └── .git/
构建时，Go 默认优先从 vendor/ 加载依赖（无需额外标志），确保：
- 构建完全离线可用；
- 依赖版本与 go.sum 严格一致，杜绝“幽灵更新”；
- 团队成员 git clone 后直接 go build，零配置、零歧义。
补充说明：关于“为何要每次拉最新版”？——场景与权衡
你提出的 Bonus 问题极具洞察力。确实，刻意不锁定依赖、每次拉取最新版在特定场景下是合理策略：
- ✅ 工具类 CLI 开发：如 linter、generator（golangci-lint, swag）。使用 go install 安装到 $GOBIN，追求最新特性与修复，无需版本固化；
- ✅ 内部 SDK 快速迭代：多个服务共用一个内部基础库，且该库采用语义化发布+强制 CI 向后兼容，上游团队可主动推送 breaking change 并通知下游升级；
- ✅ PoC 或脚本项目：生命周期短、无长期维护需求，牺牲稳定性换取开发效率。
但请注意：生产级应用、API 服务、基础设施组件必须锁定依赖。go get -u 或无版本约束的 go get github.com/xxx 应仅用于开发调试，绝不可出现在 CI/CD 或 release 流程中。
总结：三步构建可靠 Go 项目依赖体系
| 步骤 | 操作 | 目标 |
|---|---|---|
| ① 启用 Modules | go mod init <module-path> | 告别 $GOPATH，启用版本感知 |
| ② 精确获取依赖 | go get path@vX.Y.Z 或 go get path@commit | 避免隐式 latest，写入 go.mod/go.sum |
| ③ 固化至项目 | go mod vendor && git add vendor/ | 实现 100% 可重现构建，消除网络与上游变更风险 |
? 最佳实践提示：
- 禁用 GO111MODULE=off，始终在模块模式下工作；
- 在 CI 中添加 go mod verify 校验依赖完整性；
- 使用 go list -m all 审计依赖树，go mod graph 分析冲突；
- 避免手动编辑 go.mod，一切依赖变更均通过 go get / go mod tidy 维护。
从此，你不再需要解释“为什么队友跑不起来”——因为 vendor/ 就是答案。
