revel 框架不支持自动依赖注入，因其设计哲学强调轻量、显式、无魔法；依赖需在 app.init() 中手动构建并挂载到 revel.app，再于 controller.init() 中显式赋值。
Revel 框架本身不提供内置的、类似 Spring 或 Laravel 那样的自动依赖注入容器。它没有 @Inject 注解、没有服务注册表、也不扫描构造函数参数做反射注入。想在 Revel 中实现依赖注入，必须手动管理——不是“框架帮你注入”，而是“你把依赖准备好，再传进去”。
为什么 Revel 不支持自动 DI？
Revel 的设计哲学是轻量、显式、无魔法。它把控制器（Controller）当作普通 Go 结构体，不强制继承或实现接口，也不拦截实例化过程。这意味着：
- 框架不会调用你的构造函数，
new(APP)或&APP{}完全由你控制 - 没有全局服务容器，
app.Service这类字段必须你自己初始化 - 所有依赖都得在
app.Init()或控制器初始化阶段显式赋值
如何手动实现 Controller 层的依赖注入
最常用且可靠的方式：在 app.Init() 中构建依赖树，然后挂载到全局 revel.App 实例上，再在每个 Controller 的 Init() 方法中复制引用。
例如，假设有 UserService 和 DB 两个依赖：
// app/init.go
func Init() {
// 1. 构建依赖实例
db := sql.Open(...) // 或 gorm.Open(...)
userService := &UserService{DB: db}
// 2. 挂到 revel.App 上（全局单例）
revel.App.UserService = userService
revel.App.DB = db
}
// app/controllers/app.go
func (c APP) Init() revel.Result {
// 3. 手动“注入”：从全局取，赋给控制器字段
c.UserService = revel.App.UserService
c.DB = revel.App.DB
return nil
}
注意：c.UserService 必须是 APP 结构体的导出字段，且类型需匹配。
容易踩的坑：别在路由 handler 里 new 依赖
常见错误写法：
func (c APP) ShowUser() revel.Result {
svc := &UserService{DB: c.DB} // ❌ 每次请求都 new，状态/连接池无法复用
user, _ := svc.Get(c.Params.Get("id"))
return c.RenderJSON(user)
}
问题：
- 每次请求新建
UserService，丢失连接池复用、缓存、中间件等上下文 - 若
UserService含状态（如 session、logger），会导致数据错乱 - 违背 Revel 的“控制器无状态”原则——依赖应提前构造好，而非运行时拼装
进阶：用 Factory 函数封装依赖创建逻辑
当依赖构造复杂（如带配置、需要初始化顺序）时，建议抽成工厂函数，避免 Init() 变成面条代码：
func NewUserService(db *sql.DB, cfg Config) *UserService {
return &UserService{
DB: db,
Cache: redis.NewClient(...),
Logger: log.New(...),
}
}
func Init() {
db := setupDB()
revel.App.UserService = NewUserService(db, revel.Conf.Config)
}
这样既保持可测试性（工厂函数可单独单元测试），又让 Init() 保持清晰。
真正难的不是“怎么写注入代码”，而是决定哪些该作为依赖挂到 App 上、哪些该随请求生命周期创建（比如 Validator 或 Session）。后者通常通过 c.Session、c.Params 等 Revel 内置对象获取，不属于 DI 范畴——混淆这两类对象，是多数人卡住的关键点。
