Go语言并发模型怎么设计_Golang系统设计入门_技术教程

Go并发需谨慎控制goroutine数量，避免盲目启动；须用WaitGroup、带缓冲channel或errgroup.Group节流；HTTP请求天然限流可单启goroutine，批量处理需worker pool；time.AfterFunc等需context控制生命周期；channel操作不当易导致阻塞或panic。

Go 里并发不是靠加 goroutine 就完事

盲目在循环里起 go func() 是最常见错误。goroutine 轻量，但不免费：调度开销、内存占用、竞态风险都会随数量线性增长。真实系统里，必须配合控制手段——要么用 sync.WaitGroup 等待结果，要么用带缓冲的 chan 做节流，要么直接上 errgroup.Group。

HTTP 服务中每个请求启一个 goroutine 是安全的，因为请求天然限流（连接数、超时、反向代理限制）
批量处理 10 万条日志？不能直接 for _, log := range logs { go process(log) }，得用 worker pool 模式
time.AfterFunc 或 time.Tick 启的 goroutine 容易泄漏，务必配 context.WithCancel 控制生命周期

channel 用法错一半，程序就卡死或 panic

channel 不是万能队列，它的阻塞行为直接决定 goroutine 是否挂住。写入已关闭的 channel 会 panic；从已关闭且无数据的 channel 读，得到零值；无缓冲 channel 写之前没人读，就永远阻塞。

发送前先检查 select { case ch 避免阻塞
关闭 channel 的责任必须明确——通常只由发送方关闭，接收方不应 close
用 for range ch 读 channel 时，如果 sender 永不 close，循环永不退出
不要用 channel 传大结构体，避免拷贝；优先传指针或 sync.Pool 复用对象

func worker(id int, jobs <-chan int, results chan<- int, done <-chan struct{}) {
    for {
        select {
        case job, ok := <-jobs:
            if !ok {
                return
            }
            results <- job * 2
        case <-done:
            return
        }
    }
}

context.Context 不只是传取消信号

它还承载超时、截止时间、值传递、取消链路。漏传 ctx 到下游调用（比如 http.Client.Do(ctx, req)、db.QueryContext(ctx, ...)），整个链路就失去控制能力。

HTTP handler 入口的 ctx 来自 r.Context()，别自己 new
用 context.WithTimeout 时，记得 defer cancel()，否则可能泄露 timer
context.WithValue 只适合传请求范围的元数据（如用户 ID、trace ID），禁止传业务参数或函数对象
数据库连接池、gRPC client、Redis client 都要求传 ctx，否则超时和取消无效

sync.Mutex 和 atomic.Value 不是二选一

简单字段读写用 atomic.LoadInt64 / atomic.StoreUint64 更快；但涉及多个字段关联更新（比如状态 + 时间戳）、或需要条件等待（sync.Cond），就必须用 sync.Mutex。混用两者极易出错。

atomic.Value 只能存指针或接口类型，且每次 Store 都是全量替换，不适合高频小字段更新
用 sync.RWMutex 时，注意 RUnlock 必须和 Rlock 成对，漏掉会导致后续所有写锁永久阻塞
struct 字段加 mu sync.RWMutex 后，别忘了所有访问都得显式加锁——编译器不会报错，但数据竞争检测器（go run -race）会抓到

真正难的不是写并发代码，而是判断某段逻辑是否必须并发、并发粒度该划多细、失败后怎么回滚或重试。这些没法靠语法糖解决，得结合监控指标（goroutine 数、channel 阻塞数、GC pause）和压测反复验证。