Go语言用带缓冲channel实现事件总线：缓冲大小宜设1024或4096，需显式声明；大结构体传指针或复用对象池；消费者须在独立goroutine中运行并recover panic。
Go 语言本身没有内置的“事件总线”或“发布-订阅”框架，但用 channel + goroutine 能干净地实现异步事件处理——关键不在于堆砌模式，而在于控制好 channel 的生命周期、缓冲区大小和关闭时机。
用带缓冲的 channel 做事件队列
无缓冲 channel 会阻塞发送方，不适合高吞吐事件场景；缓冲 channel 才是实际可用的队列基础。但缓冲区不是越大越好：过大会掩盖消费延迟，过小会导致 select 中的 default 分支频繁触发丢事件。
- 典型缓冲大小设为
1024或4096，视事件平均处理耗时和峰值频率而定 - 务必用
make(chan Event, N)显式声明缓冲容量，别依赖无缓冲默认行为 - 如果事件结构体较大（比如含
[]byte），考虑传指针或用对象池复用，避免频繁堆分配
启动 goroutine 消费事件并防 panic
事件处理器必须在独立 goroutine 中运行，否则会阻塞发送方；同时要 recover panic，否则一个事件处理崩溃会导致整个消费者退出。
func startEventConsumer(events <-chan Event) {
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("event consumer panicked: %v", r)
}
}()
for e := range events {
handleEvent(e)
}
}()
}-
handleEvent必须是纯函数式或有明确副作用边界，避免共享状态竞争 - 不要在
for range循环里直接调用close(events)—— channel 只能由发送方关闭 - 若需优雅停止消费者，应额外引入
context.Context或sync.WaitGroup配合donechannel
避免 channel 泄漏：谁负责关闭？
绝大多数异步事件队列场景下，你不该关闭事件 channel。关闭后向已关闭 channel 发送数据会 panic；而反复检查 cap(ch) == 0 或用 select + default 并不能替代正确设计。
立即学习“go语言免费学习笔记（深入）”；
- 发送方只管
ch ，不关 channel - 消费者只管
for e := range ch，靠外部信号（如ctx.Done()）退出循环 - 真要关闭，必须确保所有发送方都已退出，且消费者已收到关闭通知 —— 这在动态增删事件源时极难保证
简单可运行示例：HTTP 请求日志事件化
把 HTTP handler 中的日志动作转为异步事件，避免磁盘 I/O 拖慢响应。
type LogEvent struct {
Path string
Method string
Status int
}
var logEvents = make(chan LogEvent, 1024)
func init() {
go func() {
for e := range logEvents {
log.Printf("HTTP %s %s %d", e.Method, e.Path, e.Status)
}
}()
}
func handler(w http.ResponseWriter, r *http.Request) {
// ... 处理逻辑
status := http.StatusOK
select {
case logEvents <- LogEvent{Path: r.URL.Path, Method: r.Method, Status: status}:
default:
// 队列满，降级：同步记录（或直接丢弃）
log.Printf("[DROPPED] HTTP %s %s %d", r.Method, r.URL.Path, status)
}
}
这里 default 分支不是为了“非阻塞”，而是防止请求处理被日志队列卡住；真正要注意的是：一旦日志 goroutine 因 panic 退出，logEvents channel 就成了“黑洞”，后续所有事件都会进 default 分支——所以 recover 和监控必不可少。
