Beego的MVC是强制性结构约束：模型须init注册、控制器须继承beego.Controller且Prepare()为前置入口、视图路径由框架硬编码决定，违者将panic或404。
Beego 的 MVC 不是概念包装，而是真实影响你 daily coding 的结构约束——模型层必须注册、控制器要继承 beego.Controller、视图模板路径由框架硬编码决定。不按这套走，orm.QueryTable 会 panic，this.TplName 会 404，路由注解会失效。
Model 层：结构体注册不是可选动作
Beego ORM 要求所有模型结构体必须在 init() 函数中显式调用 orm.RegisterModel()，否则后续任何 QueryTable("xxx") 都会报 table xxx not registered 错误。
常见错误现象：
- 结构体定义了但没注册，运行时报错：
panic: table user not registered - 注册了但包导入顺序错乱，导致
init()未执行（比如 models 包没被任何地方 import）
实操建议：
- 每个
models/*.go文件末尾加func init() { orm.RegisterModel(new(User), new(Order)) } - 避免把模型定义和注册拆到不同文件；注册必须紧贴结构体定义所在包
- 如果使用 bee 工具生成模型（
bee generate model user），它会自动补全注册逻辑，但手动改结构体后需确认注册列表是否同步
Controller 层：Prepare() 是权限/日志的唯一入口点
beego.Controller 的 Prepare() 方法会在每个请求进入具体 Action 前自动调用，它是做前置校验、参数预处理、上下文注入的**事实标准位置**。别试图在每个 Get() 或 Post() 里重复写 session 检查或日志打点。
使用场景：
- 统一鉴权：检查
this.GetSession("uid") == nil后直接this.Abort("401") - 参数预加载：从 URL 或 body 解析 ID 并查库，存入
this.Data["user"]供模板直接用 - 跨方法共享变量：比如设置
this.startTime = time.Now()，在Finish()里打耗时日志
容易踩的坑：
- 重写
Prepare()但忘了调用super.Prepare()（Beego 没 super，实际是没调用父类逻辑）——会导致 session、xsrf 等内置功能失效 - 在
Prepare()里调用this.StopRun()或this.Abort()后，仍继续写后续逻辑，可能引发 panic - 误以为
URLMapping()或路由注解能绕过Prepare()——不能，所有匹配到的请求必经此关
View 层：TplName 和 layout 依赖固定目录与命名约定
Beego 渲染模板时，默认从 views/ 目录下找文件，且 this.TplName 必须是相对路径（不含扩展名），例如设为 "user/list"，框架会自动拼成 views/user/list.tpl。不遵守这个约定，就会 404。
参数差异与兼容性影响：
-
app.conf中viewspath可改，但改完所有TplName字符串也得同步更新，容易漏 - 模板继承靠
{{define "layout"}}{{template "content" .}}，但layout.tpl必须放在views/根目录，子目录里的base.tpl不会被自动识别 - 静态资源路径（如
/static/css/app.css）和模板路径无关，但开发者常混淆二者，导致 CSS 加载失败后误以为是模板渲染问题
实操建议：
- 初始化项目时就确认
views/目录存在，且app.conf中viewspath = "views"未被注释或覆盖 - 所有
TplName值统一用小写字母+短横线，避免大小写混用（Windows 开发机可能不敏感，Linux 服务器必 404） - 不要在控制器里拼接完整路径传给
TplName，框架不支持"./views/user/detail.tpl"这种写法
路由与 Controller 绑定：Router() 和 @router 注解不可混用
Beego 支持两种路由注册方式：代码中调用 beego.Router()，或在 controller 方法上加 // @router /api/users [get] 注释。但二者底层共用同一张路由表，**混用会导致行为不可预测**——比如注解路由被 Router() 覆盖，或反向路由 urlfor 找不到方法名。
性能影响：
- 纯注解方式启动慢一点（需要扫描所有 controller 文件的注释），但热重载友好；纯
Router()方式启动快，但路由逻辑散落在各处 - 使用
bee run -downdoc=true自动生成 Swagger 文档时，只识别注解，Router()定义的接口不会出现在文档里
关键判断：
- 新项目建议统一用注解，尤其当团队有 API 文档协作需求时
- 遗留项目若已大量使用
Router()，不要中途切注解，除非重写整个 routers 包 - 无论哪种方式，控制器方法名必须首字母大写（Go 导出规则），否则
urlfor无法反射获取
最易被忽略的一点：Beego 的 MVC 分层不是靠目录物理隔离，而是靠运行时对象职责绑定。删掉 controllers/ 目录但把 controller 结构体写进 main.go，只要正确注册路由并继承 beego.Controller，它依然工作——但你会失去 bee 工具链的所有支持，包括热重载、测试生成和文档提取。
