启动协程前须明确生命周期和退出机制：需等待时用 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 并发的清晰，靠的是显式声明，不是靠脑补。
