Beego 报错无堆栈、404 无提示、ORM panic 找不到模型，主因是框架隐式行为：默认 recover panic、不记录未匹配路由、依赖显式导入和初始化顺序；需调高日志级别、启用行号、检查路由注册、确保模型包被 import 且 init 执行。
Beego 应用报错但日志没堆栈、页面 404 却没提示路由未匹配、ORM 报 panic 却找不到模型定义位置——这些问题基本都出在框架的“隐式行为”上，而不是代码写错了。排查关键不是看错误信息字面意思，而是确认三件事：是否触发了框架的默认 fallback 逻辑、是否漏掉了强制注册/导入环节、是否错误类型被中间件或 ORM 层吞掉了。
为什么 Beego 日志里看不到 panic 堆栈？
Beego 默认会 recover 大部分 panic，并转为 500 响应且只打一条 WARN 日志，原始 panic 被吃掉。你看到的 panic: table user not registered 可能只出现在启动日志里，运行时的 panic 则完全静默。
- 必须在
conf/app.conf中显式设置loglevel = 4（Debug 级别），否则 recover 后的日志被降级丢弃 - 在
main.go开头加beego.BeeLogger.EnableFuncCallDepth(true)，让日志带行号 - 若用
bee run，它自带 recovery 中间件，会拦截 panic；生产打包后（bee pack）才暴露原始 panic，更适合定位 - 自定义 panic 捕获：在
app.conf中设RecoverPanic = false，让 panic 直接崩掉进程并输出完整堆栈（仅限开发环境）
404 错误却没提示“路由未匹配”，怎么定位？
Beego 的路由匹配失败时，默认不打任何日志，直接返回 404。你访问 /api/user 报 404，但不确定是路由没写、控制器没 import，还是方法名大小写错了。
- 开启路由调试：在
main.go中加beego.BeeLogger.Info("router: %s", beego.BeeApp.Handlers)，启动时能看到所有注册的路由树 - 检查控制器是否被 import：Beego 不扫描文件系统，
controllers/下的文件必须被某个包显式import，否则AddAuto根本不会加载它 - 确认方法名首字母大写：如
Get()、Post()可被路由调用，getUser()（小写）会被跳过且无提示 - URL 路径末尾斜杠敏感：
beego.Router("/user", &UserController{})不匹配/user/，需显式写成/user/:?或启用AutoRender = true
ORM 报 table xxx not registered 但模型明明写了
这个 panic 表面是 ORM 问题，实际是 Go 初始化顺序和包导入链断裂导致的。模型结构体定义了，init() 函数也写了，但没被执行。
- 检查
models/包是否被任何地方 import：哪怕只是_ "myapp/models"，否则 Go 不会执行其init() - 确认
orm.RegisterModel()调用紧贴结构体定义所在文件，不要拆到单独的register.go里 - 避免循环 import：比如
controllersimportmodels，models又 importcontrollers，会导致初始化中断 - 用
bee generate model user生成的模型自带init()，但手动改结构体后必须检查注册列表是否同步更新
死锁错误 Deadlock found when trying to get lock 被日志吞掉
MySQL 死锁错误码 1213 默认被 Beego ORM 当作普通 error 处理，不打 ERROR 级别日志，也不触发 panic，很容易被忽略。
- 必须主动检查日志中是否含
Deadlock found、rollback、transaction begin三个关键词，且时间戳接近 -
orm.Debug = true必须配合loglevel = 4才生效，否则 SQL 日志被过滤 - 不要依赖
defer o.Rollback()—— 若事务已被 MySQL 自动回滚，再次调用会报sql: transaction has already been committed or rolled back - 重试逻辑必须包裹整个事务：
for i := 0; i
最常被忽略的一点：Beego 的错误处理链条太长，从 HTTP handler → middleware → controller → orm → database，每一层都可能吞掉或降级错误。排查时不要盯着最后一行错误文本，而要顺着日志时间戳和 goroutine ID，把整条请求链的日志串起来看。
