Beego是基于八个可独立使用的模块构建的高度解耦框架，支持仅引入cache、config等特定模块；其路由必须在init()中静态注册，Controller需嵌入web.Controller以注入上下文，ORM默认N+1查询且事务需显式管理。
Beego 的模块化不是口号，是真实可拆的八个独立包
Beego 的核心架构不是“一个大框架”，而是八个功能明确、可单独 import 的模块。你不需要用完整框架，也能只拿 cache 做本地缓存，或只用 config 解析 YAML/INI 文件。这种设计直接影响你查文档和写代码的方式——别总盯着 beego 主包，先确认你要的功能属于哪个子模块。
常见误区是以为 beego.NewApp() 或 beego.Run() 是入口关键，其实真正驱动行为的是各模块的初始化顺序：比如 config 必须在 orm 之前加载，否则数据库连接字符串读不到；logs 模块若没提前配置，orm.Debug 打印的 SQL 就不会输出到控制台。
-
config：负责加载conf/app.conf，支持 INI、JSON、YAML，但默认只认 INI 格式，改其他格式需显式调用config.SetConfigType("yaml") -
orm：独立于 HTTP 生命周期，可直接在main()里初始化，不依赖beego.Run() -
cache：默认使用内存缓存，切换 Redis 需手动注册cache.Register("redis", &redis.Cache{})，不是改配置就能自动生效
Controller 不是普通 struct，嵌入 web.Controller 才有生命周期方法
新手常把自定义 Controller 写成普通结构体，结果 Get() 方法被调用时发现 c.Ctx 是 nil、c.Data 无法赋值——这是因为 Beego v2 要求必须嵌入 web.Controller（v1 是 beego.Controller），否则框架无法注入上下文对象。
这个嵌入不是语法糖，它触发了 Beego 内部的反射机制：框架在路由匹配后，会调用 web.Controller.Prepare() 初始化 Ctx、Data、Input 等字段。如果你重写了 Prepare() 却忘了调用 super.Prepare()（Go 里实际是显式调用 c.Controller.Prepare()），后续所有方法都会失效。
- 正确写法：
type UserController struct { web.Controller }，不是type UserController struct { controller web.Controller } - 不要覆盖
Init()或Prepare()而不调用父类实现，否则c.Input无法解析 query/body 参数 -
c.ServeJSON()默认开启json.Marshal，遇到 time.Time 字段会 panic，需提前设置beego.BConfig.Log.AccessLogs = false或自定义 JSON encoder
路由注册时机决定你能用什么功能
Beego 的路由不是“启动后才生效”，而是在 init() 函数里静态注册的。这意味着：所有 web.Router()、web.NSRouter()、web.NSInclude() 调用都必须发生在 main() 执行前，且不能放在闭包或延迟函数中。
常见坑是把路由逻辑封装进函数再调用，比如写个 SetupAdminRoutes() 然后在 main() 里执行——这会导致路由完全不生效，因为 Beego 只扫描 init() 里的注册语句。另一个问题是混淆了 web.Router() 和 web.NSRouter() 的参数含义：web.Router("/user/:id:int", &UserController{}, "get:GetUser") 中的 :id:int 是路径参数类型约束，而 "get:GetUser" 是方法映射，不是字符串拼接，写成 "get: GetUser"（带空格）就会静默失败。
- 所有路由必须在
routers/router.go的func init()中完成，不能动态生成 -
web.NSRouter()的命名空间路径（如/api/v1）会自动拼接到子路由前，但不会影响中间件作用域 - RESTful 路由（
web.NSInclude()）要求 Controller 方法名严格为Get()、Post()等，不能是HandleGet()
ORM 查询性能陷阱藏在 LoadRelated() 和事务边界里
Beego ORM 的 LoadRelated() 看似方便，但默认是 N+1 查询：查 10 条用户，再对每条用户单独查一次 profile，总共发 11 次 SQL。这不是 bug，是设计选择——它不自动做 JOIN，避免复杂关联导致的笛卡尔积爆炸。
真正影响线上性能的往往是事务没及时关闭。Beego ORM 的 o.Begin() 返回的 orm.TxOrmer 对象，如果在 defer 中调用 tx.Commit()，但中间发生 panic，tx.Rollback() 不会自动触发，连接会一直卡在事务中，直到超时断开。更隐蔽的问题是：同一个 orm.Ormer 实例在 goroutine 间复用，会导致 SetTablePrefix() 或 Using() 配置互相污染。
- 批量关联查询用
o.QueryTable("user").RelatedSel("Profile").All(&users)，不是for range users { o.LoadRelated(&u, "Profile") } - 事务必须显式配对
Commit()/Rollback()，推荐用defer func() { if r := recover(); r != nil { tx.Rollback() } }() - 每个 HTTP 请求应使用独立
orm.NewOrm()实例，不要在全局变量里存o
init() 里那几行路由注册是否写对、web.Controller 是否真的嵌入成功、以及 ORM 查询时有没有意识到自己正在发第 101 条 SQL。 
