必须设 Source 和 Type，否则 c.Send() 静默失败；source 用稳定标识符，type 用反向域名格式；SetData() 需显式设 MIME 类型；StartReceiver() 必须传带生命周期控制的 context；Kafka 发送需完整序列化事件而非仅 data；event.ID 应全局唯一且具业务意义。
用 cloudevents.NewEvent() 构造事件前，必须设 Source 和 Type
CloudEvents 规范强制要求每个事件至少携带 source 和 type 字段，否则 c.Send() 会静默失败或返回 cloudevents.IsUndelivered(err) —— 这是新手最常卡住的地方。SDK 不会帮你补默认值，也不会在日志里明确提示缺了啥。
-
source应为稳定标识符，比如"service/order"或"k8s/namespace/default"，别用动态值（如 PID、随机字符串） -
type要体现语义，例如"com.example.order.created"，推荐用反向域名格式，避免和第三方事件冲突 - 如果只传
map[string]string给SetData()，记得显式指定 MIME 类型：cloudevents.ApplicationJSON；否则接收端可能解析为空或报错
接收端用 c.StartReceiver() 时，别漏掉 context 生命周期控制
直接写 select {} 看似能常驻，但实际会导致 goroutine 泄漏、无法优雅退出、测试难 mock —— 尤其在 CLI 工具或 Operator 场景下极易出问题。
- 把
context.WithTimeout()或context.WithCancel()传给c.StartReceiver()，而不是裸传context.Background() - 接收函数体内别做阻塞操作（如同步 HTTP 调用），应转发到 worker channel 或启动新 goroutine 处理
- 若需按事件类型路由，别用 if-else 链，改用 map[
event.Type()]func(cloudevents.Event)注册 handler，便于热插拔
往 Kafka 发 CloudEvent，别直接序列化 event.Data()
Kafka 消费者看到的只是原始字节流，如果只发 event.Data()，上下文字段（id、time、source）全丢了，下游根本没法做幂等或路由。CloudEvents 明确要求 context 和 data 一起编码传输。
- 用
event.MarshalJSON()或event.ToHTTP()完整序列化整个事件，不是只序列化 data 字段 - 发送到 Kafka 前，建议加个
Content-Type: application/cloudevents+jsonheader（哪怕只是存作 record headers），方便消费者识别协议版本 - 如果 Kafka topic 要混用多种事件源，务必在
type字段里带上来源标识，比如"io.k8s.pod.started"vs"com.company.payment.succeeded"
跨服务传递时，event.ID 必须全局唯一且带业务意义
很多团队用 uuid.NewString() 填 ID，短期看不出问题，但一旦要查重、追踪、DLQ 重放，就会发现 ID 只是随机串，无法关联原始业务实体（比如订单号、Pod UID）。
立即学习“go语言免费学习笔记（深入）”；
- 优先复用业务主键 + 时间戳哈希，例如
"order_123456_" + fmt.Sprintf("%x", md5.Sum([]byte("2026-03-06T15:46:00Z"))) - 避免在多个 goroutine 并发调用
event.SetID()，cloudevents.Event不是线程安全的，应每个事件实例单独构造 - 如果上游是 Kubernetes Event（
corev1.Event），可用event.ObjectMeta.UID或event.ObjectMeta.Name映射为ID，保持可观测链路一致
真正麻烦的不是写对第一版，而是当事件开始被三个以上服务订阅、有重试和死信逻辑时，id、source、type 这三个字段的取值是否经得起回溯和审计——这时候再改就牵一发而动全身了。
