event sourcing在go中是状态管理哲学而非功能库，必须同步约束聚合根设计、事件序列化与存储原子性，否则将引发重放不一致、版本跳跃、事件丢失等静默故障。
EventSourcing在Go中不是“加个库就能用”的功能
它是一套状态管理哲学，必须从聚合根设计、事件序列化、存储写入原子性三个层面同步约束，否则很快会遇到重放不一致、版本跳跃、事件丢失等静默故障。Go语言没有运行时反射强制校验，所有事件类型注册、版本递增、Apply顺序都得靠代码约定和测试兜底。
聚合根必须显式管理版本与未提交事件
常见错误是把 Apply 当成普通方法调用，直接修改字段而不生成事件；或者在构造函数里预设初始状态，绕过事件溯源链。正确做法是：所有状态变更只能由 Apply 触发，且每次调用必须产生一个新事件并追加到 UncommittedEvents 切片中。
-
LoadFromHistory必须按version升序读取并逐个Apply，不能跳过中间版本 - 聚合根初始化时
Version应为 0，首次Apply后变为 1 - 写入前需校验事件的
AggregateID和Version是否匹配当前聚合最新版本（防止并发覆盖） - 事务提交成功后才清空
UncommittedEvents，失败则保留供重试或诊断
事件存储不能依赖通用ORM的Save方法
用 GORM 或 sqlx 直接 Insert 一个事件结构体看似简单，但会丢失关键约束：事件必须按版本严格递增、同一聚合内不能存在重复版本、写入需保证原子性（事件+聚合版本更新必须一起成功或失败）。PostgreSQL 的 INSERT ... ON CONFLICT DO NOTHING 或 SQLite 的 WAL 模式更适合作为起步方案。
- 表结构至少包含：
aggregate_id（主键部分）、version（唯一联合索引）、event_type、payload（JSONB 或 TEXT）、created_at - 插入前必须查出当前最大
version，新事件version = max_version + 1，否则拒绝写入 - 避免用
json.Marshal直接存结构体指针——nil字段会被忽略，导致反序列化后字段为空而非零值 - 不要在事件 payload 中嵌套聚合根实例，只存原始业务数据（如
UserCreated{Email: "a@b.com"}，而非*User）
重放状态时别忽略元数据与时间戳校验
很多团队只重放 Data 字段，却忽略 Timestamp 和 Metadata。这会导致审计失效、调试困难，甚至在跨时区部署时出现逻辑错乱（比如基于时间的限流规则误判）。重放函数应接收完整事件接口，而非仅解包 payload。
- 定义统一事件接口：
type Event interface { EventType() string; AggregateID() string; Version() int64; Timestamp() time.Time; Metadata() map[string]string } - 重放前检查
Timestamp是否早于聚合创建时间（防时钟回拨） - 对含敏感操作的事件（如
PasswordResetRequested），在Metadata中记录请求 IP、用户代理等上下文，不混入业务 payload - 测试重放逻辑时，务必用真实历史事件序列跑通，而不是只测单个事件的
Apply
最易被忽略的是事件重命名后的兼容性处理——一旦上线，EventType 就是契约，改名等于断裂历史链。需要提前设计迁移策略，比如保留旧类型别名、在反序列化层做映射，而不是指望“以后再重构”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
