客户端发包过快不会直接导致栈溢出，而是引发 goroutine 泄漏与失控增长，最终触发 OOM；错误日志中“stack exceeds 1000000000-byte limit”实为数万 goroutine 占满内存所致，需在入口层限流熔断并用信号量硬限并发。
客户端发包过快本身不会直接导致 goroutine 栈溢出，但会引发 goroutine 泄漏或失控增长，最终触发 oom（out of memory）——而错误日志里常被误标为 runtime: goroutine stack exceeds 1000000000-byte limit。这不是栈设小了，是几十万 goroutine 每个占几 kb，加起来把内存吃光了。
为什么“发包快”会炸内存而不是报错限流
典型失控行为：每个请求都无条件起一个 goroutine，且该 goroutine 内部存在阻塞点（如未设超时的 HTTP 调用、无缓冲 channel 写入、未监听 ctx.Done() 的循环），导致协程无法退出。goroutine 数量随请求线性上涨，StackInuse 持续飙升，但进程还没来得及 panic 就被系统 OOM Killer 干掉了。
- 现象：
top -p <pid>显示 RES 内存暴涨，runtime.NumGoroutine()从几百跳到数万 - 关键线索：/debug/pprof/goroutine?debug=2 里大量 goroutine 卡在
net/http.(*persistconn).readloop或select上 - 误区：以为调大
GOMAXPROCS或改栈大小能解决 —— 它只管调度线程数，跟单个 goroutine 是否泄漏完全无关
必须在入口层做硬拦截：HTTP handler 中限速+熔断
不能依赖下游服务兜底。要在最外层（如 Gin middleware、HTTP ServeMux handler）就掐住流量，避免请求进到业务逻辑前就 spawn 出一堆僵尸 goroutine。
- 用
golang.org/x/time/rate做每 IP 或全局 QPS 限制，超出直接返回http.StatusTooManyRequests - 对高频路径加并发数硬限：比如
sem := make(chan struct{}, 50)，进 handler 先select { case sem - 拒绝未带必要 header（如
X-Request-ID）或 User-Agent 异常的请求 —— 很多扫描器/压测工具不填这些，可低成本过滤
所有 goroutine 必须绑定 context 并设超时
哪怕只是日志上报、指标打点这类“辅助操作”，只要启了 goroutine，就必须传 ctx 并检查 ctx.Done()。否则主请求已返回，后台 goroutine 还在慢悠悠跑，积少成多就是泄漏。
- 错误写法：
go sendMetric(data)—— 没 context，没超时，没 cancel 监听 - 正确写法：
go func(ctx context.Context) { select { case - 特别注意：
http.DefaultClient.Do(req)不响应ctx.Cancel，必须用http.Client{Timeout: 3*time.Second}或显式构造带Context的 request
上线前必查的三个泄漏信号
不是等报警才看，每次发布后 5 分钟内手动验证：
- 访问
/debug/pprof/goroutine?debug=2，搜索select和chan receive，看是否有固定 pattern 的长尾 goroutine - 执行
curl -s localhost:8080/debug/pprof/heap | go tool pprof -http=:8081 -，观察inuse_space是否随请求稳定上升 - 在代码里埋点：
log.Printf("goroutines: %d", runtime.NumGoroutine())，对比请求前后差值，非零即可疑
真正难防的不是发包快，而是某个 goroutine 里藏着一个没设超时的 conn.Read()，或一个忘了 close() 的 channel —— 它们不会立刻崩，但会在高负载下悄悄拖垮整台机器。
