Beego性能优化需优先关闭文档自动生成并设RunMode=prod；避免ORM的N+1查询和全字段加载，显式预加载关联数据；合理配置缓存驱动与TTL；禁用正则路由，精简中间件；静态资源交由Nginx处理；手动防御缓存穿透与热key击穿。
Beego 的性能瓶颈通常不在框架本身，而在于 ORM 查询、缓存滥用、路由误配和中间件阻塞。直接优化前先确认：是否已用 bee run -downdoc=true 关闭文档自动生成？是否在生产环境启用了 RunMode = prod？这两项不做，其他优化效果打五折。
避免 ORM 的 N+1 查询和全字段加载
Beego ORM 默认不预加载关联数据，RelatedSel 被忽略或漏写是高频性能杀手。比如用户列表页查 100 条用户再逐条查头像，DB 连接数瞬间飙高。
- 必须显式调用
RelatedSel("avatar")或LoadRelated(&user, "avatar")，不能依赖结构体 tag 自动加载 - 禁止无条件使用
All()，改用Values()或ValueList()只取 ID 和关键字段，例如：o.QueryTable("user").Limit(20).Values(&users, "id", "name", "status") - 批量更新/插入务必用
InsertMulti()或UpdateMulti()，单条循环调用Insert()在 1000 条数据时慢 8 倍以上
合理配置缓存驱动与 TTL 策略
Beego 的 cache 模块默认用内存驱动（memory），但没设最大容量和淘汰策略，长期运行后 GC 压力陡增。Redis 驱动又常因连接池配置不当反成瓶颈。
- 内存缓存必须设置
CacheSize（如1000）和AdapterConfig中的key_filed避免 key 冲突 - Redis 缓存要显式配置
ConnMaxLifetime和PoolSize，例如：{"conn_max_lifetime":3600,"pool_size":50}，否则连接泄漏导致超时 - 对“状态类”数据（如配置、权限菜单）用长 TTL（
3600），对“计数类”数据（如阅读量）用短 TTL（60）并配合主动更新，别依赖被动过期
路由匹配与中间件链的精简
Beego 路由底层用 Radix Tree，但正则路由（@ 开头）会退化为线性扫描；中间件若含同步 I/O（如未加 context 超时的 HTTP 调用），整条请求链就卡死。
立即学习“go语言免费学习笔记（深入）”；
- 禁用
@正则路由，改用参数化路由（如/api/v1/users/:id）和控制器内手动校验，性能差 3–5 倍 - 所有中间件必须包裹
ctx.SetTimeout()，尤其日志中间件里禁止直接调用time.Now().Format()，改用ctx.Input.CruTime - 静态资源（CSS/JS）务必通过 Nginx 服务，Beego 的
StaticDir在高并发下 CPU 占用率飙升，实测 QPS 超 2000 后响应延迟翻倍
真正难处理的是缓存穿透和热 key 击穿——Beego 本身不提供布隆过滤器或本地热点缓存，得自己在 Controller.Prepare() 里加一层轻量判断，或者用 Redis 的 SETNX + EXPIRE 组合兜底。这点文档很少提，但线上事故八成出在这儿。
