高并发Golang性能瓶颈多因连接池未调优、超时未控制、对象分配不当及channel误用；需重配http.Client连接池参数、显式设Timeout、禁用DefaultClient、用context+worker pool防goroutine泄漏。
高并发 Golang 项目性能卡顿，八成不是 goroutine 不够快，而是连接池没调、超时没控、对象乱分配、channel 用错地方——这些才是真实瓶颈。
http.Client 连接池参数必须重写，别碰 http.DefaultClient
默认 Transport 的 MaxIdleConns=100、MaxIdleConnsPerHost=2、IdleConnTimeout=30s 在 QPS > 500 时就会排队等连接，现象是大量 net/http: request canceled (Client.Timeout exceeded) 或延迟毛刺。
-
MaxIdleConns设为 500～2000（按机器内存和目标服务承受力取中值） -
MaxIdleConnsPerHost至少设为 100，否则单域名请求全卡在连接等待 -
IdleConnTimeout推荐 90s：比服务端 idle 超时短一点，避免被断连后还傻等 - 务必显式设置
Client.Timeout，否则失败请求会无限阻塞 goroutine - 禁用
http.DefaultClient，每次新建 client 都要带自定义 transport
goroutine 泄漏比慢更致命，必须用 context + worker pool 控制
循环里裸写 go handle(req) 是高频陷阱：一旦 handle 内部 HTTP 调用没设超时、channel 没关、或 panic 后没 recover，该 goroutine 就永久挂起，runtime.NumGoroutine() 持续上涨，P99 延迟逐步恶化。
- 所有网络/DB 调用必须套
context.WithTimeout，超时后自动 cancel 整条链路 - 改用固定数量的 worker pool，比如
semaphore.NewWeighted(50)或带缓冲 channel - 每个 worker 内部再起 goroutine 时，必须确保有
select { case 防死锁 - 启动前加
sync.WaitGroup，用defer wg.Done()显式计数，避免闭包捕获循环变量导致 Done 丢失 - 生产环境加
GODEBUG=schedtrace=1000，观察 sched 输出里 goroutines 是否持续增长
sync.Pool 只对特定对象有效，乱用反而加重 GC
sync.Pool 不是通用缓存，把它当 map 存业务结构体，会导致对象长期驻留堆上，延迟 GC 回收时机；New 函数若复用已有实例，还会带脏状态污染后续请求。
立即学习“go语言免费学习笔记（深入）”；
- 只适合「高频创建 + 短期使用 + 生命周期可控」的对象，比如
*bytes.Buffer、json.Decoder -
New必须返回全新对象，不能 return 已有实例指针 - 每次
Get()后必须Reset()，例如buf.Reset()，否则残留数据会污染下一次请求 - 别在 long-running goroutine（如后台定时任务）里高频
Get/Pool，它的回收依赖主 goroutine 的调用节奏 - HTTP handler 中优先复用
req.Context()，而不是自己 new context；中间件注入 deadline 后，下游 client 要显式支持该 context
切片预分配和 channel 缓冲不是拍脑袋填数字
make([]int, 0, 1024) 只解决一半问题：如果后续 append 超过 1024，仍会触发扩容；更隐蔽的是，若初始长度非 0（如 make([]int, 5, 1024)），你误以为底层数组已满而手动 copy，反而引入冗余拷贝。
- 预分配容量应基于真实最大预期值，比如日志行平均长度 × P99 日志条数
- channel 缓冲大小不能硬写 1024，得按 P99 处理耗时 × QPS 估算，比如 200ms × 500 QPS ≈ 100
- 避免无缓冲 channel（
make(chan int)）在高频生产者消费者场景中滥用，它本质是同步原语，会引发 goroutine 频繁切换 - 大对象别传副本，改传指针；channel 传
*Request而不是Request - 关闭 channel 前确认所有发送方已退出，否则 panic：
send on closed channel
最易忽略的点：pprof CPU 采样若直接走 /debug/pprof/profile?seconds=30，会把 handler 自身开销也计入 profile，尤其高 QPS 下可能占样本 15%+；正确做法是用 pprof.StartCPUProfile(f) 手动控制采样区间，并禁止采样期间打日志或注入结构化字段。
