beego 项目重构核心是解决控制器膨胀、模块复用难、测试成本高三大痛点，关键在于切断 controller 对 models/cache/logs 的隐式强依赖，通过接口注入、配置封装、路由解耦及生命周期明确管理实现真正解耦。
Beego 项目重构不是为了“看起来更现代”，而是为了解决控制器膨胀、模块复用困难、测试成本高这三类真实痛点。直接拆分 controllers 目录或重命名包名没用，关键在切断 Controller 对 models、cache、logs 的隐式强依赖。
Controller 不该直接 new model 或调用 cache.NewCache
常见错误是让 UserController 里直接 new(models.UserModel) 或 cache.NewMemoryCache()。这导致：单元测试时无法 mock 数据源；切换 Redis 缓存需改所有 controller；ORM 模型变更引发连锁编译失败。
正确做法是把依赖注入到结构体字段：
type UserController struct {
beego.Controller
UserModel models.UserModelInterface // 接口而非具体实现
Cache cache.CacheInterface // 同上
Logger logs.BeeLogger // 避免全局日志实例
}
启动时统一注入（例如在 main.go 的 init() 中）：
- 用
beego.AppConfig.String("cache::driver")读配置决定实例化cache.NewRedisCache还是cache.NewMemoryCache - 用
orm.RegisterModel(new(models.User))注册模型，但 controller 只通过接口操作 - 避免在 controller 方法里做
if err != nil { logs.Error(...) }，应交由中间件或统一 error handler 处理
把 config、log、cache 模块从 beego 全局实例中剥离
很多老项目直接用 beego.BeeLogger.Info() 或 beego.AppConfig.String("db::host")，看似方便，实则埋下耦合雷：一旦要替换日志库为 zerolog，就得 grep 全局改几百处；配置格式从 ini 切到 yaml 时，AppConfig 就失效。
建议做法：
- 在
core/config下封装自己的LoadConfig()，返回结构体而非beego.ConfigContainer - 日志模块用
logs.NewLogger()创建独立实例，传给需要的 service，不复用beego.BeeLogger - 缓存模块初始化后保存在
core/cache/instance.go的包级变量里，controller 通过函数获取：cache.GetInstance().Get("key")，而非直接 import beego 包
路由注册与 Controller 解耦：避免硬编码路径
写死 beego.Router("/api/v1/users", &controllers.UserController{}, "get:List") 会让路由逻辑和 controller 绑死，新增版本号或切流量时得手动改所有路由行。
可行方案：
- 用
beego.GlobalControllerRouter配合约定命名：比如controllers.UserControllerV2自动注册到/api/v2/users - 把路由规则提取到
router/rules.go，用 map 结构定义路径、方法、handler 映射，启动时循环注册 - 对高频变更的接口（如支付回调），用
beego.Handler("/notify/*", &handlers.NotifyHandler{})替代传统 router，避免每次加字段都动 controller 结构
真正难的不是“怎么拆”，而是拆完之后各模块的生命周期管理——比如 cache 实例该在 main 初始化还是随 controller 每次新建？日志 writer 是共用一个 file handle 还是每个 service 独立？这些细节不明确，解耦就只是目录结构调整而已。
