立即限流、扩容、关闭高危数据源，并在5分钟内完成；通过pprof快照重点排查[select]、[chan receive]及重复函数栈，定位未超时/未关闭的goroutine。
goroutine数量突增时怎么快速止血
别等根因分析完再动手，OOM进程里没时间讲道理。第一反应是让服务活下来，且必须在5分钟内完成。
- 立刻扩容或重启实例：利用服务无状态特性快速分摊压力，比修代码快十倍
- 在入口层限流：Nginx 或 API 网关上直接 limit_req，把 QPS 压到日常 30% 以下
- 临时关闭高危数据源：比如某批 IoT 设备、某个 region 的上报通道，用开关配置秒级生效
- 禁止任何“先观察10分钟”的操作——goroutine 超过 5000 个还在涨，就说明已失控
pprof goroutine?debug=2 快照怎么看关键线索
抓到的 curl http://localhost:6060/debug/pprof/goroutine?debug=2 输出不是用来数总数的，重点看重复栈帧和阻塞状态。
- 大量 goroutine 停在
[select]或[chan receive]：说明 channel 未关闭或发送端已退出，接收方永久等待 - 同一行函数反复出现（如
main.processDeviceData）：99% 是该函数内部启了 goroutine 却没做超时/取消控制 - 堆栈末尾带
net/http.(*persistConn).readLoop：HTTP 长连接未设 ReadTimeout / WriteTimeout，下游卡住拖垮整个连接池 - 注意区分
goroutine N [running]和[IO wait]——前者可能是死循环，后者更可能是 I/O 阻塞
为什么 GOMEMLIMIT 单独设置会失效
GOMEMLIMIT 只管 Go 堆内对象回收时机，完全不约束 mmap、cgo 分配、或 OS 未归还页。它不是内存硬限额，只是 GC 的软提示。
- 容器部署必须同步配
--memory=2.5g（Docker）或resources.limits.memory: 2500Mi（K8s），否则 RSS 超限直接被 OOM Killer 杀 -
GOMEMLIMIT建议设为 OS 限制的 70%~75%，例如--memory=2.5g对应GOMEMLIMIT=1750MiB - 用
ps -o pid,rss,comm -p $PID看 RSS，若远超GOMEMLIMIT值，说明堆外内存失控，要查 cgo/mmap/unsafe.Alloc - 禁用
GOGC=10类调优：存活对象多时，高频 GC 反而加剧 STW 和元数据开销
worker pool 替代 go handle() 的实操要点
不是加个 channel 就叫 worker pool，关键在背压形成、生命周期可控、错误可收敛。
- channel 必须带缓冲：如
taskCh := make(chan Task, 1000)，否则 sender 会阻塞，等于没限流 - worker 数量固定且可监控：启动时明确
for i := 0; i < runtime.NumCPU(); i++ { go worker(taskCh) }，避免动态伸缩引入新泄漏点 - 每个 task 处理必须透传 context：从 HTTP handler 到下游
http.NewRequestWithContext、db.QueryRowContext全链路生效 - 不要在 goroutine 闭包里捕获外部变量却不传 context，错误写法：
go func() { doWork() }()→ 正确写法：go func(ctx context.Context) { doWork(ctx) }(reqCtx)
真实线上环境里，goroutine 泄漏往往不是单点 bug，而是多个防御层同时失守：没有入口限流 + 没有 context 透传 + channel 未关闭 + GOMEMLIMIT 和 OS 限制没对齐。任何一个环节补上，都能避免 OOM。
