本文介绍如何避免 go get 将第三方包下载到全局 GOPATH/src 目录，推荐使用 Go Modules（Go 1.11+ 默认机制）替代旧式 vendor 手动管理，实现项目级依赖隔离与可重现构建。

本文介绍如何避免 `go get` 将第三方包下载到全局 `gopath/src` 目录，推荐使用 go modules（go 1.11+ 默认机制）替代旧式 `vendor` 手动管理，实现项目级依赖隔离与可重现构建。

在 Go 1.11 之前，开发者常依赖 GOPATH 工作区模型，go get 会将所有外部包统一下载至 $GOPATH/src/...，导致个人代码（src/your-project）与第三方包混杂，违背“源码分离”原则。但自 Go 1.11 起，Go Modules 已成为官方推荐且默认启用的标准依赖管理机制，它完全解耦了依赖存储与项目路径。

✅ 正确做法：启用 Go Modules
确保你使用的是 Go 1.11+（推荐 1.19+），并在项目根目录初始化模块：

# 进入你的项目目录（无需在 GOPATH 内）
cd /path/to/your/project

# 初始化模块（生成 go.mod 文件）
go mod init example.com/your-project

# 现在安装依赖 —— 不再写入 GOPATH/src！
go get github.com/go-zoo/bone

执行后，Go 会：

• 自动在项目根目录生成 go.mod（声明模块路径与依赖版本）；
• 在项目内创建 go.sum（校验依赖完整性）；
• 所有依赖包缓存于 $GOPATH/pkg/mod（只读缓存区），而非 src/；
• 构建时直接从模块缓存加载，完全不依赖 src 目录结构。

⚠️ 注意事项：

• 不要手动创建 src/vendor/ 并复制包——这是过时的 vendor 模式（类似早期 npm node_modules），易引发版本冲突、难以审计；
• 若需锁定依赖到本地（如离线构建），可用 go mod vendor 生成 vendor/ 目录，但仅作为构建辅助，不应手动维护；
• 工具如 govend 或 trash 已被 Go Modules 原生能力取代，不再推荐引入额外复杂度。

? 总结：
GOPATH/src 仅用于存放你的模块源码（当未启用 Modules 时）；而现代 Go 项目应始终以 go mod init 开启 Modules，并将 src/ 专用于自身代码——依赖由 go.mod 声明、由模块缓存管理，干净、可靠、可复现。