Go modules是官方唯一推荐的依赖管理方式，自Go 1.11引入、1.16默认启用，取代GOPATH和第三方工具；项目根目录存在go.mod即启用modules，否则回退旧模式。
Go modules 是当前唯一推荐的依赖管理方式
Go 1.11 起官方内置 go mod，Go 1.16 默认启用，不再需要 dep、glide 等第三方工具。如果你还在用 GOPATH 模式或手动维护 vendor/，现在就该切换——否则 CI 构建会不稳定，不同环境依赖版本不一致的问题几乎必然发生。
关键判断：只要项目根目录下有 go.mod 文件，就表示已启用 modules；没有则默认走旧版 GOPATH 模式（即使设置了 GO111MODULE=on，也需显式初始化）。
-
go mod init是起点，模块名建议用可解析的域名（如github.com/yourname/project），否则本地replace或私有仓库导入会出问题 - 首次运行
go build或go test时，Go 会自动下载依赖并写入go.mod和go.sum，无需额外命令 - 不要手动编辑
go.mod中的require行来“升级版本”——这容易漏掉间接依赖或校验失败
如何安全更新依赖（包括主版本升级）
直接改 go.mod 或用 go get pkg@v1.2.3 看似快，但可能破坏构建：go.sum 校验失败、间接依赖冲突、测试不通过。正确做法是让 Go 工具链驱动整个过程。
- 更新单个包到最新补丁版：
go get example.com/pkg（不带版本），它会解析go.sum中已有约束，选兼容的最高小版本 - 升级到新主版本（如 v2→v3）：
go get example.com/pkg@v3.0.0，注意包路径必须含/v3后缀（Go 的语义化版本规则） - 批量更新所有依赖到允许的最新版：
go get -u；加-t同时更新测试依赖；但生产项目慎用，建议先在分支中验证 - 降级或回滚？删掉
go.mod中对应行，再运行go mod tidy，Go 会按现有代码引用重新计算最小可行版本
go mod tidy 不只是“整理依赖”，它决定构建确定性
go mod tidy 是日常维护中最常误用的命令。它不只是删除未使用的 require 行，还会补全缺失的间接依赖、同步 go.sum、检查校验和一致性——CI 流程中必须包含它，否则 go build 可能在某台机器上突然失败。
立即学习“go语言免费学习笔记（深入）”；
- 执行前确保当前目录是 module 根（有
go.mod），否则报错no go.mod file - 如果提示
found meta tag ... in ...，说明 Go 尝试从网页解析模块路径，大概率是私有仓库没配GOPRIVATE - CI 中建议加
go mod tidy -v并检查退出码；若输出含=>行（如example.com/pkg => ./local-pkg），说明存在replace，需确认是否应提交到主干 - 不要把
go.sum设为 ignore —— 它是防篡改的关键，缺失会导致go build拒绝下载
私有仓库和代理配置绕不开，但可以极简处理
公司内网 Git、GitHub 私有库、GitLab 自托管，都会触发 go get 失败。核心就两点：告诉 Go 哪些域名不走公共代理，以及如何认证。
- 跳过代理（如 GitHub 私有库）：
go env -w GOPRIVATE=git.example.com,github.com/myorg，多个用逗号分隔，支持通配符*（但不推荐） - 国内加速（非必需，但能省时间）：
go env -w GOPROXY=https://proxy.golang.org,direct，注意direct必须保留，否则私有库无法访问 - SSH 认证私有 Git：确保
~/.ssh/config中为对应 Host 配了IdentityFile，且git命令能正常 clone；Go 内部调用的就是系统git - 避免在
go.mod里硬编码replace指向本地路径——开发时方便，但会阻断 CI，改用GOPRIVATE+ SSH 更可持续
真正麻烦的不是配置本身，而是团队成员环境不一致：有人开了 GO111MODULE=off，有人忘了设 GOPRIVATE，结果本地能跑、CI 报 unknown revision。自动化管理的底线，是让 go mod download 在任意干净环境中都能成功。
