GOMAXPROCS 不能替代 Worker Pool，因其仅控制 OS 线程数（并行度），不限制 goroutine 总数；Worker Pool 通过 channel 限流实现可控并发，worker 数决定实际并发量，缓冲区需按突发流量窗口合理设置。
为什么 runtime.GOMAXPROCS 不能替代 Worker Pool
很多人以为调大 GOMAXPROCS 就能“控制并发”，其实它只管 OS 线程调度，不约束 goroutine 创建数量。你起 10 万个 go doWork()，照样瞬间耗光内存或打爆下游服务。
Worker Pool 的本质是**用 channel 做限流阀**：任务进队列，worker 从队列取，数量由启动的 goroutine 个数决定——这才是真正可控的并发。
-
GOMAXPROCS影响的是并行度（P 数），不是并发数（goroutine 总数） - 没 pool 时，每请求启 goroutine → 并发数 = QPS × 处理时长（秒），极易雪崩
- pool 中 worker 数建议设为 CPU 核心数的 2–4 倍，非固定值；IO 密集可稍多，CPU 密集宜接近核数
chan<job> 缓冲区大小设多少才不丢任务也不卡死
缓冲通道不是越大越好。设成 0（无缓冲）时，提交任务会阻塞直到有空闲 worker；设太大则掩盖背压问题，任务堆积在内存里，OOM 风险高。
真实场景中，缓冲区应匹配「突发流量容忍窗口」：比如你允许最多积压 1 秒的任务，QPS 是 500，平均处理耗时 200ms，那理论积压上限是 500 * 0.2 = 100，缓冲区设 128 比较稳妥。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 生产环境慎用无缓冲 channel：
make(chan job)→ 提交方易被 hang 住 - 缓冲区超过 1000 很可能说明下游处理能力已跟不上，该查瓶颈而非加 buffer
- 如果任务必须不丢，缓冲区 + 超时重试 + 拒绝策略（如
select { case ch ）三者缺一不可
worker 退出时如何安全清空剩余任务
直接关闭 jobs channel 会导致部分 worker 拿到任务后还没处理完就被退出，或者新任务还在路上就断连。真正的清理要分两步：先停收新任务，再等正在跑的做完。
常见错误是只关 channel 不等 worker 结束，结果 main 函数提前 exit，goroutine 被强制终止，数据丢失。
- 用
sync.WaitGroup记录活跃 worker，每个 worker 在defer wg.Done()前确保 job 处理完毕 - 关闭
jobschannel 后，需调用wg.Wait()，而不是靠time.Sleep猜时间 - 若需支持「强制中断」，给每个 job 加
context.Context，worker 内部定期检查ctx.Err()
为什么别把 http.Handler 直接扔进 worker pool
HTTP handler 本身带 request/response 生命周期，如果直接传给 worker，response writer 可能在 handler 返回后被写入，触发 http: response.WriteHeader on hijacked connection 或 panic。
正确做法是把「需要异步做的事」抽出来（比如发 MQ、写日志、调第三方 API），而响应逻辑仍在原 goroutine 完成。
- 错误示例：
go func() { myHandler(w, r) }()→w和r不是线程安全的 - 正确拆法：在 handler 里构造 job 结构体，只含纯数据（
userID,event,timestamp），worker 拿到后做副作用 - 若真要异步返回结果，改用 WebSocket / SSE / 回调地址，而不是复用 HTTP response
实际写的时候最容易漏掉的是 worker 的 recover 机制——panic 会直接杀掉整个 goroutine，导致 pool 缺员；还有就是 job 结构体里混了指针或闭包引用，造成意外的内存泄漏。这些点不显眼，但压测时第一个崩。
