主版本升级必须手动修改import路径，如将"github.com/gorilla/mux"改为"github.com/gorilla/mux/v2"，否则编译失败；路径、module声明、目录结构须严格一致，且需同步更新子包路径，再执行go get和go mod tidy。
主版本升级必须改 import 路径，否则编译失败
Go 模块对 v2+ 主版本有硬性路径要求：不能只靠 go get 自动完成，必须手动修改代码里的 import 语句。比如从 "github.com/gorilla/mux" 升到 v2，得改成 "github.com/gorilla/mux/v2"，否则 go build 会报错 cannot find package "github.com/gorilla/mux" 或更隐蔽的符号冲突。
常见错误现象：
- 执行
go get github.com/gorilla/mux@v2.0.0后go build失败，提示找不到包 -
go list -m all显示已拉取 v2，但代码仍用旧路径导入，实际加载的还是 v1 - 同一项目中混用 v1 和 v2 路径（如部分文件用
mux、部分用mux/v2），触发duplicate symbol类链接错误
正确做法：
- 先查 GitHub Releases 确认 v2 是否已按规范发布（module 行含
/v2） - 批量替换所有
import语句，注意子包路径也要同步更新（如"github.com/gorilla/mux/middleware"→"github.com/gorilla/mux/v2/middleware"） - 再运行
go get github.com/gorilla/mux/v2@v2.0.0+go mod tidy
次版本升级默认不跨主版本，go get -u 只升到当前主版本最新
go get -u 的行为常被误解：它不会跳到 v2，哪怕 v2 已存在；它只在当前主版本内找最新 minor/patch。例如本地是 golang.org/x/net v0.22.0，go get -u golang.org/x/net 最多升到 v0.23.0，绝不会自动切到 v0.24.0 以外的版本，更不会进 v1。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：
- 以为
go get -u能“一键升最新”，结果长期卡在旧 minor 版本，错过安全修复 - 依赖的某个间接模块悄悄升了 minor 版本，导致
http.Client默认行为变化（如超时策略、重试逻辑） - 某些 v0.x 模块的 minor 升级实际含破坏性变更（因 v0 不承诺兼容），
-u会无声引入风险
更可控的做法：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 用
go list -m -u github.com/sirupsen/logrus先看可升级范围，确认目标版本是否真在当前主版本内 - 显式指定版本升级：
go get github.com/sirupsen/logrus@v1.10.0，避免递归影响间接依赖 - 生产环境建议锁定 patch 版本（如
v1.9.3），仅在 CI 中跑go get -u=patch自动验证小版本兼容性
主版本升级后需检查间接依赖是否被意外降级
主版本切换常引发连锁反应：新主版本可能删掉旧接口，而某个未升级的间接依赖仍依赖旧版 API，导致 go mod tidy 自动降级回 v1 —— 表面看 go.mod 写着 v2，实际构建用的却是 v1。
验证方法：
- 运行
go mod graph | grep mux，确认所有路径都指向/v2，而非混杂/mux（无版本后缀） -
go list -m all | grep mux输出应只有一行github.com/gorilla/mux/v2 v2.0.0，若出现github.com/gorilla/mux v1.8.0就说明降级了 - 用
go mod why github.com/gorilla/mux追溯谁还在拉 v1，通常是某个老版本的中间件或工具库
此时不能靠 replace 强行覆盖，而要：
- 升级那个拖后腿的间接依赖（查它的 GitHub 是否已支持 mux/v2）
- 若上游无响应，考虑 fork 并打兼容补丁，用
replace github.com/bad/lib => ./fork/bad-lib - 临时 exclude 问题版本：
exclude github.com/bad/lib v1.2.0，逼 MVS 选更高兼容版本
v0.x 和 v1+ 的升级风险差异极大
v0.x 模块没有兼容性承诺，每次 minor 升级都可能是破坏性变更；而 v1+ 模块的 minor 升级理论上只加功能、不删接口。但现实里，很多 v1+ 库作者会把重大重构塞进 minor 版本（尤其 v1.0.x 到 v1.1.x），所以不能盲目信任。
判断依据：
- v0.x：直接看 CHANGELOG 里有没有 “BREAKING” 字样，没有也得当心；优先用 patch 锁定，如
v0.12.3 - v1+：重点查 GitHub Releases 的 “Deprecations” 和 “Breaking Changes” 小节，v1.25.0 → v1.26.0 这类升级更要人工核对
- 伪版本（如
v0.0.0-20230101-abc123）本质是 commit hash，无语义，仅用于调试，切勿进生产 go.mod
一个容易被忽略的细节：有些模块打着 v1.x 标签，但 go.mod 里写的仍是 module example.com/pkg（没加 /v1），这说明它没真正遵守 Go Modules 规范——这种模块的 v2 升级会更混乱，得格外小心。
