Go框架不抽象并发模型，仅封装调度细节；goroutine和channel是语言原生机制，HTTP框架如Gin/Echo默认为每个请求启一个goroutine，不干预调度，真正影响并发的是开发者在handler中对context、channel、sync等的使用。
Go 框架没抽象并发模型，它只封装调度细节
Go 语言本身不提供“框架级”的并发模型抽象——goroutine 和 channel 是语言原生机制，不是某框架定义的。所谓“Gin 并发”“Echo 并发”，本质都是直接复用 Go 运行时的 runtime.Gosched()、net/http 的 Handler 启动方式，框架层几乎不做额外调度干预。
常见误解是认为框架“实现了自己的协程池”或“重写了 channel 行为”，实际上：
- Gin/Echo/Chi 等 HTTP 框架的每个请求默认启动一个
goroutine，调用链全程不切换 goroutine，也不限制数量 - 没有框架会拦截
go func() {...}()或改写chan int的语义；它们无法、也不该这么做 - 真正影响并发行为的是你写的 handler 里是否用了
select、是否带缓冲make(chan T, N)、是否漏掉close()
HTTP 框架如何间接暴露并发风险
框架不控制并发，但它的默认行为会放大你代码里的并发缺陷。比如：
-
net/http默认为每个请求启动一个goroutine，如果你在 handler 里启动 10 个子goroutine去调下游，且未设超时或限流，瞬时并发可能从 1k 请求变成 10kgoroutine - Gin 的
c.Copy()不是线程安全的，若在多个goroutine中并发读写同一个*gin.Context，会 panic：concurrent map iteration and map write - Echo 的
c.Request().Context()返回的context.Context是绑定到当前请求生命周期的，但如果你把它传给长期运行的goroutine而没做context.WithTimeout()，就可能泄漏 goroutine
真正需要你决策的并发抽象点
框架不抽象，并不意味着你不用抽象。实际项目中必须手动补上的关键抽象有：
立即学习“go语言免费学习笔记（深入）”；
-
worker pool：用带缓冲chan func()+ 固定数量goroutine消费，避免下游服务被突发请求打垮 -
context.WithCancel()/context.WithTimeout()：所有跨 goroutine 的 IO 操作（如http.Do()、db.Query()）必须带上 context，否则超时和取消不可控 -
sync.WaitGroup+defer wg.Done()：仅用于等待已知数量的 goroutine，不要在循环里反复new(sync.WaitGroup)，容易内存泄漏 -
select配合time.After()或ctx.Done()：替代裸time.Sleep()，避免 goroutine 永久阻塞
别被 “框架并发支持” 宣传误导
文档里说 “Gin 支持高并发”，真实意思是 “Gin 不拖慢 Go 原生并发能力”。它不解决以下问题：
- 你没关
http.Client的Transport.MaxIdleConns，连接池耗尽后所有 goroutine 卡在 DNS 解析或 dial 阶段 - 你在 handler 里直接
log.Printf()写文件，而没加sync.Mutex或用log.SetOutput()切到线程安全 writer，导致日志错乱甚至 panic - 你用
map[string]int当缓存，多个 goroutine 并发读写，触发fatal error: concurrent map writes
这些都不是框架该管、也管不了的事。并发模型的边界始终在你写的那几行 go 和 chan 里，不在路由注册那行代码上。
