进阶关键在于“何时不该用”和“问题定位”：goroutine泄漏因未关闭channel或缺退出机制；缓冲大小需权衡背压与性能；共享状态高频场景仍需锁或原子操作；Worker Pool须结合context与限流。
goroutine 和 channel 入门容易，但真正进阶的关键不在“会不会用”，而在“什么时候不该用”和“出问题时怎么定位”。
goroutine 泄漏：最隐蔽的内存杀手
现象：程序长期运行后 RSS 内存持续上涨，pprof 显示大量 goroutine 处于 chan receive 或 select 阻塞态，且数量不随任务结束而下降。
- 根本原因：未关闭的
channel+ 无退出机制的循环 goroutine（比如for range ch永不退出） - 典型错误写法：
go func() { for v := range ch { // ch 永不 close → goroutine 永不退出 process(v) } }() - 修复方式：必须配对使用
context.Context控制生命周期，或显式close(ch)后再range - 生产建议：所有长期运行的 goroutine 都应接受
ctx context.Context参数，并在select中监听ctx.Done()
channel 缓冲大小：不是越大越好，也不是越小越安全
缓冲通道不是“保险丝”，而是性能与可靠性的权衡点。
-
make(chan int, 0)（无缓冲）：强制同步，适合信号通知、屏障同步，但若收发端逻辑错位（如 sender 先发、receiver 没启），直接死锁 -
make(chan int, N)（有缓冲）：N 不是凭经验拍的——它应 ≈ 单位时间内峰值写入量 × 最大容忍延迟（单位：消息数）。例如每秒 100 条日志，允许最多积压 2 秒，则cap=200 - 过大的缓冲（如
10000）会掩盖背压问题，让下游崩溃前先吃光内存；过小则频繁阻塞，吞吐骤降 - 实测提示：用
runtime.ReadMemStats对比不同cap下的Mallocs和PauseNs，比理论推导更可靠
共享状态：别迷信 “通过通信共享内存”，该加锁还得加
Go 的信条 “Do not communicate by sharing memory; instead, share memory by communicating” 是指导原则，不是教条。真实业务里，高频读+低频写、聚合统计、配置热更新等场景，channel 反而成为瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 高频计数器：用
sync/atomic比走 channel 快 40 倍以上，且无调度开销var counter int64 atomic.AddInt64(&counter, 1) // 安全、无锁、单指令
- 读多写少配置：优先用
sync.RWMutex，而非为每次读都塞一个 channel 请求 - 切忌把 channel 当“万能胶水”：比如用
chan struct{}实现简单开关，远不如atomic.Bool或sync.Once直观高效
Worker Pool 模式：控制并发度 ≠ 简单限制 goroutine 数量
只用 for i := 0; i 是伪控制——它没解决任务分发公平性、panic 恢复、结果收集超时、worker 异常退出等问题。
- 必须带 recover：否则一个 panic 会让整个 pool 崩溃
go func() { defer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }() for job := range jobs { handle(job) } }() - 任务 channel 必须带超时或上下文：
select { case jobs - 结果收集推荐用
sync.WaitGroup+chan组合，避免for i := 0; i 因顺序依赖导致卡死 - 真正需要动态扩缩容？别手写，用
golang.org/x/sync/errgroup或semaphore库更稳妥
真正的进阶，是从“写得出来”走向“压得住、停得稳、查得清”。runtime/pprof、go tool trace、go tool pprof -http 这三个命令，比任何文档都更能暴露你并发模型的真实缺陷。
