Go项目应避免用go get全局安装工具，而应在tools.go中声明构建时依赖并用go install@version安装，以解决版本冲突、CI不一致等问题。
Go 项目中不推荐用 go get 全局安装工具（如 golangci-lint、mockgen、swag），因为版本冲突、CI 环境不一致、本地重装后丢失等问题频发。正确做法是把工具声明为“仅构建时依赖”，用 tools.go 文件隔离管理。
为什么不能直接 go get -u github.com/golangci/lint
全局安装的工具不受 go.mod 约束，无法锁定版本；不同项目可能需要不同版本的 golangci-lint，但 go get 只保留一份可执行文件；CI 流水线里若未预装，构建会失败；go install（Go 1.16+）虽支持 -modfile，但仍难统一多工具版本。
tools.go 文件怎么写
在项目根目录新建 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 1.17+ 推荐用
//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 - CI 中建议加
go install步骤，而不是依赖缓存或预装 - 若用 Makefile，可封装为
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/... - VS Code 中确保
"go.toolsGopath"未被覆盖，且$GOBIN在$PATH中 - 如果项目用 Go 1.16，
//go:build不生效，必须用双标记；Go 1.21+ 已废弃// +build，但双写仍安全
真正麻烦的不是写 tools.go，而是让整个团队和 CI 都习惯用 go install @version 而非 go get —— 工具版本一旦散落各处，排查环境差异的成本远高于多敲几行命令。
