支付流水必须可追溯，核心是通过_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 又容易重复或缺失。真实生产中必须组合使用：
-
_id保留为 ObjectId，用于唯一索引和快速定位 - 强制写入
event_id（UUID v4），由发起方生成并透传，代表该事件原子操作（如“扣款请求”） - 写入
trace_id（如 W3C Trace Context 格式），用于跨服务调用链追踪，支持与 Jaeger / SkyWalking 对齐 - 所有下游更新（如状态变更、对账结果）都复用同一组
event_id和trace_id，禁止生成新值
这样即使一笔支付被拆成“预授权→扣款→清算→退款”多个文档，也能靠 event_id 聚合成完整生命周期视图。
状态变更必须追加，禁用 updateOne() 覆盖原状态
常见错误是用 updateOne({ _id: xxx }, { $set: { status: "success" } }) 直接覆盖旧状态——这会丢失中间态（比如“pending”→“failed”→“recovered”），导致审计断点。
- 正确做法：每次状态变更都
insertOne()新文档，带status、updated_at、operator、reason字段 - 或在同一文档内用
$push追加到history数组：{ $push: { history: { status: "success", at: new Date(), by: "system" } } } - 数组长度需设上限（如 50 条），超限时用 TTL 索引自动清理陈旧条目，避免文档膨胀
注意：如果选数组方式，务必对 history.status 建 multikey index，否则按状态查历史会慢。
关键字段必须带时区信息与来源标记
支付系统常跨时区运行，created_at 或 settled_at 若只存 UTC 时间但没标注时区来源，对账时极易误判“是否当日完成”。
- 所有时间字段统一存 ISODate（UTC），同时额外存
timezone_offset（如 "+08:00"）和source_system（如 "core_banking_v3"） - 避免用字符串存时间（如 "2026-07-21 15:30:00"），MongoDB 无法对其做范围查询或聚合计算
- 对账类查询常需按“本地营业日”统计，这时必须靠
timezone_offset动态转换，不能靠应用层硬编码偏移
漏掉 source_system 会导致问题定位困难——比如发现某批流水 amount 异常，却无法快速判断是哪个子系统写入的。
索引要覆盖 event_id + updated_at + status 组合查询
运维查问题最常跑的语句是：“查 event_id=xxx 的所有状态变更，按时间倒序看” 或 “查今天失败的所有流水”。若没建对索引，哪怕数据量百万级也会秒变慢查询。
- 必须建复合索引：
db.transactions.createIndex({ event_id: 1, updated_at: -1 }) - 高频查状态分布时，再加一个：
db.transactions.createIndex({ status: 1, updated_at: -1 }) - 慎用通配符索引（
{"$**": 1}）——它会让写入变慢，且无法支撑精确范围查询
特别提醒：如果用 history 数组存状态变更，索引必须声明为 multikey，即对数组内每个元素建索引，否则 history.status 查询走不了索引。
真正难的不是记录动作，而是让所有服务达成一致的“留痕契约”：谁生成 event_id、谁负责填 trace_id、谁校验 timezone_offset 是否合法——这些不在数据库里，而在接口规范和上线检查清单里。
