go modules 更新不可盲目执行 go get -u，须先用 go list -u -m all 查看可升级项，再逐个确认；主版本升级需手动修改 import 路径并执行 go get @vx.x.x；ci/cd 中必须显式锁定版本以保障构建可重现。
直接更新 go.mod 里所有依赖到最新兼容版本，不是简单执行一条命令就能完事的——Go 的模块更新受 go.sum 校验、语义化版本约束、主版本号跃迁（如 v2+）和本地 replace 规则影响极大，盲目升级大概率导致构建失败或运行时 panic。
go get -u 默认只升 patch 和 minor 版本
go get -u 看似“一键升级”，实际行为很保守：它只会把依赖升到当前主版本下的最新 minor 或 patch 版本（比如从 v1.12.3 升到 v1.15.7），但绝不会跨主版本（如不自动从 v1.x 升到 v2.0.0）。这是因为 Go 模块要求 v2+ 必须带 /v2 路径后缀，否则会被视为不兼容变更。
- 想强制升级某个模块到特定版本？用
go get example.com/lib@v2.3.0 - 想升级到最新预发布版（如 rc）？加
@latest不够，得显式写@v2.3.0-rc.1 -
go get -u ./...只作用于当前目录及子目录引用的模块，不会触达间接依赖（require中带// indirect的那些）
go list -m -u all 显示可升级但不自动改 go.mod
go list -m -u all 是安全排查的第一步：它列出所有模块当前版本、可用最新版本、是否为间接依赖。但它**不做任何修改**，只是告诉你“哪些能升、升到哪”。输出里带 [behind] 表示有更新，[newer] 表示你锁的版本比当前 go.sum 记录的还新（通常因手动编辑过 go.mod）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 注意看输出中的
=>符号，右边是推荐升级目标，比如golang.org/x/net v0.14.0 => v0.22.0 - 如果某模块显示
(devel)，说明它被replace指向本地路径或 commit，go get不会动它 - 想只查某个模块？
go list -m -u golang.org/x/text
升级 v2+ 模块必须手动改 import 路径
Go 不允许 import "example.com/lib" 同时指向 v1 和 v2，所以升级 v2+ 版本时，go.mod 里路径会变成 example.com/lib/v2，你代码里的 import 语句也必须同步改——这是最容易漏掉、最常导致编译报错的点。
- 先运行
go get example.com/lib/v2@latest，它会在go.mod中写入example.com/lib/v2 v2.1.0 - 然后全局搜索替换
import "example.com/lib"→import "example.com/lib/v2" - 如果模块作者没按规范发布（比如 v2 仍用
/v1路径），go get会拒绝安装，得联系维护者或 fork 修复
go mod tidy 不等于升级，而是收敛依赖树
go mod tidy 的作用是：删掉未使用的 require、补全缺失的间接依赖、按当前代码引用关系重排 go.mod。它**不会主动升版本**，除非你先用 go get 改了某个模块版本，它才帮你把依赖树里相关联的其他模块版本也拉齐。
- 执行前确保
go.mod已提交，避免误删还在开发中但未引用的依赖 - 如果
go.sum校验失败（比如网络中断导致部分 checksum 缺失），tidy会卡住，此时可临时设GOSUMDB=off（仅调试用） - CI 环境建议加
-v参数：go mod tidy -v，方便定位哪条依赖引发冲突
真正麻烦的不是命令怎么敲，而是每个模块升级后是否引入了破坏性变更——比如函数签名改了、默认行为变了、或者文档里没写的隐式依赖升级了。上线前至少跑一遍 go test ./...，重点看那些刚升级的模块对应的功能测试是否通过。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
