go中事件溯源必须保证状态仅由重放事件推导、事件不可变、apply()纯内存幂等、快照与事件事务一致；禁用map[string]interface{}，须用导出结构体实现统一event接口，并严格遵循序列化与重放约束。
Go 里做 Event Sourcing，不是“把变更塞进 Kafka 就算完事”，而是必须保证：状态只能由重放事件推导、事件不可变、Apply() 幂等无副作用、快照与事件事务一致——缺一不可。否则你只是在写带时间戳的 CRUD 日志。
Go 中定义事件结构体为什么不能用 map[string]interface{}
用 map[string]interface{} 接事件数据，上线后大概率 panic：字段名大小写错（比如前端传 user_id，Go 解析成 UserID 后再序列化又变回 user_id）、整型 ID 被转成 float64、缺失字段静默丢弃。
- 所有事件字段首字母必须大写（导出），否则
json.Marshal忽略 - 禁止用
*time.Time，统一用time.Time；禁止嵌套未导出字段或方法 - 每个事件必须实现统一接口，例如
type Event interface { EventType() string; AggregateID() string; Version() int; Timestamp() time.Time } - 持久化前用
json.Marshal得到json.RawMessage，连同EventType、Version一起存库，不存裸 struct
Apply() 方法为什么必须纯内存且幂等
重放时可能多次调用同一事件的 Apply()（比如从快照恢复后补事件、测试重试、调试重放），如果里面写了 DB 插入、HTTP 请求或改全局变量，状态就乱了。
-
Apply()只允许修改聚合根当前内存状态字段，如a.status = event.Status、a.balance += event.Amount - 禁止调用
db.Exec()、log.Printf()、time.Now()、http.Get()等任何外部依赖 - 推荐返回新状态 struct，而非修改 receiver（更易测、更函数式）
- 测试时断言：
Apply(e); Apply(e)后状态值不变 - 常见翻车点：在处理
AddItem命令时直接a.Items = append(a.Items, newItem)，却没生成ItemAdded事件——系统从此丢失事实，审计和重建全失效
快照（Snapshot）不是可选项，是并发与性能的生死线
当一个订单聚合重放 5000 条事件才能得到当前状态，每次查询都这么干，CPU 和延迟立刻崩盘。快照不是“锦上添花”，而是必须设计的环节。
- 快照触发条件建议按事件数量（如每 100 条）或时间窗口（如每 24 小时），而非固定时间点
- 快照内容只存聚合根当前状态字段，不存事件历史、不存引用对象指针、不存未导出字段（否则 JSON 序列化失败）
- 加载逻辑必须兼容：先查最新快照 → 若存在则初始化聚合 → 再重放该快照之后的所有事件；若无快照，则从头重放
- 快照版本号（
SnapshotVersion）必须严格对应所覆盖的最高事件Version，否则重放会漏事件
用 Kafka 做事件总线时，kafka-go 怎么配才不丢事件
Kafka 天然适合事件溯源，但 Golang 客户端默认配置极易丢数据：网络抖动、broker 重启、producer 缓冲区满都会静默失败。
- 必须设置
RequiredAcks: kafka.RequireAll（而非默认的RequireNone），否则消息发出去就不管 broker 是否写入成功 -
BatchSize和BatchTimeout要平衡吞吐与延迟：高并发场景下BatchSize: 100+、BatchTimeout: 100 * time.Millisecond较稳 - 务必启用
RetryBackoff（如500 * time.Millisecond），否则临时连接失败直接 panic - 别复用
kafka.Writer实例跨 goroutine —— 它不是并发安全的，需按 topic 或 aggregate 分实例管理 - 写入前先确保事件已成功持久化到数据库，再发到 Kafka；否则出现 DB 成功但 Kafka 失败，就会导致状态与事件不一致
最常被忽略的一点：事件重放不是“越快越好”，而是“越确定越好”。哪怕某次 ApplyEvent 返回 error，也得记录并告警，不能静默忽略——因为“可回溯”的前提是每条事件都真实参与过状态构建。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
