Revel控制器必须直接或间接匿名嵌入*revel.Controller且作为结构体首字段，Action方法须导出并返回revel.Result，控制器仅协调取参、校验、调用服务与渲染，禁止直写响应或操作全局变量。
控制器必须嵌入 *revel.Controller，且必须是首字段
Revel 不识别任意 struct 为控制器，只认“直接或间接嵌入 *revel.Controller”的类型。最简写法就是：type AppController struct { *revel.Controller }。如果把 *revel.Controller 放在第二字段、或者用指针嵌套（比如 Ctrl *revel.Controller），RouterFilter 就找不到它，请求会 404 或 panic。
常见错误现象：
- 路由匹配成功，但执行时 panic："
nil pointer dereference" —— 很可能Controller字段没被初始化，即没按约定嵌入 - 访问
/app/ShowLogin返回 404 —— 检查app/controllers/app.go中 struct 定义是否满足首字段约束
Action 方法必须导出、返回 revel.Result
只有首字母大写的函数才被 Revel 视为可路由的 Action。它不能是私有方法（如 showLogin()），也不能返回 error、string 或 void。返回值必须是 revel.Result 类型，否则编译期不会报错，但运行时 ActionInvoker 无法调用它。
典型写法示例：
func (c AppController) Login() revel.Result {
// 从 c.Params.Get("username") 或 c.Params.Form.Get("password") 取参
// 调用 c.Validation.Required(...).Message(...) 做校验
if c.Validation.HasErrors() {
c.Flash.Error("用户名或密码错误")
return c.Redirect("/login")
}
c.Session.Set("user_id", "123")
return c.Render()
}
注意点：
- 参数名会自动绑定：URL 查询参数、表单字段、JSON body（需配合
ParamsFilter和 Content-Type）都会映射到同名参数，无需手动解析 - 不要在 Action 里直接写
c.Response.Out.Write(...)—— 这绕过 Revel 的 Result 流程，会导致 Flash/Session 不生效、压缩失效、日志不完整
业务逻辑应剥离到 models 或独立 service 包，控制器只做协调
Revel 的控制器不是放 SQL 或 HTTP 调用的地方。它只负责三件事：取参 → 校验 → 调用模型/服务 → 渲染或跳转。把数据库操作、第三方 API 调用、复杂计算塞进 Action，会导致测试困难、复用性差、热重载变慢。
推荐结构：
-
app/models/user.go：定义Userstruct 和FindById(id int) (*User, error)方法 -
app/services/auth.go：封装登录逻辑，含密码比对、token 生成、失败计数等 -
app/controllers/app.go：仅调用auth.Login(c.Params.Get("username"), c.Params.Get("password"))，再根据返回值决定跳转或渲染
这样做的好处：
- 单元测试可直接 import service/model，不用启动 Revel server
- 同一份业务逻辑能被 CLI 命令、定时任务、gRPC 接口复用
- 控制器方法保持短小（通常 ≤20 行），便于快速定位问题
别在控制器里直接操作 http.ResponseWriter 或全局变量
Revel 的 *revel.Controller 已封装了 Request 和 Response，所有响应都应通过 revel.Result 接口完成。直接调用 c.Response.Out.WriteHeader(401) 或 c.Response.Out.Write(...) 会破坏过滤器链行为 —— 比如 CompressFilter 不会压缩、FlashFilter 不会写 cookie、PanicFilter 无法捕获后续 panic。
同样，避免在控制器中读写全局变量（如 var db *sql.DB）。Revel 是并发安全的，每个请求都有独立 Controller 实例，但全局变量是共享的。多 goroutine 并发修改会导致数据竞争，尤其在启用热重载后，旧代码和新代码可能共存于同一进程。
真正需要跨请求共享的状态（如数据库连接池、Redis client），应在 app/init.go 的 init() 或 onAppStart 中初始化，并通过 revel.AppConfig 或自定义 context key 注入控制器，而不是硬编码引用。
