beego并发能力“开箱即用”因其底层直接依赖go net/http的goroutine自动调度机制，每个http请求由独立goroutine承载，controller生命周期与请求绑定，天然无竞态；瓶颈通常在数据库连接池、慢sql、未设超时的外部调用等，而非goroutine数量本身。
Beego 本身不“处理”并发请求，它依赖 Go 原生的 net/http 启动方式 —— 每个 HTTP 连接由独立 goroutine 承载，这是默认行为，无需额外开启或配置。
为什么 Beego 的并发能力看起来“开箱即用”
因为底层调用的是 http.Serve，而 Go 标准库在 accept 后立即启动 goroutine 执行 serverHandler.ServeHTTP。Beego 的 Controller 实例就在这个 goroutine 中创建和运行，天然享受 Go 的轻量级并发模型。
你不需要手动 go c.Get() 或写 sync.WaitGroup 来“支持并发”，那样反而破坏框架生命周期，导致 context 泄漏、中间件失效、日志错乱。
- 每个请求独占一个 goroutine，Controller 是短命对象，生命周期与请求绑定
- Beego 的
Prepare()、Get()、JSON()等方法都在该 goroutine 内顺序执行，无竞态风险（除非你显式共享变量） - 高并发瓶颈通常不在 goroutine 调度，而在数据库连接池、文件句柄、内存分配或第三方服务响应上
真正需要你干预的并发瓶颈点
高频堆分配、慢 SQL、未设超时的外部 HTTP 调用、大文件上传未限制 —— 这些才是压垮服务的元凶，不是 goroutine 数量本身。
-
json.Unmarshal([]byte, &map[string]interface{})：接口类型强制逃逸，每秒千次解析会触发 GC 尖峰；改用预定义 struct，如type UserReq struct { Name string `json:"name"` } r.ParseMultipartForm(8 ：只限制内存缓存，攻击者可发 1KB 表单 + 99MB 文件绕过；必须前置加 <code>http.MaxBytesReader卡死总读取量- ORM 查询用
o.QueryTable("user").Filter("id", id).All(&users)：底层reflect.New频繁分配小对象；改用[]User接收，避免[]interface{} - 日志拼接写
log.Printf("req=%s, user=%v", r.URL.Path, u)：fmt.Sprintf必逃逸；换strings.Builder或结构化日志库
别碰 Listener 层限流，除非你真要防 DDOS
Beego 的 LimitRouter 是伪限流：它在 BeforeExec 阶段才运行，此时 TCP 连接已建立、TLS 已握手、请求头已读完 —— 恶意连接早已吃掉 fd 和内存。真正的全局限流必须下沉到 net.Listener.Accept() 后立刻判断，用 atomic.LoadInt64(&connCount) 计数，超限直接 conn.Close()。
- 禁用 Beego 自动启动：
beego.BConfig.Listen.EnableHTTP = false - 自己构造
http.Server，传入包装过的net.Listener - 不要在
Prepare()里 newrate.Limiter：每个请求建一个桶 = 内存泄漏 + 锁竞争 - 不要用单例
rate.Limiter全局共享：所有 IP 共用令牌，等于没限
并发本身不是问题，问题是让每个 goroutine 干得少、干得快、不拖泥带水。Beego 的 Controller 设计本就为此服务，但前提是别在它里面写逃逸代码、不控上传、不设超时 —— 这些细节，比“怎么开 goroutine”重要得多。
