PATCH更新仅修复向下兼容的缺陷，不新增功能或修改API，但v0.x.y版本除外；实际需通过比对diff、运行gorelease和全量测试验证安全性。
修订版本（PATCH）变更到底改了什么
修订版本号递增（如从 v1.2.3 升到 v1.2.4）只表示做了向下兼容的问题修复，不新增功能、不修改公开 API。这类更新理论上应零风险，但实际中仍可能踩坑。
- 修复的是“不正确结果”的内部逻辑，比如数值计算偏差、竞态条件触发时机、空指针 panic 场景补丁等，不是表面可见的功能调整
- 某些模块把文档修正、测试用例补充、构建脚本微调也归入 PATCH，这些不影响运行时行为，但可能影响 CI 或本地开发流程
- 极少数情况下，作者误将破坏性修改塞进 PATCH（违反 SemVer），此时
go get -u自动升级可能导致静默故障
为什么 go mod tidy 有时会升 PATCH 版本
Go 的最小版本选择（MVS）算法并不只看直接依赖声明，而是综合所有间接依赖的约束。即使你写死 require example.com/pkg v1.2.3，只要某个间接依赖要求 v1.2.4 或更高 PATCH，go mod tidy 就会把它升上去。
- 这种升级是自动且隐式的，
go.sum会同步更新哈希值，但go.mod中版本号可能不变（取决于是否显式指定） - 执行
go list -m example.com/pkg能看到当前实际选用的版本，比go.mod更真实 - 若想锁死 PATCH，必须在
go.mod中显式写全版本号，并避免使用@latest或模糊匹配
v0.x.y 和 v1.x.y 的 PATCH 行为差异
主版本为 0（如 v0.8.5）的模块不承诺 API 稳定性，哪怕只升 PATCH，也可能包含不兼容变更。而 v1.x.y 及以上才真正受 SemVer 约束。
-
v0.x.y的 PATCH 更新要像 MINOR 一样谨慎对待：查 commit diff、跑全部测试、确认导出符号无删减 -
v1.x.y的 PATCH 基本可信任，但仍建议关注对应 release note 中标注的 “Fixed” 条目，尤其是涉及并发、IO、序列化等敏感路径的修复 - 生产环境应避免依赖
v0.x.y模块，或至少在go.mod中用exclude锁定已验证的 PATCH
如何验证一个 PATCH 是否真的安全
不能只信版本号，得看实质内容。最直接的方式是比对两个 PATCH 版本间的变更范围。
立即学习“go语言免费学习笔记（深入）”；
- 用
go list -m -versions example.com/pkg查可用版本，再访问模块仓库（如 GitHub）的 compare 链接：https://github.com/user/repo/compare/v1.2.3...v1.2.4 - 重点关注
exported函数/类型/常量的签名变化，以及internal/目录外的测试用例增减 - 运行
gorelease -base=v1.2.3 -target=v1.2.4，它会报告导出符号的增删改，比肉眼扫 diff 更可靠 - CI 中可加一条检查：对所有 PATCH 升级，强制要求
go test ./...全通，且覆盖率不降
