go get -u 默认升级至最新主版本，可能破坏兼容性；应显式指定版本或用@latest限同主版本更新。//indirect表示间接依赖，由go mod tidy维护以确保构建可重现。
go get -u 会更新到最新主版本，但可能破坏兼容性
默认用 go get -u 更新依赖时，Go 会拉取模块的最新**主版本（major version）**，比如从 v1.2.3 升到 v2.0.0。这看似“最新”，实则高危：v2+ 模块在 Go 中需通过带 /v2 后缀的导入路径引用，否则编译失败。
常见错误现象：import "github.com/some/pkg" 突然报错 cannot find module providing package github.com/some/pkg，实际是对方发布了 v2 但你没改导入路径。
- 安全做法是显式指定版本，例如
go get github.com/some/pkg@v1.5.0 - 若想升 minor/patch 版本（保持 API 兼容），用
go get github.com/some/pkg@latest—— 它只取 v1.x 范围内的最新版 - 更新全部依赖到各自 latest（仍限同主版本）：
go get -u=patch或go get -u=minor
go.mod 中 require 行末尾的 // indirect 标记意味着什么
当你运行 go build 或 go test 时，Go 可能自动添加带 // indirect 的 require 行。这不是手动引入的依赖，而是某个直接依赖的**间接依赖（transitive dependency）**，且当前项目未直接 import 它。
典型场景：A 依赖 B，B 依赖 C；你的代码只 import A，但 go.mod 里出现了 require C v1.2.0 // indirect。它存在是为了保证构建可重现 —— 即使 B 没锁死 C 的版本，Go 也会帮你记下此刻解析出的 C 版本。
立即学习“go语言免费学习笔记（深入）”；
- 不要手动删
// indirect行，否则下次go build可能拉取不同版本的 C，引发隐性不一致 - 如果某
// indirect包后来被你直接 import 了，运行go mod tidy会自动移除该行的// indirect标记 -
go mod graph | grep可查清谁引入了这个间接依赖
go mod tidy 不只是清理，它会主动降级或升级依赖以满足最小版本选择（MVS）
go mod tidy 表面是“整理依赖”，实际执行的是 Go 的**最小版本选择算法（Minimal Version Selection）**：对每个模块，选满足所有依赖约束的**最低可能版本**。这意味着它可能把某个包从 v1.8.0 “降级”回 v1.5.0 —— 如果没有其他依赖要求更高版本的话。
容易踩的坑：团队中有人先 go get 了新版本，提交了 go.mod；另一个人 go mod tidy 后发现依赖变少了、版本也低了，误以为出错。
- 协作时应统一用
go mod tidy生成go.mod和go.sum，而非靠go get手动增删 - 想锁定某个包不被
tidy降级？加一行require github.com/x/y v1.8.0（无// indirect），它就成了显式约束 -
go mod verify可校验本地缓存包是否与go.sum一致，防止篡改或下载损坏
替换私有仓库或临时分支用 replace，但上线前必须删掉
开发中常需测试 fork 后的修复分支、或使用尚未公开的内部模块，这时用 replace 最直接：
replace github.com/orig/pkg => ./local-fix
或指向 Git 分支：
replace github.com/orig/pkg => github.com/you/pkg v0.0.0-20230401120000-abcd1234
问题在于：replace **仅在本地 go.mod 所在模块生效**，不会传递给下游用户；且 go build -mod=readonly（CI 常用）会直接报错拒绝构建。
- 测试完确认没问题后，务必删掉
replace行，并用go get拉正式版本，再go mod tidy - 若必须长期用 fork，应让 fork 项目发布语义化版本（如
v1.2.3-myfix），然后require它，而非replace -
go list -m all可快速查看当前解析出的所有模块及版本，含是否被 replace
go mod graph 和 go list -m -versions 这两个命令比任何文档都管用。 
