Go并发编程如何写高可读代码_Go并发代码规范建议

启动协程前须明确生命周期和退出机制：需等待时用 sync.WaitGroup 并 defer wg.Done()；需取消时传 context.Context 并监听 ctx.Done()；避免无节制启协程，应限并发数。

用 go 启动协程前必须明确生命周期和退出机制

很多人一看到并发就直接写 go func() { ... }()，结果协程成了“幽灵 goroutine”——没被等待、没法取消、资源不释放。可读性崩塌的起点，就是协程生死不明。

实际写法要绑定控制信号：

• 需要等待完成：用 sync.WaitGroup 显式计数，defer wg.Done() 放在函数开头而非结尾（防 panic 漏调）
• 需要主动取消：传入 context.Context，并在协程内监听 ctx.Done()，配合 select 退出
• 不要在循环里无节制启协程：先确认是否真需并发；若需，限制并发数（如用带缓冲的 channel 控制 worker 数量）

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() go func(ctx context.Context) {     select {     case <-time.After(3 * time.Second):         fmt.Println("done")     case <-ctx.Done():         fmt.Println("canceled:", ctx.Err())     } }(ctx)

避免裸用 channel 做同步或状态传递

把 chan bool 当作“信号旗”，或用 chan Struct{} 做通知，看似简洁，实则语义模糊。后续维护者很难判断这个 channel 是用来退出、完成、还是错误上报。

更可读的做法是：

• 用命名明确的 channel 类型，比如 type DoneChan chan struct{}，再配合注释说明用途
• 优先封装成函数返回值，而不是让调用方自己 select：例如写 WaitUntilReady(ctx) 而非暴露一个 readyCh chan struct{}
• 写死的 cap=1 缓冲 channel 很容易因漏收导致阻塞；若只做一次通知，用 sync.Once + sync.Cond 或 atomic.Bool 更轻量、意图更清

select 里别漏写 default 或 ctx.Done()

这是最常引发死锁或卡顿的点。比如只监听业务 channel 却没处理超时或取消，协程就永远挂在那里。

每条 select 至少满足其一：

• 有 case （推荐放第一行）
• 有 default: 做非阻塞轮询或降级逻辑
• 所有 channel 都确定不会关闭且必有数据（极少见，需加注释说明理由）

特别注意：select {} 是永久阻塞，仅用于主 goroutine 等待信号的场景，绝不能出现在可被取消的子协程中。

错误处理必须和 goroutine 绑定，不能只靠上层 recover

协程内 panic 不会传播到父 goroutine，recover() 在启动它的函数里根本捕不到。指望全局 recover 是自欺欺人。

正确姿势：

• 每个独立 go 语句内部，用 defer func(){ if r := recover(); r != nil { log.Printf("panic: %v", r) } }()
• 若需上报错误，通过参数传入错误 channel（类型为 chan），并确保该 channel 有缓冲或有接收方，否则会阻塞 panic 恢复流程
• 不要在 defer 里调用可能 panic 的函数（如未判空的 map 写入），否则 recover 失效

可读性差的代码，往往不是语法错，而是把“谁负责清理”“谁决定结束”“出错了往哪报”这些契约藏在了隐式约定里。Go 并发的清晰，靠的是显式声明，不是靠脑补。