goroutine泄漏是比CPU占用更常见的性能恶化原因，表现为pprof中goroutine数持续上涨且多阻塞在select或chan receive；需检查未关闭channel、无超时HTTP调用、未监听ctx.Done()等问题。
goroutine 泄漏比 CPU 占用更常导致性能恶化
很多开发者一提并发优化就盯着 runtime.GOMAXPROCS 或协程数量，但实际线上服务中，goroutine 泄漏才是拖垮吞吐、耗尽内存的元凶。典型表现是 pprof 中 goroutine 数持续上涨，且多数处于 select 阻塞或 chan receive 状态。
排查时优先运行：
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看堆栈，重点找未关闭的
chan、未设超时的 http.Client 调用、或忘记 close() 的 context.WithCancel 子节点。
- 所有带
for range ch的循环，必须确保ch会被某处close()，否则协程永远卡住 - 用
context.WithTimeout包裹外部调用（如 HTTP、DB），避免单个请求阻塞整个 goroutine - 启动长期运行的 goroutine 时，显式传入
context.Context并监听ctx.Done()，而不是靠全局 flag 控制退出
channel 使用不当会放大锁竞争
高频写入同一 chan（尤其无缓冲或小缓冲）时，底层 runtime 会对该 channel 加互斥锁，成为瓶颈。这不是设计缺陷，而是 channel 语义要求——它保证发送/接收的顺序性和原子性，代价就是锁开销。
替代方案取决于场景：
立即学习“go语言免费学习笔记（深入）”；
- 若只是传递事件（如日志、指标），改用
sync.Pool+ ring buffer 自建无锁队列，或直接用github.com/panjf2000/ants/v2管理任务池 - 若需严格保序且量不大（如配置变更通知），保留 channel，但把缓冲区设为
cap = 1024以上，减少锁争抢频次 - 若多个 goroutine 向不同 channel 写，但最终要聚合，避免用一个大 channel 收集，改用
sync.Map分 key 存储，最后统一读取
sync.Pool 不是万能缓存，滥用反而降低性能
sync.Pool 适合复用临时对象（如 []byte、bytes.Buffer、自定义结构体），但它的 Get/Put 开销不为零，且对象可能被 GC 清理。如果每次 Get 都 miss，或 Put 进去的对象很快又被分配新对象，就会比直接 new 更慢。
云模块_YunMOK网站管理系统采用PHP+MYSQL为编程语言，搭载自主研发的模块化引擎驱动技术，实现可视化拖拽无技术创建并管理网站！如你所想，无限可能，支持创建任何网站：企业、商城、O2O、门户、论坛、人才等一块儿搞定！永久免费授权，包括商业用途； 默认内置三套免费模板。PC网站+手机网站+适配微信+文章管理+产品管理+SEO优化+组件扩展+NEW Login界面.....目测已经遥遥领先..
判断是否该用 Pool 的关键信号：
- 对象分配频率高（>10k/s）、生命周期短（
- 已通过
go tool pprof -alloc_space确认该类型占 heap 分配前 3 - Pool 的
New函数返回的是零值对象，不能依赖其内部状态残留
示例：错误用法是把带业务字段的 struct 放进 Pool；正确做法是只放纯数据容器：
var bufPool = sync.Pool{
New: func() interface{} {
return make([]byte, 0, 1024)
},
}
不要用 goroutine 模拟异步 I/O，Go 的 netpoll 机制已足够高效
常见误区是给每个 TCP 连接起一个 goroutine 处理读写，再用 select 等待多个连接。这在连接数少时没问题，但连接数上万后，goroutine 调度和栈内存（默认 2KB）会吃掉大量资源。
真正高效的模式是：
- 用
net.Conn.SetReadDeadline配合单个 goroutine 轮询多个连接（类似 epoll wait），或直接使用golang.org/x/net/netutil.LimitListener控制并发连接数 - 对 HTTP 服务，优先用标准库
http.Server，它底层已基于 netpoll 复用 goroutine；自定义协议时，参考net/http/transport.go的readLoop和writeLoop分离模型 - 避免在 handler 里做同步阻塞操作（如调用
time.Sleep、未设 timeout 的database/sql.QueryRow），这些会卡住整个 goroutine，而非仅当前连接
并发性能的瓶颈往往不在“能不能并发”，而在“有没有让并发真正落地而不互相拖累”。channel 的锁、goroutine 的泄漏、Pool 的误用、I/O 模型错配——这些细节比调大 GOMAXPROCS 影响更大，也更容易被忽略。
