Revel框架要求严格遵循预设目录结构：app/controllers、app/models、app/views必须存在且名称大小写敏感，routes为唯一路由入口；Controller仅调度、Model封装业务规则、View纯渲染，扩展逻辑通过services、modules或Job分离。
在Revel框架中组织业务代码，必须严格遵循其预设的目录契约和生命周期约定，否则路由无法识别、依赖注入失效、热重载中断。
理解Revel默认项目结构
Revel不接受自定义目录名或路径别名。创建项目后，app/controllers、app/models、app/views 这三个目录必须存在且名称完全一致，大小写敏感。任何手动重命名（如把 controllers 改成 handler）会导致所有 HTTP 路由 404。
routes 文件是唯一入口路由表，所有控制器方法必须在此显式声明或通过 RESTful 自动映射规则匹配，不能靠反射自动扫描。
Controller 层：只做调度，禁止业务驻留
控制器文件必须放在 app/controllers/ 下，且类名以 Controller 结尾（如 AppController），方法名首字母大写（如 Index、CreateUser）。
方法体内只能做四件事：接收参数（c.Params、c.Params.Get）、调用 model 或 service 层方法、设置响应状态（c.RenderJSON、c.Redirect）、返回 View 或数据。绝不允许出现 SQL 查询、时间计算、字符串拼接等业务逻辑。
例如，用户注册操作中，密码哈希、邮箱唯一性校验、发送激活邮件这些步骤必须移出 Controller，放到 models 或独立 services 包里。
Model 层：业务规则的唯一出口
Revel 没有强制要求 Model 必须是 struct 或必须继承某基类，但推荐将每个核心实体建模为独立 Go struct，并在同文件中定义其行为方法。
方法命名采用动词+名词形式（如 User.Create、Order.Cancel），不使用 Set/Get 前缀。所有涉及数据变更的操作必须返回 error，Revel 的 panic 恢复机制会自动捕获未处理错误并返回 500。
注意：Model 文件中禁止直接 import "github.com/revel/revel" —— 这会造成循环依赖。需要访问配置、日志或缓存时，应通过 revel.AppConfig、revel.INFO 等全局变量间接获取，或通过构造函数注入依赖。
View 层：纯渲染，零逻辑分支
视图模板必须放在 app/views/ 目录下，路径需与控制器方法一一对应：AppController.Index → app/views/App/Index.html。
模板中只允许使用 Revel 提供的 SafeHTML、DateFormat、RenderBody 等安全函数，禁止执行 if 判断嵌套超过两层、禁止调用外部函数、禁止访问数据库句柄。复杂条件展示应提前在 Controller 中计算好布尔标志位传入。
例如，显示“已支付”或“待付款”按钮，不应在模板里写 {{if .Order.IsPaid}}…{{else}}…{{end}}，而应在 Controller 中设置 .ShowPayButton = !.Order.IsPaid，模板只做 {{if .ShowPayButton}}。
扩展业务逻辑：用 services 和 modules 分离职责
方法一：在 app/ 目录下新建 services/ 子目录，存放跨 Model 的协调逻辑。例如 PaymentService.Process 会同时调用 Order.Find、User.BalanceDeduct、Email.SendReceipt。
方法二：对可复用能力（如短信网关、第三方登录）封装为 module，放入 app/modules/，并在 conf/app.conf 中启用：module.sms=github.com/yourname/sms-module。模块内可通过 revel.InterceptMethod 注册前置/后置钩子。
方法三：使用 Revel 的 Job 系统处理耗时任务。比如用户注册成功后触发的欢迎邮件，不应阻塞 HTTP 响应，而应调用 revel.Jobs.Schedule(“send_welcome_email”, user.ID) 异步执行。
