beego路由匹配慢需检查是否误用正则路由：@开头正则会退化为线性扫描，应优先使用beego.restrouter走基数树；必须用正则时仅限低频管理路径，并开启dev模式路由调试日志定位耗时。
Beego路由匹配慢？检查是否误用正则路由
Beego默认用基数树（Radix Tree）做路由匹配，时间复杂度是 O(k)，性能很好。但一旦在路由里写 @ 开头的正则表达式（比如 /user/@([0-9]+)），就会退化为线性扫描，QPS 下降明显。
常见错误场景包括：用正则校验 ID 格式、匹配带版本号的 API 路径（如 /v1/users/:id 其实不需要正则，直接用 RESTful 动态参数即可）。
- 优先用
beego.RESTRouter("/api/users/:id", &controllers.UserController{})，它走基数树，不触发正则引擎 - 必须用正则时，确保只在少数管理后台路径中使用，避免出现在高频接口上
- 可通过
beego.BConfig.RunMode == "dev"下开启路由调试日志，观察Router matched的耗时
数据库查询卡顿？警惕 N+1 和 auto_now 副作用
ORM 层最常拖垮性能的两个点：一个是关联查询没预加载，另一个是字段配置不当引发无意义 UPDATE。
比如定义了 UpdatedAt time.Time `orm:"auto_now;type(datetime);null"`，哪怕只改了一个非时间字段，o.Update() 也会强制更新该字段，导致行锁竞争和 binlog 膨胀。
- 关联数据一律用
RelatedSel("profile")预加载，别在循环里调user.Profile - 时间字段按需选：
auto_now_add仅用于创建时间，auto_now慎用，高频更新表建议手动赋值UpdatedAt - 查列表时禁用
All(&slice)，改用Values(&slice, "id", "name")减少内存拷贝和 GC 压力
缓存命中率低？先确认驱动和 TTL 策略是否匹配业务
Beego 默认用内存缓存（memory 驱动），单机有效；但一上集群，缓存就失效——这不是 bug，是设计使然。很多人没意识到这点，还在用 cache.GetCache("memory") 做分布式会话缓存。
另外，TTL 设得太短（比如 5 秒）或太长（比如 24 小时），都会让缓存形同虚设：前者频繁穿透 DB，后者数据陈旧。
- 生产环境必须切到
redis驱动，并在conf/app.conf中配好cache.redis段 - 热点数据（如用户权限）用短 TTL（60–300 秒）+ 主动刷新机制；静态配置类用长 TTL（1 小时以上）+ 缓存预热
- 务必开启缓存统计：
beego.GlobalCache.Stat()，定期看Hits/Misses比值，低于 0.8 就得查原因
中间件阻塞请求？别在 Filter 里做同步 IO
Beego 的 Filter 是同步执行的，如果在 BeforeRouter 里调了 HTTP 请求、DB 查询或 Redis GET，整个 goroutine 就卡住，吞吐量直线下降。
典型反模式：在鉴权中间件里每次请求都查一次数据库验证 token；或者日志中间件里同步写文件。
- Token 校验必须走缓存（Redis），且加本地 LRU 内存缓存二级防护
- 日志写入交给异步 channel + 单独 goroutine 处理，Filter 里只做结构化打点
- 所有 Filter 函数开头加
ctx.Input.SetData("start_time", time.Now())，结尾用time.Since()打点，超 5ms 就要优化
auto_now 改成手动赋值后，订单表的 UPDATE 平均延迟从 18ms 降到 3ms。这些不是理论值，是凌晨三点被告警叫醒后亲手调出来的数字。缓存、路由、ORM、中间件——四个地方，每个细节松动一毫米，线上抖动就是十倍放大。
