财务不平本质是异常未捕获导致数据写入不完整，须从数据流闭环反推：先锁定失衡明细与断点，逆向追踪典型流水全链路状态，排查非exception类隐形缺口，修复后需真实重放验证+故障模拟检验补偿能力。
这类问题本质是“异常未被捕获→逻辑跳过→数据写入不完整→财务结果失真”，排查不能只盯代码try-catch，要从数据流闭环反推。
先锁定失衡数据的精确断点
财务不平不是模糊现象，它一定对应某笔交易、某个账户、某类凭证的差额。立刻做三件事：
- 导出当前不平的明细账（如：总账 vs 明细账差额为+128,450.60元）；
- 按时间倒序筛出该差额发生前最后10笔业务流水，重点看金额、方向、状态字段；
- 比对这些流水在各环节的记录一致性——比如订单服务记了“已支付”，但清分服务没生成对应分账单，或对账服务漏掉了这笔冲正。
逆向追踪每笔异常业务的生命周期
选一笔典型失衡流水，沿其全链路回溯（非代码行，而是数据状态）：
- 原始请求是否到达网关？查API网关日志中该traceId是否有4xx/5xx或超时；
- 核心服务是否完成主事务？查数据库该订单的status是否卡在“支付中”而非“已清分”；
- 下游补偿动作是否触发？查消息队列中是否有对应topic的失败重试记录，或死信队列堆积；
- 财务侧是否收到最终确认？查ERP接口调用日志里该单号是否有“成功返回但无响应体”的空报文。
检查异常捕获的“隐形缺口”
很多财务不平源于被忽略的非Exception场景：
- 异步回调无幂等校验：同一笔支付通知重复抵达，第一次成功入账，第二次因主键冲突静默失败，未记异常日志；
- 超时后主动撤回但未回滚：支付网关返回超时，服务端发起撤单，但撤单成功后未同步更新本地订单状态，导致后续对账时该单“既不算收入也不算退款”；
- JSON解析容忍过度：上游多传一个空字段，Jackson自动设为null，下游用该null计算金额时未判空，直接参与加减得出0值并写库。
验证修复是否真正堵住漏洞
改完代码后，必须做两件事才敢上线：
- 用真实差额数据构造测试用例，在预发环境重放，确认异常时能明确抛出带业务上下文的Error（如：“PayNotifyHandler-重复通知-单号PAY20260518001”），且触发告警；
- 人工模拟一次“网络抖动+部分服务不可用”的组合故障，观察系统是否在恢复后自动完成对账补偿，而不是依赖人工干预补单。
