3. 不可变流水核心概念
在金融 Ledger 系统中，流水不是一张可随意修改的表格，而是一段只允许追加、不允许覆盖的事实记录。理解不可变流水的核心，需要同时掌握七个概念：事件溯源、追加写入、不可篡改、哈希链、版本控制、审计追踪与数据完整性。它们不是孤立术语，而是共同构成“余额如何从流水派生”的可信基础。
一句话主线：业务动作先变成事件，事件以追加方式写入流水，流水通过哈希链和版本控制形成可验证历史，审计追踪回答“谁在何时改了什么”，数据完整性保证余额派生结果可复算、可对账、可追责。
一、核心原理：事件溯源与追加写入
事件溯源（Event Sourcing）主张不直接保存“当前余额”作为唯一真相，而是保存导致余额变化的所有事件。例如开户、入金、出金、冻结、解冻、手续费、冲正，每一个动作都是一条不可变事件。当前余额只是这些事件按顺序重放后的派生结果。
追加写入（Append-Only）是事件溯源的存储约束：新事件只能追加到流水末尾，不能修改或删除已有事件。若业务发生错误，正确做法不是“改掉旧流水”，而是追加一条冲正或调整事件。这样，历史始终保留，余额变化路径完整可查。
账户 A 流水示例：
evt_001 OPEN_ACCOUNT +0.00
evt_002 DEPOSIT +1000.00
evt_003 WITHDRAW -200.00
evt_004 FEE -1.00
evt_005 REVERSAL_FEE +1.00 # 冲正手续费，而非删除 evt_004
当前余额 = 1000.00 - 200.00 - 1.00 + 1.00 = 800.00这种设计带来两个直接收益：第一，任何时点余额都可以通过重放截止该时点的事件得到；第二，任何余额差异都可以回溯到具体事件，而不是面对一个被覆盖过的数字。
二、不可篡改、哈希链与版本控制
不可篡改不是口号，而是由存储策略和密码学共同保证。单条流水一旦写入，其关键字段（事件 ID、账户、金额、币种、时间、业务序号、前序哈希）应被固化。哈希链进一步把每条事件与前一条事件绑定：
hash_1 = SHA256(evt_001 内容 + genesis_hash)
hash_2 = SHA256(evt_002 内容 + hash_1)
hash_3 = SHA256(evt_003 内容 + hash_2)
...
若 evt_002 被篡改，则 hash_2 变化，hash_3 及后续全部校验失败。版本控制则解决“规则变化”问题。金融系统常遇到费率调整、精度变更、账户模型升级。版本控制不是修改旧流水，而是为事件附加 schema 版本、规则版本或账本版本。重放时按事件发生时的版本解释，避免用新规则错误重算旧业务。
| 概念 | 解决的问题 | 典型实现 | 失败后果 |
|---|---|---|---|
| 事件溯源 | 余额真相来源 | 事件表 + 重放 | 余额无法解释 |
| 追加写入 | 历史不可覆盖 | Append-Only 存储 | 历史被改写 |
| 哈希链 | 检测篡改 | SHA-256 前序哈希 | 篡改无法发现 |
| 版本控制 | 规则演进兼容 | schema_version / rule_version | 旧账重算错误 |
| 审计追踪 | 责任归属 | 操作者、来源、原因码 | 无法追责 |
| 数据完整性 | 可复算可对账 | 校验和、快照、对账任务 | 账实不符 |
三、方法流程：从事件写入到余额派生
一个可落地的不可变流水系统，通常按以下流程运转：
- 事件建模：把业务动作定义为事件类型，明确金额方向、币种、账户、业务单号、发生时间、操作者、原因码。
- 追加写入：在事务中写入事件表，同时计算当前事件哈希，并记录前序哈希。
- 版本标注：为事件附加 schema_version、rule_version、ledger_version，确保未来重放可解释。
- 余额派生：通过重放引擎按事件顺序累加，生成余额快照；高频账户可定期落快照，减少全量重放成本。
- 完整性校验：定时校验哈希链、快照与流水重放结果是否一致，发现差异立即告警。
- 审计追踪：记录谁写入、从哪个系统写入、依据哪条业务指令，形成可追责链路。
实践提示：余额快照不是真相，只是加速派生的缓存。任何快照都必须能通过“快照 + 后续事件重放”回到当前余额，否则快照不可信。
四、案例与场景：一笔冲正如何保持不可变
假设用户入金 1000 元后，系统误收 1 元手续费。传统做法可能直接更新手续费记录为 0，但这样会丢失“曾经收过费”的事实。不可变流水做法是追加一条冲正事件：
evt_004 FEE -1.00 rule_version=v1
evt_005 REVERSAL_FEE +1.00 reason=SYSTEM_ERROR
ref_evt=evt_004
operator=ops_zhang
schema_version=v2此时余额恢复为 1000 元，但审计追踪仍能看到：谁在何时因何原因冲正了哪条事件。对账时，evt_004 和 evt_005 同时存在，净额为 0，既保证数据完整性，也保留操作痕迹。
五、误区与复盘
- 误区一：不可变等于不能纠错。纠错靠追加冲正事件，而不是修改历史。
- 误区二：只存余额就够了。没有流水，余额差异无法解释，审计和重放都无从谈起。
- 误区三：哈希链只做一次校验。哈希链应持续校验，尤其在批量导入、迁移、灾备恢复后。
- 误区四：版本控制只记在代码里。版本必须随事件落库，否则未来无法按当时规则重放。
- 误区五：审计追踪只记操作者。还应记录来源系统、业务单号、原因码、前后哈希，才能形成完整证据链。
复盘要点：不可变流水的价值不在“不能改”，而在“改了能被发现，错了能追加纠正，余额能重放验证，责任能追溯到人”。这四点同时成立，余额派生才具备金融级可信度。
掌握这些核心概念后，后续设计流水表结构、哈希计算、快照策略和对账任务时，才能始终围绕“事实不可变、派生可验证、审计可追踪”这一主线展开。