Beego 2.0 性能瓶颈主要在 json.Marshal 和 Redis 访问，尤其多次 Get+Unmarshal 拼装数据时；需关闭调试模式、禁用 AutoRender、正确注册 pprof 路由、用 Values() 替代 All()、复用 Redis 连接池。
Beego 2.0 在压测中 CPU 拉满、QPS 上不去，基本就是 json.Marshal 和 Redis 访问在拖后腿——尤其当你还在用多次 Get + Unmarshal 拼装数据时，框架本身几乎不背锅。
压测前必须关掉的 Beego 调试开关
Beego 默认开启调试模式（beego.BConfig.RunMode == "dev"），这会导致：日志全量输出、路由参数自动校验、模板重载、颜色化控制台输出。实测会让空接口 QPS 腰斩。
- 启动前加
beego.SetMode(beego.PROD)，或确保配置文件中runmode = prod - 检查
conf/app.conf是否残留copyrequestbody = true——这个会强制读取并缓存整个请求体，对大 Body 接口是隐形 CPU 杀手 - 禁用
beego.BConfig.WebConfig.AutoRender = true，纯 API 服务不需要模板渲染，留着它只会多一次反射调用
pprof 抓不到真实热点？检查你的 /debug/pprof 路由注册方式
Beego 2.0 的 pprof 需要手动挂载，但很多人只注册了 /debug/pprof，漏掉了带参数的子路径（如 /debug/pprof/profile），导致 go tool pprof 直接报 404 或返回 index 页面。
- 务必注册两个路由：
beego.Router("/debug/pprof", &controllers.ProfController{})和beego.Router("/debug/pprof/:app([\w]+)", &controllers.ProfController{}) -
ProfController.Get()中必须显式调用pprof.Profile(c.Ctx.ResponseWriter, c.Ctx.Request)等函数，不能只靠pprof.Index—— 否则profile、trace等子命令无法触发采样 - 压测时用
curl "http://host/debug/pprof/profile?seconds=30"手动触发，比等自动采集更可控
JSON 序列化成瓶颈？别急着换框架，先看你怎么用 orm
Beego ORM 的 QueryTable().All() 默认返回完整 struct，哪怕你只用其中 2 个字段，也会把整张表字段反序列化进内存；再加上循环里反复 json.Marshal，CPU 就被吃死了。
- 用
Values()或ValueList()替代All()，只取需要的字段：o.QueryTable("user").Filter("status", "active").Values(&users, "id", "name", "email") - 避免在 for 循环内调用
json.Marshal—— 改成预分配 slice，一次性json.Marshal([]interface{}{...}) - 如果返回结构固定，考虑用
encoding/json的structtag 显式控制字段（如json:"id,string"），减少运行时反射开销
Redis 连接池没效果？检查你是不是每次请求都 new client
Beego 自带的 cache.RedisCache 是单例，但很多人在 controller 里写 redis.NewCache(...)，导致每次请求新建连接池，既浪费资源又触发大量 GC。
- 全局初始化一次：
var redisCache cache.Cache = cache.NewCache("redis", `{"key":"myapp","conn":"127.0.0.1:6379"}`) - 不要在
Get()方法里重复cache.NewCache，也不要直接 newredis.Client - 确认
maxidle和maxactive配置合理（如"maxidle":10,"maxactive":50），过小会排队，过大则内存浪费
Beego 的性能瓶颈从来不在路由或中间件调度上，而在于你是否让 ORM 和 JSON 处理暴露在高频路径里——这些操作的耗时通常是框架层的 10 倍以上。pprof 抓到的 top 函数如果不是 runtime.mallocgc 或 encoding/json.(*encodeState).marshal，那大概率是你还没真正压到它的极限。
