应使用带补零的语义化版本，如go install github.com/revel/cmd/revel@v0.25.0；错误写法@v0.24会失败，因实际tag为v0.24.0；安装后须运行revel version验证。
go install 时如何指定 Revel CLI 版本
Revel 的命令行工具（revel）和框架核心是分离发布的，go install 默认拉取 @latest，但有时你必须锁定特定 CLI 版本（比如配合旧版框架或 CI 环境一致性）。不能写成 go install github.com/revel/cmd/revel@v0.24 这种形式——它会失败，因为该仓库的 tag 命名不遵循 Go module 规范（实际是 v0.24.0，而非 v0.24）。
正确做法是显式使用带补零的语义化版本：
-
go install github.com/revel/cmd/revel@v0.25.0（推荐，对应 Revel v1.1.0 框架） -
go install github.com/revel/cmd/revel@v0.24.0（仅用于维护 v1.0.x 项目） - 安装后务必运行
revel version验证输出是否含CLI v0.25.0字样
框架依赖如何在 go.mod 中精确指定版本
Revel 框架本身作为模块依赖，必须在 go.mod 中显式声明，且版本号必须与 CLI 兼容。v1.1.0 是当前稳定版，但它的 module path 是 github.com/revel/revel，不是 github.com/revel/revel/v1（它未启用 Major Version Suffix）。
常见错误是写错版本格式或漏掉 go mod tidy：
- 手动编辑
go.mod，确保这一行存在：github.com/revel/revel v1.1.0 - 不要写成
v1.1、1.1.0或latest，Go Modules 会拒绝解析 - 改完后必须执行
go mod tidy，否则revel run .仍报cannot find package "github.com/revel/revel" - 若项目原用 GOPATH 结构，
go mod tidy可能卡住——先确认GO111MODULE=on
同一台机器上能否共存多个 Revel CLI 版本
不能直接共存。go install 总是覆盖 $GOPATH/bin/revel（或 $GOBIN/revel），没有版本隔离机制。如果你需要频繁切换（例如本地开发用 v0.25，而某个遗留 CI 脚本依赖 v0.24），得用变通方式：
- 为不同版本分别安装到独立路径：
go install -o ~/bin/revel-v0.24 github.com/revel/cmd/revel@v0.24.0 - 再装另一个：
go install -o ~/bin/revel-v0.25 github.com/revel/cmd/revel@v0.25.0 - 使用时显式调用：
~/bin/revel-v0.24 new myapp或~/bin/revel-v0.25 run . - 注意：两个 CLI 仍会读取同一个
go.mod和app/init.go，版本不匹配时启动仍可能 panic
revel run 报 “not found in GOPATH” 的真实原因和解法
这个错误信息极具误导性。它几乎从不表示路径真不在 GOPATH，而是 Revel CLI 与框架版本不匹配导致的加载失败——尤其是当你用 v0.24 CLI 启动一个已升级到 v1.1.0 框架的项目时。
排查顺序必须严格按依赖链来：
- 第一步：运行
revel version，确认 CLI 是 v0.25.0 - 第二步：检查
go.mod中github.com/revel/revel行是否为v1.1.0 - 第三步：执行
go mod tidy，观察是否出现require github.com/revel/revel v1.1.0 // indirect - 第四步：启动时**必须加点号**：
revel run .（旧版 CLI 会尝试自动推断路径，v0.25+ 要求显式传参） - 如果还失败，
ls -l app/init.go看是否存在——v1.1.0 强制要求该文件存在并调用revel.Run()
最易被忽略的一点：revel run 失败时不会打印完整 stack trace，只报模糊路径错误；真正的问题往往藏在 CLI 和框架的版本对齐细节里，而不是代码或配置本身。
