启动协程前须明确生命周期和退出机制：需等待时用 sync.WaitGroup 并 defer wg.Done()；需取消时传 context.Context 并监听 ctx.Done()；避免无节制启协程，应限并发数。
用
启动协程前必须明确生命周期和退出机制
很多人一看到并发就直接写
，结果协程成了“幽灵 goroutine”——没被等待、没法取消、资源不释放。可读性崩塌的起点，就是协程生死不明。
实际写法要绑定控制信号：
需要等待完成：用
显式计数，
放在函数开头而非结尾（防 panic 漏调）
需要主动取消：传入
，并在协程内监听
，配合
退出
不要在循环里无节制启协程：先确认是否真需并发；若需，限制并发数（如用带缓冲的 channel 控制 worker 数量）
避免裸用
做同步或状态传递
把
当作“信号旗”，或用
做通知，看似简洁，实则语义模糊。后续维护者很难判断这个 channel 是用来退出、完成、还是错误上报。
更可读的做法是：
用命名明确的 channel 类型，比如
，再配合注释说明用途
优先封装成函数返回值，而不是让调用方自己
：例如写
而非暴露一个
写死的
缓冲 channel 很容易因漏收导致阻塞；若只做一次通知，用
+
或
更轻量、意图更清
里别漏写
或
这是最常引发死锁或卡顿的点。比如只监听业务 channel 却没处理超时或取消，协程就永远挂在那里。
每条
至少满足其一：
Android开发代码规范 中文WORD版
本文档主要讲述的是Android开发代码规范；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
有
有
做非阻塞轮询或降级逻辑
所有 channel 都确定不会关闭且必有数据（极少见，需加注释说明理由）
特别注意：
是永久阻塞，仅用于主 goroutine 等待信号的场景，绝不能出现在可被取消的子协程中。
错误处理必须和 goroutine 绑定，不能只靠上层
协程内 panic 不会传播到父 goroutine，
在启动它的函数里根本捕不到。指望全局
是自欺欺人。
正确姿势：
每个独立
语句内部，用
若需上报错误，通过参数传入错误 channel（类型为
不要在 defer 里调用可能 panic 的函数（如未判空的 map 写入），否则 recover 失效
可读性差的代码，往往不是语法错，而是把“谁负责清理”“谁决定结束”“出错了往哪报”这些契约藏在了隐式约定里。Go 并发的清晰，靠的是显式声明，不是靠脑补。
gogo func() { ... }()sync.WaitGroupdefer wg.Done()context.Contextctx.Done()selectctx, 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)channelchan boolchan struct{}type DoneChan chan struct{}selectWaitUntilReady(ctx)readyCh chan struct{}cap=1sync.Oncesync.Condatomic.Boolselectdefaultctx.Done()selectcase （推荐放第一行）default:select {}recoverrecover()recovergodefer func(){ if r := recover(); r != nil { log.Printf("panic: %v", r) } }()chan），并确保该 channel 有缓冲或有接收方，否则会阻塞 panic 恢复流程