Go中无法直接套用HTTP中间件模式，因消息总线处理函数签名由业务决定，强行统一将导致类型擦除；推荐用泛型BusHandler[T]接口与链式ChainHandler实现类型安全的拦截器组合。
Go 里没有现成的“消息总线拦截器”抽象，但可以用函数组合 + 接口包装实现，核心是把 Handler 变成可链式增强的类型。
为什么不能直接用中间件模式套 HTTP 那套
HTTP 中间件依赖 http.Handler 的固定签名 func(http.ResponseWriter, *http.Request)，而消息总线的处理函数签名完全由业务决定（比如 func(*OrderEvent)、func(context.Context, []byte)）。强行统一会导致类型擦除或大量 interface{}，失去编译期检查和性能优势。
实际踩坑点：
- 用
func(interface{})包一层再反射调用，运行时 panic 难定位，且无法静态校验参数匹配 - 把所有事件塞进
map[string]interface{}，后续加字段或改结构时无提示、易出错 - 拦截逻辑写在每个 handler 里，重复代码多，权限/日志/重试等逻辑散落各处
推荐做法：定义带泛型的 BusHandler[T] 接口
让每个事件类型拥有专属 handler 类型，拦截器只对具体类型生效，既保类型安全，又支持链式组合。
示例结构：
type BusHandler[T any] interface {
Handle(context.Context, T) error
}
type ChainHandler[T any] struct {
handlers []BusHandler[T]
}
func (c *ChainHandler[T]) Handle(ctx context.Context, msg T) error {
for _, h := range c.handlers {
if err := h.Handle(ctx, msg); err != nil {
return err
}
}
return nil
}
这样你可以写：
- 一个日志拦截器：
type LoggingHandler[T any] struct{ next BusHandler[T] } - 一个重试拦截器：
type RetryHandler[T any] struct{ next BusHandler[T]; maxRetries int } - 它们都实现
BusHandler[T]，就能无缝接入ChainHandler
如何注册并触发带拦截链的 handler
总线本身不负责拦截逻辑，只提供注册点和分发入口。关键在于注册时就组装好链，而不是每次分发时动态构建 —— 避免 runtime 开销。
示例注册方式：
// 定义业务 handler
type OrderCreatedHandler struct{}
func (h OrderCreatedHandler) Handle(ctx context.Context, e OrderCreated) error {
fmt.Println("processing order:", e.ID)
return nil
}
// 组装链（顺序重要：Log → Retry → 实际 handler）
bus.RegisterHandler(&OrderCreated{},
&LoggingHandler[OrderCreated]{next: &RetryHandler[OrderCreated]{
next: &OrderCreatedHandler{},
maxRetries: 3,
}},
)
分发时只需：
bus.Publish(ctx, OrderCreated{ID: "ord-123"})
注意点：
- 不要在
Publish内部做反射判断类型再找 handler，应提前建好map[reflect.Type]BusHandler[any]或用泛型 map（Go 1.22+） - 拦截器中若需修改消息内容（如加 traceID），必须传指针或返回新实例，值类型无法被上游感知
- 上下文传递要显式透传，别依赖闭包捕获 —— 否则并发下 ctx 被复用导致 deadline 错乱
容易被忽略的边界：错误传播与上下文取消
拦截器链里任意一环返回 error，是否继续执行后续？是否需要回滚前序操作？Go 没有内置事务语义，这些必须由业务 handler 自己控制。
更关键的是 context 取消：
- 如果
LoggingHandler在Handle开头打日志，但ctx.Done()已触发，你还该打吗？—— 应该先select { case - 如果
RetryHandler重试三次，每次间隔 100ms，但 ctx 50ms 就超时了，它必须立刻退出，不能硬等 - 所有拦截器的
Handle方法签名必须接受context.Context，且必须检查取消状态
这不是“加个 defer”能解决的，是整个链的契约 —— 每一层都得尊重 ctx，否则拦截器反而成了 cancel 泄漏点。
