Go 1.11起官方正式支持go mod，vendor是其可选输出而非替代方案；go mod负责依赖声明与版本解析，vendor用于离线构建和依赖锁定，二者协同工作。
Go 1.11 起官方正式支持 go mod，它已成为 Go 项目依赖管理的标准方式；vendor 目录则用于将依赖锁定并打包进项目本地，适合离线构建或严格控制依赖版本的场景。两者不是互斥关系——go mod 是依赖声明与版本解析的核心机制，vendor 是其可选输出结果。
启用 go mod 并初始化模块
在项目根目录下运行命令即可开启模块模式：
-
go mod init example.com/myproject—— 初始化go.mod文件（模块路径建议用实际域名或唯一标识） - 后续执行
go run、go build或go test时，Go 会自动记录新引入的依赖到go.mod，并下载到本地缓存（$GOPATH/pkg/mod） - 若项目已有
Gopkg.lock（dep 工具）或vendor/，go mod init会尝试迁移依赖信息
常用 go mod 命令与依赖操作
日常开发中高频使用的命令包括：
-
go mod tidy—— 清理未引用的依赖，添加缺失的依赖，同步go.mod和go.sum -
go get -u package@v1.2.3—— 升级指定依赖到某版本（-u表示更新次要版本） -
go mod vendor—— 将当前go.mod中所有依赖复制到vendor/目录（不改变go.mod） -
go list -m all—— 查看当前模块及所有依赖的版本列表 -
go mod verify—— 校验依赖哈希是否与go.sum一致，确保完整性
理解 vendor 目录的作用与使用时机
vendor 不是替代 go mod 的方案，而是补充手段：
立即学习“go语言免费学习笔记（深入）”；
- 当 CI/CD 环境无法访问公网代理（如公司内网），可通过
go mod vendor+go build -mod=vendor完全离线构建 -
go build -mod=vendor表示强制只读取vendor/下的代码，忽略go.mod中的远程路径和版本声明 - 注意：
vendor不会自动更新，每次依赖变更后需手动运行go mod vendor同步 - 建议将
vendor/提交进 Git，但需在.gitignore中排除vendor/modules.txt（该文件由 Go 自动生成，无需手动维护）
避免常见陷阱
实际使用中容易踩坑的地方：
-
不要混用 GOPATH 模式和 module 模式：确保环境变量
GO111MODULE=on（Go 1.16+ 默认开启），并在非$GOPATH/src下开发新项目 -
go.sum不可随意删除或修改：它是依赖包内容的校验和，删掉会导致go build失败或安全警告 - 私有仓库依赖需配置
replace或GOPRIVATE环境变量，否则go get可能因认证失败而中断 - 升级 major 版本（如 v2+）需在 import 路径末尾加上
/v2，且go.mod中模块名也需对应（语义化版本规范要求）
