Beego v2 不发布带 patch 号的子版本 tag，无法用 go get github.com/beego/beego/v2@v2.1.0 精确安装；只能指定 minor 版（如 @v2.1）、commit（如 @8a3f9d2）或 @latest，且需配合 replace 锁定 commit 以确保构建一致性。
go get 不能直接指定 Beego v2 子版本？用 @version 语法
Beego v2 的模块路径是 github.com/beego/beego/v2，它本身是 Go Module 的语义化版本包，go get 默认拉取 latest（即最新 tagged 版本），但你无法像普通库那样用 go get github.com/beego/beego/v2@v2.1.0 精确安装——因为官方不发布带 patch 号的子版本 tag（如 v2.1.0、v2.2.1），只维护 v2 这个 major 分支的最新 commit。
所以「指定版本」实际指两种情况：固定到某个已发布的 minor 版（如 v2.1），或锁定到某次 commit。操作上必须显式加 @ 后缀：
-
go get github.com/beego/beego/v2@v2.1→ 拉取 v2.1.x 系列最新 tag（若有） -
go get github.com/beego/beego/v2@8a3f9d2→ 拉取特定 commit（推荐用于调试或复现问题） -
go get github.com/beego/beego/v2@latest→ 显式声明，避免因 GOPROXY 缓存导致意外降级
注意：go get github.com/beego/beego/v2 不带 @ 时行为取决于本地 go.mod 是否已有该依赖及 GO111MODULE 状态，容易不一致。
bee 工具也要匹配 Beego v2 版本
bee 是独立工具，其版本与 Beego 运行时版本需对齐，否则 bee run 可能报错或忽略新特性（比如 v2.2+ 的路由注册方式变更）。安装时务必用 v2 后缀：
- 正确：
go install github.com/beego/bee/v2@latest - 错误：
go install github.com/beego/bee（会装 v1，已废弃） - 验证：
bee version输出应含v2.x.x，且bee new myapp生成的go.mod中依赖为github.com/beego/beego/v2
如果 bee 报 unknown revision，说明 GOPROXY 没生效或缓存脏了，先执行 go clean -modcache 再重试。
项目内锁定 Beego 版本靠 go.mod + replace（多版本共存场景）
当你同时维护多个 Beego 项目，有的用 v2.0，有的要升到 v2.3，又不想全局升级，就得在项目 go.mod 里硬编码版本：
require github.com/beego/beego/v2 v2.3.0
但如果官方没打 v2.3.0 tag（事实如此），Go 会 fallback 到最近的 v2.x tag 或主干 commit —— 此时唯一可靠方式是 replace：
replace github.com/beego/beego/v2 => github.com/beego/beego/v2 v2.2.0
或者指向具体 commit：
replace github.com/beego/beego/v2 => github.com/beego/beego/v2 7c1e8a5
执行 go mod tidy 后，所有 import "github.com/beego/beego/v2" 都会走这个替换路径。注意：replace 仅对当前 module 生效，不会影响其他项目。
常见报错：missing go.sum entry 或 checksum mismatch
这是 Go Module 校验失败的典型表现，根本原因是 GOPROXY 返回的包内容和本地 go.sum 记录不一致。Beego 因频繁发版、tag 稳定性差，特别容易触发：
- 现象：
verifying github.com/beego/beego/v2@v2.2.0: checksum mismatch - 原因：GOPROXY（如 goproxy.cn）缓存了旧版，或你本地曾手动改过源码
- 解法：删掉
go.sum中对应行 + 执行go mod download -dirty，或干脆go clean -modcache && go mod tidy - 预防：在 CI/CD 中固定 GOPROXY 和 Go 版本，避免不同环境拉到不同 commit
真正麻烦的不是装不上，而是装上了却因 commit 不一致导致行为漂移 —— 尤其在日志格式、ORM 初始化顺序这类底层细节上，建议团队统一用 replace 锁死 commit hash。
