Revel 框架不支持自定义 CLI 命令，因其无内置命令系统且官方 CLI 硬编码不可扩展；应使用独立 Go 命令行工具，通过 revel.Init 和 revel.LoadConfig 初始化环境后调用业务逻辑。
Revel 框架本身不提供类似 Laravel php artisan 那样开箱即用的自定义命令行机制——它没有内置的命令注册系统、Command 基类或 app/Console/Commands 目录约定。所有官方 revel CLI 子命令（如 revel new、revel run）都硬编码在 github.com/revel/cmd/revel 里，且不开放扩展接口。
为什么不能直接写 revel my-command
Revel 的命令行工具是单体二进制，源码中 main.go 用 flag 硬编码解析子命令，没有插件或钩子机制。你无法通过修改项目代码让 revel 主程序识别新命令；强行向其源码注入逻辑会破坏可升级性，也不符合 Go Modules 依赖管理原则。
- 试图在
app/下新建命令文件并期望revel自动发现——不会生效 - 重编译
revel二进制并打补丁——每次升级都要重复，维护成本高 - 误以为
revel clean或revel package是可继承的模板——它们是固定功能，不可复用为业务命令基类
替代方案：用标准 Go 工具链写独立命令
最务实的做法是绕过 revel CLI，直接用 Go 写一个与 Revel 应用共存的独立命令行工具。它能访问项目全部代码（models、controllers、配置），且完全可控。
- 在项目根目录新建
cmd/mytool/main.go，导入你的 Revel 应用包（如my-app/app） - 初始化 Revel 运行时所需环境：
revel.Init(...)+revel.LoadConfig()，否则app.DB或revel.BEFORE_ROUTES等会 panic - 用
flag或github.com/spf13/cobra解析参数，调用业务逻辑（比如models.User.DeleteStale()） - 构建为独立二进制：
go build -o bin/mytool cmd/mytool/main.go，运行bin/mytool --dry-run
示例关键片段：
package main
<p>import (
"flag"
"log"
"my-app/app" // ← 你的 Revel 应用包
"github.com/revel/revel"
)</p><p>func main() {
dryRun := flag.Bool("dry-run", false, "show what would be deleted")
flag.Parse()</p><pre class="brush:php;toolbar:false;">// 必须初始化 Revel 环境，否则 app.* 无法使用
revel.Init("prod", ".", ".")
revel.LoadConfig()
if *dryRun {
log.Println("Would delete stale users...")
} else {
count, err := app.DeleteStaleUsers()
if err != nil {
log.Fatal(err)
}
log.Printf("Deleted %d users", count)
}}
生产部署时如何集成进运维流程
独立命令不是“二等公民”，它更适合生产环境：可被 systemd、supervisord 或 CI/CD 脚本直接调用，还能加权限控制、日志重定向、超时限制。
- 避免把命令逻辑塞进
revel run的 HTTP handler 里触发——这是反模式，HTTP 层不该承担后台任务 - 若需定时执行（如每天清理日志），用系统 cron 调用
bin/mytool --cleanup，而非依赖 Revel 的Job模块（它仅限内存级、无持久化、不保证执行） - 敏感操作（如数据库迁移）务必加
--confirm交互确认，或要求传入环境标识（--env=prod）防止误操作
真正容易被忽略的是环境初始化顺序：没调 revel.Init 就访问 revel.Config 会 panic，而错误信息只显示 nil pointer dereference，看不出根源。务必在 main() 开头就完成初始化，再碰任何 Revel 相关变量。
