go get -u=patch 仅升级补丁版本（如v1.9.1→v1.9.3），不升minor或major，作用于direct依赖及其子树中满足semver约束的模块，需配合go mod tidy同步go.sum和清理未引用依赖。
go get -u=patch 只升补丁，不碰次版本
这是最直接、最可控的补丁级升级方式。它会把所有 direct 依赖及其子树中满足语义化版本约束的模块，**仅升级到最新 patch 版本（如 v1.9.1 → v1.9.3）**，不会升 minor（v1.9.x → v1.10.0）或 major（v1 → v2）。
常见误操作是只写 go get -u，它默认允许 minor 升级，容易引入意料外的行为变更。而 go get -u=patch 明确限定了升级粒度。
- 执行范围：只作用于当前模块下的所有包（
./），不跨 module 边界 - 间接依赖（
// indirect）是否升级？—— 仅当它们被某个 direct 依赖的新 patch 版本重新引入时才会动，否则保持原样 - 必须配合
go mod tidy才能同步go.sum和未引用的新增依赖项
go.mod 中 require 的版本号不是“锁定”，而是“下限+范围”
require github.com/sirupsen/logrus v1.9.0 这行并不表示“固定用 v1.9.0”，而是告诉 Go：“请选 v1.9.* 范围内最新可用的版本”。构建时若存在 v1.9.3 且未被 exclude 或 replace 干扰，Go 就可能拉取它。
真正锁定靠的是 go.sum：它记录每个模块的 commit hash 和文件哈希。只要 go.sum 不变，go build 拉的代码就完全一致。
- 手动改
go.mod中的版本号后，必须运行go mod tidy，否则go.sum缺失对应条目，CI 构建会失败 - 如果想强制用 v1.9.0（哪怕 v1.9.3 已存在），得加
exclude github.com/sirupsen/logrus v1.9.1 // indirect，但不推荐——这会绕过 MVS 规则，可能引发冲突 - 更稳妥的做法是：先
go get github.com/sirupsen/logrus@v1.9.0，再go mod tidy
go mod tidy 会悄悄升级版本？是的，但只因“最小版本选择”规则
go mod tidy 本身不主动升级，但它会按 Go 的最小版本选择（MVS）规则补全依赖图。如果你代码里没显式 import 某个包，但某个已升级的 direct 依赖内部用了 github.com/sirupsen/logrus v1.9.3，而你 go.mod 里只写了 v1.9.0，tidy 就会把 go.mod 改成 v1.9.3 —— 否则无法满足依赖一致性。
这不是 bug，是 Go 模块系统的设计逻辑：它保证整个依赖图里每个模块只存在一个版本（主版本相同前提下）。
- 这种升级通常发生在你运行
go get -u=patch ./后再go mod tidy，或者在引入新功能后首次tidy - CI 中建议加
-v参数：go mod tidy -v，能看到它实际增删了哪些模块，方便快速识别意外变更 - 如果不想让
tidy改go.mod，就得确保所有间接依赖的版本都被 direct 依赖显式声明并收敛
补丁升级后 panic(nil) 崩溃？检查 panic( 和 http.Error
Go 1.22+ 开始，panic(nil) 不再静默忽略，而是直接崩溃。很多老项目或第三方库里有类似 panic(err) 的写法，一旦 err == nil 就炸。升级补丁版本（尤其从 1.21→1.22+）后高频出现。
这不是依赖本身的问题，而是 Go 运行时行为收敛。修复成本低，但容易漏掉。
- 全局搜索
panic(，重点检查传入变量是否可能为nil - 标准库调用也要留心：
http.Error第二个参数是http.ResponseWriter，若传nil，新版本也会 panic - 某些老 YAML 库（如
gopkg.in/yaml.v2）在 Go 1.23+ 中已知反射 panic，必须换为gopkg.in/yaml.v3或github.com/go-yaml/yaml
补丁升级看似安全，但最容易被忽略的是：它可能触发底层依赖的隐式行为变更，而这些变更往往藏在间接依赖里，不跑测试根本发现不了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
