Beego多模块项目需明确模块边界、单向依赖和可控初始化：按数据主权划分模块，接口通信代替直连，显式控制初始化顺序，路由隔离注册，依赖注入替代包级引用。
Beego 多模块项目不是靠“加目录”就能撑起来的，核心在于模块边界是否清晰、依赖是否单向、初始化顺序是否可控。盲目套用 modules/user 这类目录名，却让订单模块直接 new UserDAO 或调用用户登录逻辑，迟早会演变成循环 import 和启动 panic。
模块目录命名必须反映职责边界，而非功能名词
很多人一上来就建 modules/user、modules/order，但很快发现 order 里要查用户昵称、user 里又要发订单通知——这不是模块化，是目录套娃。真正的模块划分应基于「谁拥有数据主权」和「谁承担变更成本」：
-
modules/auth：只管认证态（token 签发/校验、session 管理），不碰用户资料字段 -
modules/profile：只管用户资料读写（头像、昵称、收货地址），不处理登录态或权限判断 -
modules/order：只管订单生命周期（创建、支付、发货），通过接口（如profile.UserBrief()）获取必要用户信息，绝不直接 import profile 的 model 或 dao
模块间通信必须走定义好的 interface，而不是结构体或具体实现。比如 order 模块声明 type UserProfileGetter interface { GetUserBrief(id int64) (*UserProfile, error) }，由主程序在初始化时注入真实实现。
模块初始化顺序必须显式控制，不能依赖 import 顺序
Beego v2 的 app.Run() 启动流程中，init() 函数执行顺序不可控。如果 modules/order/init.go 里写了 func init() { db.Table("orders").AutoMigrate(&Order{}) }，而 modules/profile/init.go 也做了类似操作，极可能因 import 顺序不同导致 migrate 执行错乱，甚至 panic。
- 所有模块的初始化逻辑必须收敛到一个明确入口，比如
app/modules/loader.go中的LoadModules() - 每个模块提供
Register(*App)方法（*App是你封装的全局应用上下文），由LoadModules()按需调用，顺序可读、可测、可调试 - 数据库迁移、配置加载、服务注册等重操作，统一放在
Register()内，且必须检查前置依赖是否已就绪（例如：if !app.IsDBReady() { panic("db not ready") }）
路由注册必须隔离到模块内部，禁止集中写在 routers/router.go
把所有 beego.Router() 堆在 routers/router.go 里，等于把模块边界焊死在入口文件上。后期新增模块时，既要改目录结构，又要翻出这个大文件找位置，极易冲突。
- 每个模块提供
SetupRouter(*beego.ControllerRegister)方法，例如auth.SetupRouter(c)注册/login、/logout - 主
router.go只做两件事：调用modules.LoadModules()，再遍历模块列表调用其SetupRouter() - 若需分组前缀（如
/api/v1/users），由模块自己决定是否加c.NS("/api/v1", ...)，主路由不干预
这样改一个模块的路由，只需动该模块自己的文件，CI/CD 时还能做精准 diff 和灰度发布。
跨模块调用必须走接口+依赖注入，严禁包级直连
这是最容易被忽略、也最致命的一点。看到 models.User 在 modules/profile/models/user.go 里，就以为其他模块可以 import "myapp/modules/profile/models" 直接用——这等于把模块内实现细节暴露给所有人，下次 profile 模块重构字段名或拆表，所有引用处全崩。
- 对外暴露的类型必须是 interface，且定义在模块顶层（如
modules/profile/service.go中的type UserService interface { GetUserByID(int64) (*UserDTO, error) }） - 具体实现（含 DAO、model、ORM 调用）全部放在
internal/子目录下，对其他模块不可见 - 主程序初始化时，用构造函数或选项模式将实现注入接口变量，例如：
order.NewService(profileSvc, paymentSvc)
Beego 本身不提供 DI 容器，但你可以用一个轻量 app.Container 结构体管理依赖。比起强行塞进框架生命周期，自己掌控初始化链路更可靠、更易 debug。
