go 1.11 起，官方模块（go modules）成为标准化、可复现的依赖管理方案，取代 gopath 和第三方工具；它支持语义化版本控制、本地缓存、校验机制与跨环境构建一致性。
在 Go 早期生态中，依赖管理长期处于“无官方方案”状态：go get 默认拉取主干最新代码（通常是 master 分支），导致构建不可复现——同一份代码在不同时间构建，可能因上游变更而行为不一致。为解决该问题，社区曾涌现 godep、glide、dep 等工具，但均属临时性补充，直至 Go 1.11（2018年8月）正式引入模块（Modules），标志着 Go 依赖管理进入原生、稳定、标准化阶段。
✅ 正确做法：启用 Go Modules
只需在项目根目录执行：
go mod init example.com/myproject
Go 会自动生成 go.mod 文件，记录模块路径与初始依赖。后续运行 go build、go test 或 go run 时，Go 工具链自动识别模块模式（无需设置 GO111MODULE=on —— Go 1.16+ 默认启用），并按以下规则解析依赖：
- 所有导入路径直接解析为模块版本，而非 GOPATH 下的源码；
- 依赖版本明确写入 go.mod（如 github.com/sirupsen/logrus v1.9.3）；
- 实际依赖代码缓存在 $GOPATH/pkg/mod，通过内容哈希隔离不同版本；
- 构建时自动校验 go.sum 中的模块哈希值，确保完整性与可重现性。
示例 go.mod 片段：
module example.com/myproject
go 1.21
require (
github.com/sirupsen/logrus v1.9.3
golang.org/x/net v0.14.0
)
replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.9.0? 注意：replace 用于临时覆盖依赖（如调试 fork 分支），仅影响当前模块；exclude 可显式排除特定版本（较少使用）。
⚠️ 历史方案对比（已淘汰/不推荐）
- godep（2015年前主流）：将依赖复制到 Godeps/_workspace 并修改 GOPATH，需用 godep go build 替代原生命令，破坏工具链一致性，且不支持版本范围。
- glide / dep：虽支持 vendor/ 目录与版本约束，但仍需额外命令（如 glide install），且未被 Go 官方集成，已于 Go 1.11 后停止维护。
- Go 1.5 vendor 实验（GO15VENDOREXPERIMENT=1）：首次引入 vendor/ 目录机制，但无版本声明能力，仅解决“快照”问题，无法指定 v1.2.0 还是 v1.2.1。
? 最佳实践建议
- 新项目一律使用 go mod init 初始化，禁用 GOPATH 模式（设 GO111MODULE=on 强制启用）；
- 提交 go.mod 和 go.sum 到版本库，禁止提交 vendor/ 目录（除非 CI 明确要求离线构建）；
- 升级依赖时使用 go get package@version（如 go get github.com/google/uuid@v1.3.0），Go 自动更新 go.mod 并下载对应版本；
- 定期运行 go mod tidy 清理未使用依赖、补全缺失项，保持模块文件整洁；
- 生产构建推荐加 -mod=readonly 标志（如 go build -mod=readonly），防止意外修改 go.mod。
Go Modules 不仅解决了“构建不可复现”的核心痛点，更通过轻量设计（无中心仓库、无复杂锁文件、纯文本配置）契合 Go “少即是多”的哲学。如今，它已是 Go 生态的事实标准——拥抱模块，就是拥抱现代 Go 开发的确定性与可维护性。
