go网络编程无事件循环，应避免node.js式回调，改用channel+goroutine显式建模；回调易致body关闭后读取、上下文过期、错误透传失效等问题，而channel封装异步结果更可控且需带缓冲并defer关闭。
Go网络编程里没有“事件循环”这个运行时概念，net/http 或 net 包本身不提供类似 Node.js 的全局事件循环，所谓“回调函数解耦业务逻辑”，本质是手动构造异步通知机制——但直接用回调极易出错，真正该做的是用 channel + goroutine 显式建模。
为什么不能照搬 Node.js 风格的事件循环回调
Go 的 runtime 没有单线程事件循环，goroutine 是轻量级线程，调度由 Go runtime 管理。强行模仿事件循环（比如用 select 堆砌大量 chan 并手动轮询）不仅没收益，反而引入竞态、泄漏和调试盲区。
- HTTP handler 中传入
func([]byte, error)回调，但 handler 返回后r.Body已关闭，回调里再读就是http: read on closed response body - 回调函数捕获的变量若含
http.Request或context.Context，容易因 goroutine 生命周期失控导致上下文过期或 panic - 错误无法统一透传：回调里
log.Fatal会 kill 整个进程；return err对外不可见；fmt.Errorf("xxx: %w", err)又常被忽略
用 channel 封装异步结果比回调更可控
把“回调要做的事”变成一个结构体 + 无缓冲或带缓冲 channel，让调用方主动接收结果，而不是被动等待函数调用。
- 必须用带缓冲 channel：
ch := make(chan TaskResult, 1)，否则 goroutine 可能在发送时永久阻塞 - goroutine 内必须
defer close(ch)，否则接收方会死等 - 主流程要用
select+ctx.Done()控制超时，例如：select { case res := - 不要在回调签名里暴露
*http.Request或http.ResponseWriter，它们不是可跨 goroutine 安全传递的对象
HTTP handler 里绝对禁止直接 go 启动 goroutine 处理业务
这是线上事故高发点。看似异步，实则埋雷。
-
r.Body在 handler 函数返回后立即被关闭，goroutine 里io.ReadAll(r.Body)必然失败 - 没做并发控制：1000 个请求进来就启 1000 个 goroutine，可能瞬间耗尽 DB 连接或内存
- goroutine 内 panic 不会触发 HTTP handler 的 recover，日志里完全无声无息
- 进程重启时所有未完成 goroutine 被丢弃，订单/消息/支付任务彻底丢失
- 正确做法只有三步：
validate signature→io.ReadAll(r.Body)→write to Redis Stream / Kafka / DB→ 立刻return 200 OK
真需要“回调语义”时，优先用接口+结构体包装
比如你要给某个 UserService 加监控、重试、限流，别写 func(user *User, cb func(error))，而是定义接口：
type UserService interface {
GetUser(ctx context.Context, id int64) (*User, error)
}
type InstrumentedService struct {
base UserService
metrics MetricsClient
}
func (s *InstrumentedService) GetUser(ctx context.Context, id int64) (*User, error) {
s.metrics.Inc("get_user")
defer s.metrics.Hist("get_user_latency", time.Now())
return s.base.GetUser(ctx, id)
}
- 所有装饰器都实现同一接口，叠加清晰：
NewRateLimitService(NewRetryService(NewDBService())) - 每个方法都显式接收
context.Context，超时、取消、值传递全部可控 - 错误链完整：
return fmt.Errorf("get user %d failed: %w", id, err) - 避免闭包捕获 request/response，也避免反射或代码生成
最易被忽略的一点：所谓“解耦”，不是靠回调函数把逻辑甩出去，而是靠明确的输入输出边界、显式的错误传播路径、以及可测试的接口契约。Go 里没有魔法，只有清晰的责任划分。
