Go 1.16+ 默认启用 go mod，初始化模块需运行 go mod init example.com/myapp 生成 go.mod，再执行 go mod tidy 确保依赖准确；私有库需配置 GOPRIVATE，go.sum 变动属正常但应统一 Go 版本与环境。
Go 1.16+ 默认启用 go mod，不再需要 GOPATH；如果你还在用 go get 直接拉包而没初始化模块，大概率会遇到版本混乱、require 缺失或 indirect 依赖失控的问题。
如何初始化一个 Go 模块并正确声明依赖
新项目第一步不是写代码，而是运行 go mod init example.com/myapp —— 这会生成 go.mod 文件，并把当前路径注册为模块根。注意：模块路径不一定要能访问，但必须全局唯一（尤其对私有库），否则后续 go get 或 CI 构建时可能解析错版本。
后续所有依赖都会自动写入 go.mod，但前提是代码里真实 import 了该包。常见错误是手动编辑 go.mod 添加 require 行却不 import，这会导致 go build 忽略它，且 go mod tidy 会把它删掉。
-
go mod init后立即执行go mod tidy，清理冗余、补全缺失、降级间接依赖 - 如果项目要引用本地未发布的模块，用
replace重定向：replace example.com/other => ../other - 避免在
go.mod中硬编码// indirect依赖，它们应由go mod graph或go list -m all自动推导
为什么 go get 会升级不该升级的依赖
go get 默认行为已从“拉最新 commit”变为“拉最新兼容版本”，但具体逻辑取决于参数：
立即学习“go语言免费学习笔记（深入）”；
-
go get pkg@latest：取主版本号相同下的最高语义化版本（如 v1.12.3 → v1.15.0） -
go get pkg@master：取默认分支 HEAD，绕过语义化约束，易引入破坏性变更 -
go get pkg@v1.10.0：锁定指定版本，但若该版本不存在于 proxy 或本地 cache，会报unknown revision
真正安全的做法是：先改代码 import 并调用新 API，再运行 go mod tidy —— 它只升级满足当前 import 需求的最小版本，不会盲目升主版本。
私有仓库依赖拉取失败的典型原因与解法
错误信息如 module github.com/private/repo: reading github.com/private/repo/@v/v0.1.0.mod: 404 Not Found，本质是 Go 默认走 proxy.golang.org，而私有库不在其索引中。
解决方式不是关 proxy（影响公共包），而是精准配置：
- 设置
GOPRIVATE=github.com/private/*，让 Go 跳过 proxy 和 checksum 验证 - 若用 SSH 地址（
git@github.com:private/repo.git），需确保~/.gitconfig里配了对应 host 的url重写规则 - 企业内网场景下，可搭配
GONOSUMDB和自建athensproxy，但必须同步维护私有模块的go.sum条目
go.sum 文件被频繁修改？你可能忽略了校验机制
go.sum 不是锁文件，而是每个依赖模块的校验和快照。只要 go.mod 变更、或 go mod download 拉到新版本，它就可能更新 —— 这是正常行为。但频繁变动往往说明：
- 多人协作时混用了不同 Go 版本（如 1.19 vs 1.21），导致 checksum 计算方式微异
- CI 环境未设
GO111MODULE=on，导致部分步骤 fallback 到 GOPATH 模式，漏写校验和 - 误删了
go.sum后直接go build，Go 会重建它，但内容可能与团队其他成员不一致
建议在 CI 脚本开头固定 go version，并始终用 go mod verify 检查一致性；不要把 go.sum 当作可选文件忽略。
