直接用 goroutine 处理大量请求会因失控并发导致内存耗尽、调度风暴、OOM 等问题；必须用信号量（如 semaphore.NewWeighted）在业务执行层限流，并配合 context、超时、连接层防护与 panic 恢复保障稳定性。
为什么直接用 goroutine 处理大量请求会崩
不加控制地为每个请求起 goroutine，在 QPS 上千时极易耗尽内存或触发调度风暴。Go 运行时无法优雅处理数万级并发 goroutine 的抢占与栈分配，常见现象是 RSS 暴涨、GC 频繁停顿、runtime: failed to create new OS thread 报错，甚至进程被 OOM killer 杀掉。
关键不是“能不能并发”，而是“谁来决定并发多少”——必须把并发权收归可控的调度层，而非放任 HTTP handler 自由 spawn。
- 默认 HTTP server 每个连接一个 goroutine，但连接数 ≠ 有效请求数；TCP 连接可能空闲、慢速、恶意保活
-
http.Server.ReadTimeout和WriteTimeout只管单次读写，不管整个请求生命周期 - 真正需要限流的是业务逻辑执行环节，比如调用下游 DB 或 RPC，而非 Accept 阶段
用 semaphore 控制并发执行数（最简可靠方案）
用 golang.org/x/sync/semaphore 实现信号量限流，比 channel 手动计数更轻量、无泄漏风险，且支持带上下文的 acquire。
var sem = semaphore.NewWeighted(100) // 允许最多 100 个并发执行
<p>func handler(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
if err := sem.Acquire(ctx, 1); err != nil {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
defer sem.Release(1)</p><pre class="brush:php;toolbar:false;">// 这里放真实业务逻辑：DB 查询、RPC 调用等
result, err := doHeavyWork(ctx)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
json.NewEncoder(w).Encode(result)}
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 数值 100 不是拍脑袋定的，应基于压测：观察 P95 响应时间拐点 + GC pause 稳定区间
- 务必用
ctx传入Acquire，否则超时请求仍会卡住信号量 - 不要在
Acquire前做任何重操作（如解析大 body），否则限流失效
结合 http.Server 的 ConnContext 和 IdleTimeout 做连接层防护
信号量管业务执行，而连接本身需防慢连接、长连接堆积。靠 http.Server 原生字段就能筛掉大部分无效压力。
srv := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
ConnContext: func(ctx context.Context, c net.Conn) context.Context {
// 可在此注入连接级 traceID 或限流标记
return context.WithValue(ctx, connKey, c.RemoteAddr().String())
},
}-
IdleTimeout是关键：防止客户端建连后不发数据，长期占着 fd 和 goroutine -
ReadTimeout必须设，否则 POST 大 body 上传卡住时，goroutine 一直挂起 - 避免在
ConnContext中做同步阻塞操作（如 DB 查询），它运行在 accept goroutine 中
别忽略 panic 恢复和 context 取消传播
高并发下 panic 更容易引发雪崩，而没检查 ctx.Err() 会导致 goroutine 泄漏——这两点在线上事故中占比极高。
- HTTP handler 必须包一层
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }() - 所有下游调用（
db.QueryContext、http.Do、time.Sleep）都必须传入原始r.Context()，不能用context.Background() - 自定义中间件里若用
context.WithTimeout，记得用defer cancel()，否则 timeout 后 context 仍存活
真正难的不是写限流代码，而是让每个函数、每条调用链都尊重 context 生命周期，并在 panic 后不破坏信号量状态——这需要持续 code review 和故障演练验证。
