go中无标准带中间件消息总线，需显式构建“发布→中间件链→handler”调用链；硬塞逻辑致耦合、难动态启停、panic中断流；应定义middleware函数类型并按topic绑定独立链，执行时递归调用且每层defer recover，透传context支持超时与追踪。
Go 里没有“带中间件的消息总线”标准实现，chan 和 EventBus 本身不提供中间件机制；要支持中间件，必须自己在事件分发路径上插入可插拔的处理逻辑——本质是把“发布 → 中间件链 → 投递 handler”做成显式调用链。
为什么不能直接在 EventBus.Publish 里硬塞中间件逻辑
常见错误是改写 Publish 方法，在里面加日志、校验、重试等代码。这会导致：中间件和核心逻辑耦合，无法按 topic 动态启用/禁用；所有事件强制走同一套流程，比如调试时想跳过鉴权中间件却做不到；中间件 panic 会直接中断整个事件流，且无法统一 recover。
真正可行的做法是把中间件抽象为函数类型：type Middleware func(Event, func(Event))，让每个 topic 可绑定独立中间件链，再由总线控制执行顺序。
如何定义中间件接口并注入到事件分发中
中间件必须能访问事件内容、决定是否继续传递、还能修改事件（如加 traceID）、甚至终止投递（如权限拒绝）。关键点在于：中间件接收当前 Event 和一个 next 回调，由它决定是否调用 next(event)。
-
Event结构体必须含Type string和Version string字段，否则中间件无法做路由或兼容判断 - 注册 topic 时允许传入中间件切片：
bus.Subscribe("user.created", handler, middleware1, middleware2) - 内部维护
map[string]struct{ handlers []func(Event); middlewares []Middleware }，避免每次 publish 都重复构建链 - 中间件链执行必须用递归或栈式展开，不能简单 for-range —— 否则无法短路（如鉴权失败就 stop）
中间件里最容易忽略的并发与错误处理细节
多个 goroutine 并发调用 Publish 时，中间件链本身是无状态的，但若中间件内访问共享资源（如计数器、缓存），就必须自行加锁；更危险的是中间件里 panic 会崩掉整个 goroutine，而 EventBus 默认不会 recover。
- 每个中间件调用都得包一层
defer func() { if r := recover(); r != nil { log.Printf("middleware panic: %v", r) } }() - 不要在中间件里直接向
chan发送事件（比如转发到另一个 topic），这会绕过当前中间件链，造成行为不一致 - 如果中间件需要异步操作（如调用 HTTP 服务），必须启动新 goroutine，并确保
next不被阻塞；否则会拖慢整个事件流 - 中间件返回修改后的
Event时，要深拷贝原始结构体，否则多个 handler 看到的是被前面中间件污染的数据
要不要给中间件加 context.Context 支持
要，而且必须显式透传。很多中间件需要超时控制（如限流检查）、取消信号（如请求已中止）、或携带 trace 上下文。别依赖全局 context.Background()。
正确做法是把中间件签名升级为：type Middleware func(ctx context.Context, event Event, next func(context.Context, Event))，并在 Subscribe 时要求传入初始 ctx（如 context.WithTimeout 包装过的），或者让 Publish 接收 ctx 参数。不这么做，中间件就无法参与分布式追踪或超时传播——这是生产环境最常翻车的地方。
