公共服务应放在 app/services 目录；通过接口定义+构造函数注入实现依赖注入与测试隔离；涉及外部调用、事务、复用或复杂规则的逻辑须抽为服务；service 层不得直接访问 c.Params 或 c.Session，需由 Controller 显式传参。
公共服务该放在 app/ 的哪个目录
Revel 没有预设“service”目录，但约定优于配置，app/services 是最自然、最易协作的选择。它和 app/models、app/controllers 并列，语义清晰，不会被框架自动扫描或注入（避免意外初始化），也方便测试时单独 import。不要塞进 app/utils 或根目录下的 lib/——前者容易泛滥成杂货铺，后者在 revel package 时可能被遗漏。
如何让服务支持依赖注入与测试隔离
Revel 本身不提供 DI 容器，但你可以用构造函数参数 + 接口解耦实现轻量级可测性。关键不是“怎么注册”，而是“怎么传入”。
- 定义接口（如
type EmailSender interface { Send(to, subject, body string) error }） - 实现结构体（如
type SMTPSender struct { client *smtp.Client }） - 控制器中不 new 实例，而是通过字段接收：
type App struct { *revel.Controller EmailService EmailSender } - 在
app/init.go的init()函数里，用revel.InterceptFunc或自定义 Filter 注入实例（例如从配置读取 SMTP 地址后初始化SMTPSender，再赋值给每个App实例）
这样写，单元测试时可直接传入 mock 实现，无需启动 Revel 运行时。
哪些逻辑必须抽成服务，而不是写在 Controller 里
判断标准很直接：只要出现以下任一情况，就该拆。
- 调用了外部 HTTP API（如支付网关、短信平台）——避免 Controller 耦合网络细节和重试逻辑
- 涉及多步 DB 操作且需事务控制（如扣库存 + 写订单 + 发通知）——事务应由服务统一开启/提交，Controller 只管调用原子方法
- 需要复用到多个 Controller（如用户积分计算、内容审核策略）——重复代码是技术债的起点
- 包含非 trivial 的业务规则（如 “VIP 用户下单免运费但仅限当日首单”）——这类逻辑必须可独立测试、可灰度开关
注意：数据库查询本身（如 c.DB.Where(...).Find(&x)）不必硬抽，但围绕它的组合逻辑（比如“查出订单并校验状态是否可取消”）应该下沉。
为什么不要在 service 层直接访问 c.Params 或 c.Session
公共服务的目标是可复用、可脱离 HTTP 上下文运行（比如被定时任务或 CLI 命令调用）。如果 service 方法签名里出现 *revel.Controller 或依赖 c.Params.Get()，它就彻底绑定到一次 HTTP 请求生命周期里了。
正确做法是把必要参数显式传入：
- 错：
func (s *OrderService) CancelByRequest(c *revel.Controller) error - 对：
func (s *OrderService) Cancel(orderID uint, userID uint, ip string) error
Controller 负责解析 c.Params.Get("id")、c.Session.Get("user_id")，然后把干净的值传给 service。这层隔离看似多一步，实则换来长期可维护性。
