Revel 项目必须用 Go Modules 管理依赖，GO111MODULE 必须为 on 或空值，且项目根目录需有 go.mod 文件；revel run 依赖 go.mod 中的 module path 解析资源路径，go run main.go 无法提供 Revel 运行时上下文。
Revel 项目必须用 Go Modules 管理依赖，不是可选项
Revel 自 v1.0 起（2022 年后）已原生支持 Go Modules，GO111MODULE=off 或手动维护 GOPATH/src 结构是过时且高风险的做法。如果你还在用 revel run 报 not found in GOPATH，说明环境未对齐现代 Go 工程规范。
关键判断点：go env GO111MODULE 必须是 on 或空值（Go 1.16+ 默认开启），且项目根目录存在 go.mod 文件。Revel CLI ≥ v1.1.0 会自动识别 app.importPath 来自 go.mod 的 module path，不再硬编码到 $GOPATH/src 下。
- 初始化命令必须是
go mod init github.com/yourname/myapp，路径只是导入标识，不约束物理位置 -
revel new myapp后立即执行go mod tidy，否则可能漏掉github.com/revel/revel等核心依赖 - 若用
revel package生成部署包，它内部仍依赖go build，所以go.mod必须完整、可复现
peerDependencies 在 Revel 中不存在，别套前端那一套
Revel 是 Go 框架，没有 package.json，也没有 peerDependencies 概念。所谓“框架依赖宿主环境”的逻辑在 Go 里不成立——所有依赖都通过 go mod 静态解析、编译进二进制，不存在运行时动态加载或版本协商。
你看到的 peerDependencies 示例（如 react、react-dom）只适用于 JS 生态的 UI 框架封装场景，和 Revel 完全无关。强行类比会导致两个后果：
- 误以为要让使用者自己
go getRevel 核心包 → 实际上go mod tidy就能拉全 - 在
go.mod里写replace或exclude干预 Revel 依赖 → 可能破坏其内部revel.AppInit初始化链
Revel 的扩展机制（如插件、模块）靠的是 Go 包导入 + 接口实现，不是 npm 式的 peer 约束。
revel run 和 go run main.go 的依赖行为完全不同
直接 go run main.go 在 Revel 项目中几乎总是失败，错误像 Failed to import with error: import "": invalid import path。这不是依赖没装好，而是 go run 不提供 Revel 运行时所需的上下文。
Revel 的 main.go（尤其是 revel.NewApp 启动入口）依赖 app.conf 中的 app.importPath 值来定位控制器、模板、拦截器等资源路径。这个路径由 go.mod 的 module name 决定，但 go run 不读配置、不注入环境变量、不触发 Revel 的初始化钩子。
- 开发阶段只用
revel run myapp，它会自动加载conf/、扫描app/、绑定路由 - 部署阶段用
revel package myapp生成可执行文件，本质是go build -o myapp .，此时依赖已静态链接 - 若想跳过 Revel CLI 直接构建，确保
go build在项目根目录执行，且go.mod中 module 名与app.conf里的app.importPath一致
第三方 Go 包混用时容易踩的 module 版本冲突坑
Revel 本身不控制你的 dependencies，但它的部分子模块（如 revel/modules/db）可能间接依赖旧版 github.com/go-sql-driver/mysql 或 gopkg.in/yaml.v2。当你显式 require 新版驱动时，go mod 会尝试统一版本，但 Revel 内部代码若用了已移除的 API，就会编译失败或 panic。
典型症状：undefined: yaml.MapSlice 或 cannot use db (type *sql.DB) as type *gorm.DB。
- 先用
go mod graph | grep revel查 Revel 直接依赖了哪些包及其版本 - 对冲突包，优先用
go mod edit -require=xxx@v1.2.3显式指定兼容版本，而非replace - Revel v1.1.0 测试过兼容
gopkg.in/yaml.v3，但某些插件模块仍锁死v2，这时需确认插件是否维护活跃；不建议长期replace掩盖问题
最稳妥的方式是：保持 Revel 主干升级节奏，避免在 go.mod 里随意降级其 transitive dependencies —— Go 的模块系统不会帮你做运行时适配，错配就是编译期报错。
