如何设计MongoDB支付流水保证数据可追溯？

支付流水必须可追溯，核心是通过_id+event_id+trace_id三重标识实现全链路留痕、不可篡改、时间有序、关联明确；状态变更须追加而非覆盖；时间字段需存ISODate(UTC)并附加timezone_offset和source_system；索引须覆盖event_id+updated_at+status组合查询。

支付流水必须可追溯，核心是保证每笔交易在全链路中留痕、不可篡改、时间有序、关联明确。MongoDB本身不提供全局事务级回滚或行级版本历史，靠设计补足。

用 _id + event_id + trace_id 三重标识锚定单笔流水

只依赖 _id 不够——它只是插入顺序标识，无法跨服务串联；纯靠业务字段如 order_id 又容易重复或缺失。真实生产中必须组合使用：

1. _id 保留为 ObjectId，用于唯一索引和快速定位
2. 强制写入 event_id（UUID v4），由发起方生成并透传，代表该事件原子操作（如“扣款请求”）
3. 写入 trace_id（如 W3C Trace Context 格式），用于跨服务调用链追踪，支持与 Jaeger / SkyWalking 对齐
4. 所有下游更新（如状态变更、对账结果）都复用同一组 event_id 和 trace_id，禁止生成新值

这样即使一笔支付被拆成“预授权→扣款→清算→退款”多个文档，也能靠 event_id 聚合成完整生命周期视图。

状态变更必须追加，禁用 updateOne() 覆盖原状态

常见错误是用 updateOne({ _id: xxx }, { $set: { status: "success" } }) 直接覆盖旧状态——这会丢失中间态（比如“pending”→“failed”→“recovered”），导致审计断点。

1. 正确做法：每次状态变更都 insertOne() 新文档，带 status、updated_at、operator、reason 字段
2. 或在同一文档内用 $push 追加到 history 数组：{ $push: { history: { status: "success", at: new Date(), by: "system" } } }
3. 数组长度需设上限（如 50 条），超限时用 TTL 索引自动清理陈旧条目，避免文档膨胀

注意：如果选数组方式，务必对 history.status 建 multikey index，否则按状态查历史会慢。

关键字段必须带时区信息与来源标记

支付系统常跨时区运行，created_at 或 settled_at 若只存 UTC 时间但没标注时区来源，对账时极易误判“是否当日完成”。

1. 所有时间字段统一存 ISODate（UTC），同时额外存 timezone_offset（如 "+08:00"）和 source_system（如 "core_banking_v3"）
2. 避免用字符串存时间（如 "2026-07-21 15:30:00"），MongoDB 无法对其做范围查询或聚合计算
3. 对账类查询常需按“本地营业日”统计，这时必须靠 timezone_offset 动态转换，不能靠应用层硬编码偏移

漏掉 source_system 会导致问题定位困难——比如发现某批流水 amount 异常，却无法快速判断是哪个子系统写入的。

索引要覆盖 event_id + updated_at + status 组合查询

运维查问题最常跑的语句是：“查 event_id=xxx 的所有状态变更，按时间倒序看” 或 “查今天失败的所有流水”。若没建对索引，哪怕数据量百万级也会秒变慢查询。

1. 必须建复合索引：db.transactions.createIndex({ event_id: 1, updated_at: -1 })
2. 高频查状态分布时，再加一个：db.transactions.createIndex({ status: 1, updated_at: -1 })
3. 慎用通配符索引（{"$**": 1}）——它会让写入变慢，且无法支撑精确范围查询

特别提醒：如果用 history 数组存状态变更，索引必须声明为 multikey，即对数组内每个元素建索引，否则 history.status 查询走不了索引。

真正难的不是记录动作，而是让所有服务达成一致的“留痕契约”：谁生成 event_id、谁负责填 trace_id、谁校验 timezone_offset 是否合法——这些不在数据库里，而在接口规范和上线检查清单里。