Go项目应避免用go get全局安装工具,而应在tools.go中声明构建时依赖并用go install@version安装,以解决版本冲突、CI不一致等问题。
Go 项目中不推荐用 go get 全局安装工具(如 golangci-lint、mockgen、swag),因为版本冲突、CI 环境不一致、本地重装后丢失等问题频发。正确做法是把工具声明为“仅构建时依赖”,用 tools.go 文件隔离管理。
全局安装的工具不受 go.mod 约束,无法锁定版本;不同项目可能需要不同版本的 golangci-lint,但 go get 只保留一份可执行文件;CI 流水线里若未预装,构建会失败;go install(Go 1.16+)虽支持 -modfile,但仍难统一多工具版本。
在项目根目录新建 tools.go,内容极简:只声明导入,不写任何逻辑,且必须用 // +build tools 构建约束标记(或 Go 1.17+ 的 //go:build tools)。这样 go mod tidy 不会把它当真实依赖,但 go list 和 IDE 仍能识别。
//go:build tools // +build tools package tools import ( _ "github.com/golangci/golangci-lint/cmd/golangci-lint" _ "github.com/golang/mock/mockgen" _ "github.com/swaggo/swag/cmd/swag" )
tools.go(约定俗成,部分工具链如 gopls 会自动识别)tools(不能是 main 或其他)_ 空导入,避免编译报错“imported and not used”//go:build tools,旧版需同时保留 // +build 
tools(双标记兼容)用 go install 显式指定模块路径和版本,安装到 $GOBIN(默认 $HOME/go/bin),而非修改 go.mod:
GO111MODULE=on go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.54.2
go mod tidy ——它不会处理 tools.go 中的导入tools.go 里的版本(如把 v1.54.2 换成 v1.55.0),再重新 go install
go install 步骤,而不是依赖缓存或预装make tools-install,内部调用上述命令最容易出问题的是构建约束没生效,导致 go mod tidy 把工具误加进 require;或者 IDE(如 VS Code + gopls)没识别 tools.go,提示 “command not found”。
go.mod:grep -A5 'github.com/golangci' go.mod —— 若出现,说明构建标记写错了或用了错误的 Go 版本golangci-lint --version,不是 go run github.com/...
"go.toolsGopath" 未被覆盖,且 $GOBIN 在 $PATH 中//go:build 不生效,必须用双标记;Go 1.21+ 已废弃 // +build,但双写仍安全真正麻烦的不是写 tools.go,而是让整个团队和 CI 都习惯用 go install @version 而非 go get —— 工具版本一旦散落各处,排查环境差异的成本远高于多敲几行命令。