客户端发包过快不会直接导致栈溢出，但会无节制创建goroutine，引发内存爆炸式增长，最终OOM被杀；根本原因是并发失控，而非栈大小，需在HTTP handler入口用rate.Limiter限流并配context超时、容器memory.limits与GOMEMLIMIT组合防御。
客户端发包过快本身不会直接导致 Goroutine 栈溢出，但会触发无节制的 goroutine 创建，最终引发内存爆炸式增长——此时报错常是 runtime: goroutine stack exceeds 1000000000-byte limit 或被 OOM Killer 杀死，而非“连接拒绝”或“限流提示”。关键不在栈大小，而在并发失控。
为什么加 GOMAXPROCS 或调大栈根本没用
网上很多方案建议改 GOMAXPROCS 或设 GOMEMLIMIT，但这两者完全不解决发包过快问题：GOMAXPROCS 控的是 OS 线程数，不影响 goroutine 创建数量；GOMEMLIMIT 只管堆内 GC，对 channel、stack、mmap 分配毫无约束。发包过快时，每个请求 spawn 一个 goroutine，若没熔断机制，1 秒 5000 请求 = 5000 个 goroutine，每个占 ~2.6KB 栈 + 堆上 buffer，10 秒就吃掉 1GB+ RSS。
必须在 HTTP handler 入口做并发闸门
不能等业务逻辑跑完再判断，必须在 http.HandlerFunc 第一行就拦截。推荐用带超时的限流器，而不是简单计数器——避免排队阻塞拖垮整个服务。
- 用
golang.org/x/time/rate.Limiter，每秒允许 N 个 token，burst 设为 2×N（防脉冲） - 在 handler 开头调
if !limiter.Allow() { http.Error(w, "too many requests", http.StatusTooManyRequests); return } - 别用
time.Sleep等待 token，它会阻塞 goroutine，反而加剧堆积 - 如果后端依赖慢（如 DB 查询），需额外套一层
context.WithTimeout，防止 goroutine 卡死不退
goroutine 泄漏比限流失败更危险
限流只是第一道防线。真正致命的是：限流后仍创建了 goroutine 却没退出。典型场景是发包过快 → 启动大量 goroutine 去调 http.DefaultClient.Do → 全部卡在 conn.Read 上，既不响应 cancel，也不释放栈。此时 runtime.NumGoroutine() 持续上涨，runtime.ReadMemStats().StackInuse 也同步涨，pprof 查 /debug/pprof/goroutine?debug=2 会看到成千上万个 [select] 或 [IO wait] 状态。
- 所有外发 HTTP 调用必须传入带 timeout 的
context.Context，且 client 设置Timeout和Transport.IdleConnTimeout - 禁止在 goroutine 里直接用
time.After做超时，它不参与 context 取消 - 用
sync.WaitGroup+context.Done()双保险等待子 goroutine 退出，别只靠 channel 关闭
容器环境必须配 memory.limits + GOMEMLIMIT 组合
光靠代码限流不够。当突发流量打穿限流阈值（比如 burst 被耗尽），进程 RSS 仍可能飙升。此时若容器没设内存上限，Go 进程会吃尽宿主机内存，被 OOM Killer 杀掉——而错误日志里往往只有模糊的 “stack overflow”，让人误判为代码问题。
- K8s 中必须设
resources.limits.memory: 2500Mi，对应GOMEMLIMIT=1750MiB（70%） - 裸机用 systemd 部署时，用
MemoryMax=2.5G+MemoryLow=1.8G，比ulimit -v有效得多 - 上线前必跑验证：启动后执行
ps -o pid,rss,comm -p $PID，确认 RSS 稳定在 limit × 0.8 以内
最易被忽略的一点：pprof 必须默认开启且低开销运行。等 OOM 发生再想起开 /debug/pprof/heap，进程早就卡死或被杀，快照拿不到。真实压测阶段就要确认 curl -s http://localhost:6060/debug/pprof/goroutine?debug=2 能在 200ms 内返回文本——这是 goroutine 泄漏最早、最准的信号。
