Beego 无原生 DI 容器，推荐使用 Wire 编译期注入：需正确安装、将 wire.go 置于 main 包同级目录，依赖须在 beego.Run() 前初始化；控制器不可直接注入依赖，应通过 *App 结构体传递；须禁用自动路由扫描并显式注册，所有 Router 调用必须在 Wire 初始化后、Run 前执行。
Beego 本身不提供原生依赖注入容器，必须借助第三方库（如 Wire）或手动管理，否则容易出现初始化顺序混乱、单例失效、测试难 mock 等问题。
Wire 是目前 Beego 项目中最可行的依赖注入方案
Beego 没有像 Spring 或 fx 那样的运行时 DI 容器，wire 属于编译期代码生成型工具，它不引入运行时开销，也避免了反射带来的不确定性。它适合 Beego 这类强调启动确定性、部署轻量的框架。
- 安装必须用
go install github.com/google/wire/cmd/wire@latest，不能只go get—— 后者不会把wire可执行文件放进$GOBIN，导致后续wire gen找不到命令 -
wire.go文件需放在与main.go同级目录，且包名必须是main，否则wire无法解析InitializeApp等入口函数 - Beego 的
app.Run()是阻塞调用，所有依赖（如数据库连接、RabbitMQ client）必须在Run()前完成初始化；wire生成的InitXXX()函数正好承担这个职责 - 不要在
init()函数里构造依赖对象 ——init执行时机不可控，可能早于配置加载，导致beego.AppConfig.String("db::url")返回空字符串
Beego 控制器不能直接接收依赖实例
Beego 的控制器由框架通过反射创建（reflect.New(cType)），它不会读取构造函数参数，也不支持接口注入。所以你不能写 type UserController struct { svc *UserService } 并期望框架自动赋值。
- 正确做法是把依赖挂到全局变量或通过
beego.AppConfig注入上下文 —— 但更推荐用wire构建一个*App结构体，把所有服务作为字段，在main()中传给控制器方法或封装进自定义基类 - 例如：定义
type App struct { DB *orm.Ormer; Cache *cache.Cache; UserService *UserService }，再让每个Controller持有*App字段，而非各自声明依赖 - 若强行在
Controller的Prepare()里做依赖查找，会破坏无状态性，导致并发下数据错乱或 panic
Wire + Beego 路由注册要避开自动扫描陷阱
Beego 默认启用 beego.BeeLogger 和 beego.Router 的自动发现机制（如 bee run 时扫描 controllers/ 目录），但 wire 生成的依赖图不参与该扫描流程，容易造成路由注册和依赖初始化脱节。
- 禁用自动路由扫描：在
conf/app.conf中设autoregister = false，改用显式注册，例如beego.Router("/user", &controllers.UserController{}, "get:Get;post:Post") - 所有
Router调用必须放在wire初始化完成之后、beego.Run()之前，否则UserController内部引用的App字段还是 nil - 别把
beego.Router写在init()函数里 —— 此时wire还没运行，App实例不存在，会导致 panic - 如果用了
beego.NSRouter或beego.NSCond，它们的闭包捕获的变量也必须来自wire构建的对象，不能是局部变量或未初始化的指针
Wire 生成的代码可读性差、调试困难，一旦 BuildProviderSet 中漏掉某个依赖，错误只在运行时报 nil pointer dereference，没有明确提示缺哪个实例 —— 务必在 CI 中加入 wire check 步骤，并为每个 Provider 函数加单元测试验证非 nil。
