Go Modules是当前Golang包管理的标准方案，自Go 1.13起默认启用，集成于Go命令行中，通过go.mod和go.sum锁定依赖版本，支持语义化版本控制与最小版本选择策略，无需GOPATH限制，兼容现代项目结构。相比之下，dep曾为社区常用工具，但已于2019年归档，配置文件为Gopkg.toml和Gopkg.lock，存在性能与维护问题；govendor与glide属早期第三方方案，依赖本地vendor目录或YAML配置，现已停止维护，不适用于新项目。对于新项目应直接使用Go Modules，旧项目建议迁移到Go Modules，可通过golang-migrate/dep2mod等工具完成转换。企业内网可配置私有Module Proxy如Athens，构建环境可控场景可结合go mod vendor。总体而言，Go Modules已成为唯一推荐方向，支持完整生态与高效依赖管理。
Go语言在发展过程中经历了多种包管理方式的演变，从最初的
go get到如今模块化（Go Modules）成为主流，开发者在不同阶段面临不同的依赖管理工具选择。本文将对比几种主要的Golang包管理工具，帮助你根据项目需求做出合理选择。
1. Go Modules（官方推荐）
Go Modules 是自 Go 1.11 引入的官方依赖管理方案，从 Go 1.13 开始默认启用，已成为当前事实上的标准。
核心优势：
- 无需依赖外部工具，集成在 Go 命令行中
- 通过
go.mod
和go.sum
精确锁定依赖版本 - 支持语义化版本控制和最小版本选择（MVS）策略
- 可脱离
GOPATH
工作，项目结构更灵活 - 社区生态全面支持，如 proxy.golang.org 加速依赖拉取
对于新项目，强烈建议直接使用 Go Modules。初始化项目只需运行：
立即学习“go语言免费学习笔记（深入）”；
go mod init example.com/myproject
添加依赖时，
go get会自动更新
go.mod文件。
2. dep（已废弃）
dep 曾是社区广泛使用的实验性包管理工具，在 Go Modules 出现前填补了官方空白。
现状与问题：
- 项目已于 2019 年正式归档，不再维护
-
配置文件为
Gopkg.toml
和Gopkg.lock
- 存在解析性能差、规则复杂等问题
如果你还在维护旧项目使用
dep，建议尽早迁移到 Go Modules。官方提供了迁移工具
golang-migrate/dep2mod或手动执行
go mod init导入依赖。
3. govendor 与 glide（历史工具）
这两者属于更早期的第三方解决方案，功能类似但设计略有不同。
govendor 将依赖复制到本地
vendor/目录，强调“闭源构建”。
glide 使用
glide.yaml定义依赖，支持版本约束，曾被 Kubernetes 早期采用。
为什么不推荐：
- 均无持续维护，兼容性风险高
- 不支持现代 Go 的模块机制
- 增加项目体积，重复拷贝依赖
仅在维护非常老的 Go 1.5~1.8 项目时可能遇到，不建议新项目使用。
4. 如何选择合适的工具？
选择应基于项目阶段和团队环境：
- 启动新项目 → 使用 Go Modules，无需犹豫
- 维护旧项目使用 dep/glide → 制定迁移计划转为 Go Modules
- 企业内网无公网访问 → 配置私有 Go Module Proxy（如 Athens）
- 需要精细控制构建环境 → 结合
vendor
模式（go mod vendor
）
Go Modules 已足够稳定和强大，覆盖绝大多数使用场景。遇到代理问题可通过设置环境变量解决：
export GOPROXY=https://proxy.golang.org,direct export GOSUMDB=sum.golang.org
基本上就这些。Go 的包管理已经进入标准化时代，Go Modules 是唯一值得投入的方向。掌握它不仅提升开发效率，也便于融入现代 Go 生态。工具演进虽多，但现在的选择很清晰。
