题干与适用场景
订单系统每天产生 2 亿笔交易。内部账本记录订单、支付、退款和手续费；支付服务商按结算批次提供报告；银行提供实际入账流水。请设计一条 T+1 对账管道，在次日 6 点前完成前一日数据，识别漏记、重复、金额、手续费和币种差异，支持重跑、人工复核、退款、多币种和审计留痕。
题目默认内部账本是业务事实来源，支付商和银行是外部事实来源。对账结果不能直接覆盖账本，也不能因为总额相等就隐藏单笔差异。金额、币种、结算日、批次和证据链必须可追溯。
面试官考察点
第一项是能否先定义事实、时间和不变量。候选人应区分交易发生日、入账日、结算日和银行价值日，并明确金额使用最小货币单位、币种不可省略、同一外部流水可重复导入。
第二项是能否把匹配从“全表 join”变成分层策略。先用支付商交易 ID、批次 ID 等强键匹配，再用受限的订单号、金额、币种和时间窗口匹配；模糊匹配必须进入人工队列，不能静默自动确认。
第三项是能否设计差异闭环。差异要有类型、严重级别、证据、负责人、状态、截止时间和修复动作；修复后仍要保留原始差异与新的对账版本。
回答前需要澄清的问题
- 对账边界是什么？ 是支付授权、捕获、退款、手续费、提现，还是银行到账全部覆盖？
- 6 点截止按哪个时区？ 结算日和报告生成日是否跨越夏令时或节假日？
- 外部报告是否可增量获取？ 是否有稳定文件名、游标、版本号和重试下载接口？
- 允许自动调整账本吗？ 默认只生成待处理调整单，由有权限的流程审批后入账。
- 多币种按什么汇率？ 交易币种、结算币种和银行入账币种是否都要保留，汇率来源和精度是什么？
- 差异多久必须解决？ 需要定义高金额、合规和客户影响差异的升级路径。
30 秒回答框架
“我先把三方事实保存为不可变原始层，再统一金额、币种、时间和外部 ID。管道按报告版本幂等导入，先用强键匹配，再用受限组合键匹配，任何不确定结果进入人工队列。每个批次同时做行级、分组和总额校验，差异以可审计状态机管理，修复通过审批后的调整单完成。调度上按截止时间倒推，监控文件完整性、延迟、匹配率、未决金额和重跑次数，并用重复文件、晚到退款、部分结算和汇率变化做演练。”
分步骤深入解答
第一步：定义事实模型和账期
建立 internal_entry、provider_entry、bank_entry 三类不可变事实，统一保留原始文件哈希、行号、来源、抓取时间、报告版本、业务日期和结算日期。金额使用整数最小货币单位，禁止用浮点数；币种作为必填字段。内部账本的订单状态与资金状态分开，避免把“支付成功”误当成“已到账”。
第二步：按来源版本幂等接收
下载任务先写入对象存储，再校验文件大小、哈希、签名和预期行数。以 source + report_id + version + row_number 建立唯一键，重复下载只增加接收记录，不重复记账。供应商提供的报告版本变化要保留旧版本，并记录替换关系，禁止原地覆盖。
unique_key = source + report_id + version + row_number
if unique_key already exists: record_duplicate_download()
else: persist_raw_row()第三步：建立可重跑的标准化层
标准化层将状态、金额符号、时区、手续费类型和外部 ID 映射到版本化字典。每次转换写入 normalization_run_id，输入快照和规则版本固定后可以重跑。无法识别的状态、负金额语义或未知币种进入隔离区，不应被默认转成零。
第四步：采用分层匹配策略
第一层使用支付商交易 ID、退款 ID、提现 ID 等稳定强键。第二层在同一商户、币种和结算日内使用订单号、金额和允许的时间窗口。第三层只产生候选对，不自动确认；金额相同但币种不同、一个内部单对应多笔外部单、或一笔外部单拆成多次结算，都进入人工复核。
第五步：用三层控制证明结果
行级控制检查每条事实是否最多匹配一次。分组控制按批次、币种、结算日和手续费类型比较笔数与金额。总额控制比较内部账本、支付商报告和银行到账的期初、流入、流出、手续费、退款与期末余额。三层不一致时保留各层证据，不能只展示一个“通过”标记。
第六步：把差异做成状态机
差异类型至少包括缺失、重复、金额不符、手续费不符、币种或汇率不符、日期错位和未知外部状态。状态可以是 open、investigating、adjustment_pending、resolved、accepted，每次变更记录操作者、理由、证据和时间。高金额或合规差异需要双人审批，自动任务只能创建调整建议。
第七步：处理晚到、退款和部分结算
报告晚到时先关闭已收到范围，保留批次为未完成，不能把暂时缺失当成永久漏记。退款和拒付可能在原交易日之后出现，要通过事件日期与结算日期分别入账。部分结算要保留外部批次与内部交易的一对多关系，余额相等也不能抹掉未匹配行。
第八步：安排恢复、重跑和审计
每个运行保存输入文件清单、快照时间、规则版本、匹配结果和输出差异。失败后从最后一个成功阶段重跑，重跑结果通过运行 ID 隔离，再以唯一键合并。保留原始文件、哈希、报告版本、人工决定和调整凭证，支持按批次、交易和差异追溯。Stripe 的报告也将余额、交易和 payout 分开，并建议使用 payout ID 关联其中的 balance transactions，这说明外部结算批次不能被简化成一个总金额。
设计取舍与边界
取舍一：强键优先还是更高匹配率
强键匹配的自动化率可能较低，但误配成本可控。扩大金额和时间窗口会提高匹配率，也会增加把两笔相似交易错误合并的风险。应把阈值、窗口和回退规则配置化并版本化，所有非确定匹配进入人工队列。
取舍二：每日批处理还是准实时
T+1 批处理更容易复现和审计；准实时流可以更早发现高金额差异，却需要处理报告版本变化、晚到数据和重复事件。可以先用批处理作为账务结论，再用流做预警，避免把预警当成最终对账结果。
取舍三：自动调整还是人工审批
小额、规则明确且可逆的差异可以进入受限自动调整；高金额、币种异常、重复扣款和合规相关差异必须人工审批。无论哪种路径，都保留原始事实和调整凭证，不修改历史行。
失败演练与演进计划
演练一：重复文件和重复行
连续投递同一报告三次，验证文件哈希、报告版本和行唯一键不会产生重复账。再让同一交易出现在两个版本，验证版本关系和最终选用规则可解释。
演练二：晚到退款与部分结算
让退款在结算日后两天到达，并把一笔订单拆到两个 payout。验证交易日、结算日和到账日分别统计，差异在新运行中关闭而历史运行保持不变。
演练三：报告缺页和错误汇率
删除一页报告或替换汇率表，验证行数、哈希、总额和币种控制会阻断发布，并把批次标记为待补数，而不是生成“已对账”。
常见误区与追问
误区一：只比较三方总额
总额相等时仍可能存在一笔漏记和一笔重复。必须保留行级匹配、分组控制和总额控制。
误区二：用浮点数存金额
浮点误差会制造虚假差异。金额应使用整数最小单位或定点数，并同时记录币种。
误区三：覆盖旧报告
覆盖会破坏审计和重跑依据。报告应不可变保存，以版本关系表达更正。
误区四：模糊匹配自动入账
相同金额和相近时间不等于同一交易。模糊结果应进入人工复核，并显示候选证据。
误区五：把支付成功当成银行到账
支付状态、支付商结算和银行到账是不同事实，必须分别建模并用批次关系连接。
误区六：忽略报告生成和时区
报告可能在结算日后才可用，跨时区和节假日会造成假性漏记。调度应使用来源承诺时间，并显式保存时区。
误区七：修复时直接改历史账
直接改历史会失去原始证据。修复应通过审批后的调整单，并关联原差异和新运行。