Go mod与go get使用最佳实践：如何区分生产与开发依赖？

核心结论 #

你没有过度纠结，Go 官方早已提供了规范方案来区分生产依赖和开发工具依赖，不需要在你提到的两个不合理方案中二选一。

开发工具依赖的标准处理方案 #

从 Go 1.14 开始，社区普遍采用 tools.go 模式管理开发类工具依赖，完美解决「依赖需要版本管理但不能进入生产构建」的需求：

• 在项目根目录新建 tools/tools.go 文件，写入以下内容：

//go:build tools
// +build tools

package tools

// 导入所有开发环节需要的工具依赖，比如lint、代码生成工具等
import (
	_ "github.com/golangci/golangci-lint/cmd/golangci-lint"
	_ "honnef.co/go/tools/cmd/staticcheck"
)

• 执行 go mod tidy，这些工具依赖会被自动加入 go.mod 和 go.sum 做版本统一管理
• 由于文件顶部加了 //go:build tools 构建标签，生产构建时Go编译器会自动忽略该文件，这些依赖绝对不会被编译到生产二进制包中，完全不会影响生产发布的依赖列表

vendor 同步问题的处理 #

如果你所在的团队必须使用 vendor 模式，不存在「两条命令更新依赖不合理」的问题，这属于Go依赖管理的标准操作：

• 你可以把 go mod tidy && go mod vendor 封装到Makefile的一个目标中，示例配置：

deps:
	go mod tidy
	go mod vendor

• 后续不管是新增生产依赖还是开发工具依赖，只需要执行 make deps 即可，自动完成 go.mod 更新和 vendor/modules.txt 同步，完全不需要手动执行两条命令

流水线环节的优化建议 #

• 如果没有强制要求维护vendor目录，流水线可以直接弃用vendor模式，执行 go mod download 拉取所有依赖即可，从根源上避免 modules.txt 不同步的问题
• 所有lint、测试工具直接从项目依赖启动，比如执行 go run github.com/golangci/golangci-lint/cmd/golangci-lint run，保证本地和流水线使用的工具版本完全一致，避免出现本地检查通过、流水线拦截的问题
• 不要全局安装任何项目相关的工具，所有工具版本都通过 go.mod 统一管控

内容的提问来源于stack exchange，提问作者Djoby