select 不能直接替代事件循环，因其同步、一次性、无队列特性无法支持事件入队、分发策略、超时控制和错误隔离；它仅可作为事件循环中“等待就绪”的环节。
为什么 select 不能直接替代事件循环
很多人一想到“事件驱动”，就立刻套用 select + channel，结果在高并发下迅速卡死或漏事件。根本原因在于：select 是**同步、一次性、无队列**的——它只检查当前是否有就绪的 channel 操作，不缓存未消费的事件，也不支持优先级或延迟调度。
真实事件驱动系统需要：事件入队、分发策略、超时控制、错误隔离。所以必须自己构建事件循环骨架，select 只能作为其中“等待就绪”的一个环节。
-
select块里不能有阻塞操作（如time.Sleep或同步 HTTP 调用），否则整个 goroutine 挂起，影响所有监听的 channel - 多个
select并发运行没问题，但每个都应绑定独立的chan Event输入源，避免争用 - 如果事件来源是网络连接（如
net.Conn），别把Read()直接塞进select——要用net.Conn.SetReadDeadline()配合非阻塞读，再把数据包推到 channel
如何用 sync.Pool 降低事件对象分配压力
每秒数万事件时，频繁 &Event{...} 会触发 GC 尖峰，实测可使 P99 延迟翻倍。关键不是“要不要池化”，而是“池化什么”和“谁负责归还”。
推荐只池化**可复用的事件载体结构体**（如 type Event struct { Type string; Payload []byte; SrcID uint64 }），不池化含闭包、指针引用或不确定生命周期的字段。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义池时用
sync.Pool{New: func() interface{} { return &Event{} }}，不要在New里做耗时初始化 - 每次从池取对象后，必须显式重置字段（尤其
Payload切片要event.Payload = event.Payload[:0]，避免残留数据污染） - 事件处理结束前，调用
pool.Put(event)——不能依赖 defer，因为 handler 可能 panic；建议统一收口在中间件或 dispatcher 中
runtime.GOMAXPROCS 和 worker 数量怎么配才不浪费也不堵塞
设成 CPU 核心数 ≠ 最优。Golang 的调度器对 I/O 密集型事件并不敏感，真正瓶颈常在 channel 缓冲区大小、worker 处理逻辑是否含同步阻塞、以及事件入队速率是否远超消费速率。
观察 go tool trace 中的 “Proc status” 和 “Goroutine analysis”，若大量 G 处于 “runnable” 状态但 Proc 长期空闲，说明 worker 不足；若大量 G 卡在 “chan send” 或 “chan recv”，说明 channel 容量太小或 consumer 太慢。
- 初始 worker 数建议设为
2 * runtime.NumCPU()，然后按压测中 channel 阻塞率（len(ch)/cap(ch) > 0.7）动态调整 - 避免为每个连接启一个 goroutine：改用固定数量的 worker 从共享
chan *Event拉取任务，连接层只负责解析+投递 - 若事件类型差异大（如心跳 vs 业务命令），拆成多个专用 channel + worker 组，防止慢事件拖垮快路径
为什么 context.Context 必须传给每个事件处理器
不是为了“标准写法”，而是解决两个实际问题：超时中断正在执行的 handler，以及跨 goroutine 传递取消信号（比如连接断开时，要立刻终止它触发的所有异步事件）。
常见错误是只在入口处传 ctx，handler 内部又起了新 goroutine 却没传下去，导致无法及时回收资源。
- 每个事件结构体里预留
ctx context.Context字段，并在投递前用context.WithTimeout(parentCtx, timeout)包装 - handler 中启动子 goroutine 时，必须用
ctx衍生新上下文：go doWork(ctx)，而不是go doWork(context.Background()) - 若 handler 调用外部服务（如 Redis、gRPC），确保客户端方法支持
ctx参数，否则取消将失效
实际最难的不是并发模型本身，而是事件语义的边界划分——比如“一次上传完成”该算一个事件，还是拆成“分片到达”“校验通过”“落盘成功”三个事件。这直接影响 channel 设计、错误重试粒度和监控指标口径。设计时多问一句：这个事件，下游是否可能重复收到？能否幂等处理？
