Go版本管理核心是理解go get、go mod tidy等命令的行为差异：go get -u升级到最高兼容minor版，精确锁定需@指定；replace/exclude影响依赖解析但不改变构建行为；go mod tidy不降级版本，仅增删require。
Go 1.11 引入 go mod 后，Go 官方包管理已基本脱离 $GOPATH 依赖，直接通过 go.mod 文件声明版本约束。但实际使用中，常见问题不是“能不能用”，而是“为什么用了 go get 却没更新到想要的版本”“require 里写 v1.2.3 为什么拉下来是 v1.2.4”——本质是没理清 Go 版本解析规则与命令行为差异。
go get -u 默认升级到最新次版本，不是指定版本
go get -u 会按模块的语义化版本规则，升级到满足当前 require 范围的**最高兼容次版本（minor）**，而非你显式写的那个 patch 版本。比如 require github.com/sirupsen/logrus v1.9.0，执行 go get -u 后可能变成 v1.10.1（只要主版本仍是 v1）。
- 想精确锁定版本：改用
go get github.com/sirupsen/logrus@v1.9.0（带@显式指定） - 想禁用自动升级逻辑：在
go.mod中加// indirect注释不解决，得靠go mod edit -droprequire或手动删后go mod tidy - 执行后检查是否真生效：
go list -m all | grep logrus，别只信go.mod文件内容
replace 和 exclude 不影响 go build，但会干扰 go list 和依赖图
replace 常用于本地调试或 fork 替换，但它只是构建时重定向路径，go list -m all 仍显示原始模块名和版本，容易误判真实依赖树；exclude 则彻底从 go.mod 的版本选择中剔除某版本（哪怕其他模块间接依赖它），但若某依赖硬编码调用被 exclude 的符号，go build 仍可能失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
replace github.com/xxx/lib => ./local-lib：路径必须存在且含go.mod，否则go build报no required module provides package -
exclude github.com/xxx/lib v1.5.0：仅当v1.5.0是某个依赖自动选中的版本时才生效；若其他依赖明确require它，则 exclude 无效 - 调试时优先用
go mod graph | grep xxx查真实引用链，而不是只看go.mod
go mod tidy 会清理未使用的 require，但不会降级已存在的版本
go mod tidy 的核心动作是：补全缺失的 require、删除未被任何 .go 文件 import 的模块条目。它**不会**把当前 require 中的 v1.10.0 自动降级成 v1.9.0，哪怕代码里根本没用到 v1.10.0 新增的 API。
立即学习“go语言免费学习笔记（深入）”；
- 要强制降级：先
go get github.com/xxx/pkg@v1.9.0，再go mod tidy - 若 tidy 后发现某模块消失，说明项目里没有任何
import触发它，不是“被删了”，是“本来就不该在” - CI 中建议加
go mod tidy -v && git diff --quiet go.mod go.sum || exit 1，防止手误提交不一致状态
真正难控的不是怎么写 go.mod，而是当多个间接依赖各自 require 同一模块的不同 minor 版本时，Go 会选择其中最高的那个——这个决策发生在 go build 前，且不报错，只有运行时才发现行为异常。这时候得靠 go mod graph 拆解冲突点，而不是反复 go get -u。
