go项目依赖稳定性取决于go.mod中require行是否精确、可复现、不被绕过；生产环境必须写死语义化版本（如v1.9.1），禁用@latest；伪版本（v0.0.0-...）不可靠；go mod tidy仅基于import同步依赖；go.sum不可删、不可忽略，是构建可重现的底线；模块路径、goprivate配置须与仓库url严格一致。
Go 项目依赖是否稳定，不取决于你写了多少 go get，而取决于 go.mod 里那几行 require 是否精确、可复现、不被绕过。
go.mod 中的版本号写死还是用 @latest？
生产环境必须写死语义化版本，比如 v1.9.1；@latest 是 CI 脚本或临时调试用的，不是部署依据。
-
go get github.com/gin-gonic/gin@latest会拉取远程最新 tag，但可能跳过中间 patch 版本，也可能拉到未充分测试的 minor 版本 - 写死版本后，
go build永远下载同一 commit 归档（由go.sum校验），不会因远程 tag 变动而改变行为 - 如果依赖库没打正规 tag（只有
main或dev分支），go get会生成伪版本如v0.0.0-20240501123456-abc123def456，这种版本不可靠，应避免出现在生产go.mod
go mod tidy 不是“一键清理”，它依赖 import 语句存在
go mod tidy 只删掉 go.mod 里没有被任何 import 引用的 require 项，不会主动补全间接依赖——除非你先运行 go build 或 go test 触发完整依赖分析。
- 只改了
go.mod手动删行，不运行go mod tidy→ 下次go build可能报错找不到包 - 新增了
import "github.com/some/pkg"但没运行任何 Go 命令 →go.mod不更新，CI 构建直接失败 - 想强制刷新所有间接依赖？先
go build ./...再go mod tidy，而不是只靠tidy
go.sum 文件不能删、不能 ignore、不能靠 “信任” 绕过
go.sum 是构建可重现性的底线。它记录每个模块版本对应的校验和，一旦不匹配，go build 直接中止并报错：verifying github.com/xxx@v1.2.3: checksum mismatch。
- Git 提交时漏掉
go.sum→ 团队成员首次go build必然失败 - 手动编辑
go.sum→ 下次go mod download会覆盖你的修改，且可能引入不一致 - 临时禁用校验（如设
GOSUMDB=off）→ 仅限离线调试，绝不能进 CI 或提交记录
私有模块路径写错，go get 会静默 fallback 到 proxy
当 go get git.example.com/team/lib@v1.3.0 失败时，大概率不是网络问题，而是模块路径与仓库根目录不一致，或 GOPRIVATE 配置遗漏。
-
go.mod中module声明必须和 Git 仓库 URL 完全对应，例如仓库地址是https://git.example.com/team/lib，则module必须是git.example.com/team/lib -
GOPRIVATE=git.example.com只匹配一级域名；若用子路径，得写成GOPRIVATE=git.example.com/team/* - SSH 地址（
git@git.example.com:team/lib.git）需在~/.gitconfig配置[url "git@git.example.com:"] insteadOf = https://git.example.com/，否则go mod download仍走 HTTPS 并 403
真正麻烦的从来不是怎么加依赖，而是某天 go build 突然失败却查不到改动点——往往卡在 go.sum 校验、伪版本生成、或 GOPRIVATE 通配符漏了一层斜杠。这些地方不显眼，但改错一行就停摆一上午。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
