不能直接传递 context.Context 作为事件参数，因其含运行时状态（如 cancel channel、deadline），异步处理时易过期或 panic；应提取必要字段（如 ReqID、Deadline）固化到事件结构体中。
为什么不能直接把 context.Context 作为事件参数传递
Go 的事件分发（比如用 github.com/google/uuid 配合自定义通知器，或基于 sync.Map 实现的简单事件总线）通常要求事件数据是可序列化、无状态、无引用依赖的。而 context.Context 是一个接口类型，内部包含 deadline、cancel channel、value map 等运行时状态，**无法安全跨 goroutine 传递或复用**——尤其当事件被异步处理、缓存、重试或转发到其他模块时，原 Context 可能已过期、被 cancel，甚至引发 panic（例如调用 ctx.Done() 返回已关闭 channel 后再读取）。
推荐做法：只传 context.Context 的必要衍生信息
真正需要的往往不是整个 Context，而是它携带的某些“上下文事实”，比如请求 ID、超时剩余时间、用户身份标识等。应在事件生成阶段就提取并固化这些值：
-
reqID := ctx.Value("request_id").(string)（注意类型断言安全） -
deadline, ok := ctx.Deadline()→ 转为time.Time字段存入事件结构体 - 用
ctx.Value()提取的业务相关键值（如"user_id"、"trace_id"）应显式复制，不保留对ctx的引用 - 避免在事件结构体中嵌入
context.Context字段；若必须保留取消信号，可用chan struct{}替代（但需确保该 channel 不被多次 close）
如果真要支持 cancel 传播，用 context.WithCancel + 显式生命周期管理
某些场景（如长周期任务监听事件后启动子任务）确实需要下游能响应上游取消。这时不应传递原始 ctx，而应在事件处理器中创建新 Context：
// 事件结构体里不存 ctx，但带一个标记
type NotifyEvent struct {
ReqID string
Timeout time.Duration // 或 Deadline time.Time
// ... 其他业务字段
}
// 处理器内按需派生
func (h *Handler) Handle(e NotifyEvent) {
childCtx, cancel := context.WithTimeout(context.Background(), e.Timeout)
defer cancel() // 确保退出时清理
// 启动依赖 childCtx 的子操作
go doWork(childCtx, e.ReqID)
}
关键点：context.WithCancel / WithTimeout 必须在事件消费端调用，而非生产端；否则 cancel 函数可能被丢弃或误触发。
立即学习“go语言免费学习笔记（深入）”；
常见踩坑：用 context.WithValue 包裹事件再发出去
有人会写 newCtx := context.WithValue(oldCtx, "event", e) 然后把 newCtx 传给 handler —— 这看似“带上了上下文”，实则危险：
- handler 若保存该
newCtx并长期持有，会阻止oldCtx的 GC，尤其当oldCtx关联大对象（如 HTTP 请求体）时 - 多个事件共用同一
oldCtx，彼此 cancel 会互相干扰 -
context.WithValue不是设计用来承载业务数据的；它的语义是“传递请求范围的元数据”，不是“事件载荷容器”
真正要解耦事件与上下文，就得接受：事件是独立消息，Context 是执行时的环境凭证——两者应在边界处拆开，而不是强行缝合。
