Golang中基于反射机制的轻量级消息分发总线设计-Golang-PHP中文网

反射非必需但可省去类型注册和断言，代价是panic难定位、性能降10%~30%、签名无法静态检查；reflect.value.call是核心，因仅它支持动态参数拆包调用，且要求首参为事件类型、次参（可选）为context.context。

golang中基于反射机制的轻量级消息分发总线设计

反射不是必须的，但用对了能省掉大量类型注册和断言代码；不过它会让 panic 更难定位、性能下降 10%~30%，且无法静态检查订阅函数签名是否匹配事件类型。

纯函数订阅（如 func(string, interface{})）无法直接适配多种事件结构体，比如 UserCreatedEvent 和 OrderPaidEvent。反射允许总线在运行时动态调用任意签名的 handler，只要参数数量和类型能匹配事件本身。

必须用 reflect.Value.Call 而非直接调用：只有它能接受 []reflect.Value 参数列表，把事件实例自动拆包成 handler 所需的参数
handler 第一个参数必须是事件接口或具体结构体，第二个可选为 context.Context，其余不被支持——否则 Call 会 panic
不要在 Call 外层 recover：必须包裹在实际调用点，例如 sub.fn.Call([]reflect.Value{ev, ctx}) 周围，否则捕不到 handler 内部 panic

用户传进来的 handler 函数若参数错位或类型不兼容，会在首次 Emit 时才暴露 panic，调试成本高。应在 Subscribe 阶段就做静态校验。

Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。

下载

用 reflect.TypeOf(fn).NumIn() 检查入参个数：合法值为 1（仅事件）或 2（事件 + context）
第一个参数必须是导出结构体或实现了 Event 接口的类型，用 t.In(0).Kind() == reflect.Struct || t.In(0).Implements(eventType) 判断
第二个参数若存在，必须是 context.Context，否则拒绝注册并返回 error
校验失败时不 panic，而是返回明确错误，比如 "handler signature mismatch: expected (UserCreatedEvent) or (UserCreatedEvent, context.Context)"

反射对象不是 goroutine 安全的——reflect.Value 实例一旦被多个 goroutine 同时调用 Call，可能引发不可预测行为，尤其当底层值是 map 或 slice 时。

每次 Emit 都应调用 reflect.ValueOf(event) 新建实例，不要缓存或跨 goroutine 复用
避免把 reflect.Value 存入 map 或 channel：它内部持有指向原始值的指针，多 goroutine 修改同一底层数组会导致竞态
若 handler 需要修改事件字段，必须先用 .Interface().(*MyEvent) 转回原类型再改，不能直接对 reflect.Value 调用 Set* —— 总线不应承担修改责任

反射调用失败时，堆栈里只显示 reflect.Value.call，看不到真实 handler 名称和行号，排查效率极低。

在 Call 前记录 handler 地址：fmt.Sprintf("%p", reflect.ValueOf(fn).Pointer())，日志中带上该标识
用 runtime.FuncForPC 尝试还原函数名：在 defer recover 块中获取 reflect.ValueOf(fn).Call 的 PC，再查符号表
最稳妥的做法是：开发期强制开启 -gcflags="-l" 禁用内联，让 handler 函数保留在堆栈中；线上则依赖日志中的 fn.Pointer() 和事件类型做交叉定位

真正难的不是怎么写反射调用，而是怎么让别人（包括三个月后的你自己）在 panic 日志里一眼看出是哪个 handler、哪类事件、在哪一行崩的。类型安全和可观测性，比“少写几行代码”重要得多。