应按场景选异步模式：瞬时操作用带recover的goroutine；可控队列用带缓冲channel+固定worker；跨服务必须用Kafka等持久化MQ，避免channel死锁与泄漏。
用 goroutine + channel 实现异步消息处理，不是“能跑就行”，而是要分清场景：是本地轻量任务、高并发写入，还是需要持久化与重试的业务消息。选错模式，轻则丢数据，重则 goroutine 泄漏或 channel 死锁。
什么时候直接起 goroutine 就够了？
适合不关心结果、无状态、失败可容忍的瞬时操作，比如日志上报、埋点记录、通知触发。
- 错误写法：
go sendEmail(email)—— 若sendEmailpanic，整个 goroutine 崩溃且无日志 - 正确做法：加
recover+ 显式传参（避免闭包捕获循环变量） - HTTP handler 中立即返回，不能等结果；否则违背“异步”本意
func sendEmailHandler(w http.ResponseWriter, r *http.Request) {
email := r.URL.Query().Get("to")
go func(to string) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in email goroutine: %v", r)
}
}()
if err := sendEmailAsync(to); err != nil {
log.Printf("send email to %s failed: %v", to, err)
}
}(email)
json.NewEncoder(w).Encode(map[string]string{"status": "queued"})
}如何用 channel 构建可控的任务队列？
当任务量不可控、需限流或统一管理生命周期时，必须引入带缓冲的 channel 作为中间队列，再配固定数量 worker 消费。
-
taskCh := make(chan Task, 100)：缓冲大小 ≠ 并发数，而是积压容量，防主流程阻塞 - worker 数量建议设为 CPU 核心数 × 2～4，避免过度调度；别硬写
runtime.NumCPU()，先压测 - 务必在所有任务发送完毕后
close(taskCh)，否则for range taskCh永远不会退出 - worker 内部应处理 panic，否则一个 panic 会让整个 worker goroutine 退出，队列变“半瘫痪”
type Task struct {
ID int
Data string
}
func StartWorkerPool(numWorkers int, taskCh <-chan Task) {
for i := 0; i < numWorkers; i++ {
go func(workerID int) {
defer func() {
if r := recover(); r != nil {
log.Printf("worker %d panicked: %v", workerID, r)
}
}()
for task := range taskCh {
log.Printf("Worker %d processing task %d", workerID, task.ID)
// do work...
}
}(i + 1)
}
}
为什么不能只靠 channel 做跨服务异步通信？
channel 是内存级通信，进程重启即丢失，无法满足消息可靠性要求（如订单创建后发短信、支付成功后更新库存）。它只适用于单体或同一进程内协作。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境必须用 Kafka / NSQ / RabbitMQ 等消息队列：提供持久化、ACK、重试、死信、消费者组负载均衡
- Go 客户端（如
github.com/segmentio/kafka-go）消费时，每条消息处理完才调用msg.Commit()，否则可能重复消费 - 别把 HTTP 请求体直接塞进 message body 当原始数据——序列化用
json.Marshal，反序列化前校验字段，避免 panic - 消息体里至少带
trace_id和timestamp，否则出问题时根本无法对账和排查时序
常见死锁和资源泄漏怎么一眼识别？
90% 的 goroutine 相关线上故障，都来自 channel 使用不当。以下现象出现就该立刻检查：
- pprof 查到大量 goroutine 卡在
chan send或chan receive—— 很可能是 sender 没 close，receiver 却用了for range - 程序内存持续上涨，
runtime.ReadMemStats显示Mallocs高但Frees低 —— 可能是 channel 缓冲区过大，或结果 channel 没被读取导致堆积 - HTTP 接口响应时间突增，但 CPU 不高 —— 往往是 task channel 满了，新请求在
taskCh 处阻塞等待 - 用
select等待 channel 时没写default或time.After分支 —— 一旦 channel 没数据，协程就卡死
真正难的不是写出能跑的异步代码，而是判断哪一层该用内存 channel，哪一层必须交出去给消息队列；以及当 panic 发生时，是否真的被 recover 住、错误是否被记录、任务是否真的被丢弃而非静默失败。这些细节，往往在压测和上线后第一波流量里才暴露出来。
