beego本身不提供自动并发问题检测能力，真实场景中并发问题必须靠组合手段主动暴露和验证；单请求测试无法触发资源争抢，需高并发压测结合-race编译、db.stats()、pprof等工具综合诊断。
Beego 本身不提供自动并发问题检测能力，真实场景中并发问题（如连接池耗尽、goroutine 泄漏、竞态访问）必须靠组合手段主动暴露和验证。
为什么 go run main.go 启动时看不出并发问题
单请求测试完全无法触发资源争抢。Beego 的 web.Run() 底层基于 net/http.Server，默认用 goroutine 处理每个请求——但只有高并发压测时，连接池、缓存客户端、全局变量等才会暴露出竞争或泄漏。
- 本地
curl http://localhost:8080/api/user/1成功 ≠ 生产扛得住 500 QPS - 数据库连接数在
DB.Stats()里显示OpenConnections=2，不代表 100 并发下不会飙到 100+ - 没加
-race编译，写共享 map 或未加锁的计数器根本不会报错，只会偶发返回错误数据
用 go build -race 检查内存竞态
Go 自带竞态检测器是第一道防线，它能发现控制器、模型、中间件里对全局变量、结构体字段、map/slice 的非同步读写。
- 确保所有测试和压测都用
go build -race编译，再运行：./myapp - 常见误用点：在
Controller里直接赋值this.Data["count"] = globalCounter++——globalCounter必须是sync/atomic或加sync.Mutex - Beego 的
beego.BConfig是只读配置，但若你在中间件里动态改beego.BConfig.WebConfig.SessionOn，-race会立刻标记 - 注意：开启
-race后性能下降 2–5 倍，仅用于测试环境，禁止上生产
压测时盯紧 DB.Stats() 和 cache.GetCache().Stats()
连接池和缓存客户端的统计信息是判断是否“真并发安全”的硬指标，不能只看日志有没有报错。
- 在健康检查接口或后台定时任务里打印：
stats, _ := DB.DB().Stats(); log.Printf("db stats: %+v", stats) - 关键看三个字段：
OpenConnections（当前打开数）、InUse（正被使用的连接）、WaitCount（等待获取连接的总次数）——如果WaitCount持续上涨，说明连接池太小或连接没释放 - Redis 缓存同理：
redisCache.Stats()返回HitCount/MissCount，但更要关注Ping()耗时是否随并发升高；超时说明连接池打满或网络抖动 - 别依赖 Beego 日志里的 “SQL executed” 行数——它不反映连接是否归还，得看底层
*sql.DB的实际状态
用 pprof 抓 goroutine 泄漏和阻塞点
goroutine 数量持续增长、HTTP 请求响应延迟突增，大概率是某处没 defer rows.Close() 或事务没 Commit()，导致连接/资源长期占用。
- 启动时加
_ "net/http/pprof"，然后访问http://localhost:8080/debug/pprof/goroutine?debug=1 - 对比压测前后 goroutine 列表：如果大量卡在
database/sql.(*Tx).Commit或redis.(*Client).Do，就是事务或缓存调用没收尾 - 用
go tool pprof http://localhost:8080/debug/pprof/block查阻塞点，常见于未设 context timeout 的 HTTP 调用或无缓冲 channel 写入 - Beego 的
Prepare()方法里若含同步 I/O（比如没加ctx.SetTimeout()就调第三方 API），blockprofile 会清晰暴露
真正难定位的是“半泄漏”：连接池没爆满，但平均响应时间随并发线性上升——这往往源于某条 SQL 没走索引，或缓存 key 设计导致热点集中，得结合慢查询日志和 Redis slowlog get 交叉验证。
