go install 必须指定 @latest，否则会拉取旧版 CLI 导致 revel new 失败；Revel v1.0+ 强依赖 Go Modules，需 GO111MODULE=on 且禁用 GOPATH 干预；项目无顶层 main.go，入口在 app/tmp/main.go。
go install 命令必须用 latest，否则会拉错版本
Revel 的命令行工具 revel 和框架本身在 Go Modules 时代已拆分为两个独立模块，且官方早已弃用 go get（尤其对旧版 Go）。用 go get github.com/revel/cmd/revel 会命中 v0.2x 分支，导致后续 revel new 报 no Go files in current directory 或模板渲染失败——因为新版 Revel（v1.0+）要求项目结构与模块路径强一致，而旧 CLI 不识别。
正确做法是统一用 go install 指向 @latest：
go install github.com/revel/cmd/revel@latest-
go install github.com/revel/revel@latest（可选，框架本身通常随项目自动下载）
执行后检查：revel version 应输出类似 v1.0.0-20261015123456-abcdef123456 的 commit-hash 版本，而非 v0.22.1。
GO111MODULE=on 是硬性前提，不能依赖 GOPATH
Revel v1.0+ 完全基于 Go Modules 构建，所有依赖（包括 github.com/revel/config、github.com/klauspost/compress）都通过 go.mod 解析。若环境未显式启用模块，revel new myapp 会静默创建空 go.mod，后续 go build 直接失败，报错如 cannot find package "github.com/revel/revel"。
务必在 shell 中设置：
-
export GO111MODULE=on（Linux/macOS） -
$env:GO111MODULE="on"（PowerShell） - 验证：
go env GO111MODULE必须返回on
不要设 GOPATH 干预模块查找路径——Revel 项目根目录即模块根，go mod init 由 revel new 自动完成，手动干预反而破坏约定。
国内用户绕过代理失败的三类典型错误
即使设置了 GOPROXY，仍常因以下原因卡在 go install 阶段：
- 代理地址末尾漏了
/：比如https://goproxy.cn应为https://goproxy.cn/，否则部分模块重定向失败 - 未同步 golang.org/x 系列包：Revel 依赖
golang.org/x/net和golang.org/x/text，需额外配置export GOPROXY=https://goproxy.cn,direct，其中direct保证这些域名走直连（若你有稳定代理则可省略） - 本地 DNS 污染残留：运行
go clean -modcache清空缓存后再试，避免旧版依赖被复用
验证是否成功：执行 revel new testapp 后，testapp/go.mod 中应包含 github.com/revel/revel v1.0.0- 开头的版本号，且 go list -m all | grep revel 能列出全部子模块。
revel new 生成的项目默认不带 main.go，别急着 go build
Revel v1.0+ 不再生成顶层 main.go，而是把入口逻辑封装在 app/tmp/main.go（由 revel run 动态生成），这是为了支持热重载和开发模式注入。直接 go build 当前目录会报 no Go files——这不是安装失败，是设计如此。
生产构建必须指定入口：
- 启动开发服务：
revel run -a testapp（自动处理临时 main） - 构建生产二进制：
go build -o testapp ./app/tmp（注意路径是./app/tmp，不是.） - CI/CD 中务必确认
app/tmp/main.go已提交到 Git，否则go build会找不到文件
这个细节最容易被忽略：很多团队在 CI 中写 go build -o app . 导致构建失败，实际只需改一个路径。
