题目重点：以工资计算快照和支付状态机隔离计算、审批、付款，解决高并发发薪日的幂等与对账。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版以 tenant+employee+pay_period+pay_run_version 作为工资运行唯一范围；金额用货币最小单位或 decimal，汇率与税规则按生效日期版本化。
- 税务内容只描述软件版本与审计结构，不提供国家具体税率或法律建议；实际规则由合规专家核定。
解题路线
- pay schedule 服务生成 pay period 与 cutoff；计算任务读取冻结的工资、工时、扣缴和规则版本，产出不可变 payslip snapshot，审批修改需新版本重算。
- 将状态拆为 draft→calculated→approved→payment_pending→paid/failed；审批身份与付款执行分离，入账/付款事件写不可变 ledger。
- 付款提交使用稳定 `payment_intent_id` 和支付提供方幂等键；事务内保证一份获批 payslip 只产生一个活跃 intent，outbox 可靠投递。重试同一 intent，不创建新付款；回执乱序用版本条件更新。
- 发薪日按 tenant/pay_run 分片批算、限流下游，提前预计算并保留审核窗口；日终对内部 ledger、提供方回执和银行结果做三方对账，异常进人工复核。
手动走一遍
同一员工双周工资计算 2,000 单位，审批后 payment_intent P；发送支付请求超时，不知道提供方是否成功。重试必须继续使用 P 的幂等键并查询结果，不能新建 P2 再发一次。税表版本调整只影响新计算批次，历史工资单仍引用旧版。
规模与取舍
E 员工、R 条计算规则的朴素批算 O(E×R)，付款与账本写 O(E)；峰值由每周期集中发薪员工数与下游限额决定。持久存储随工资单、规则版本及审计保留期限增长。
易错点与追问
容易失分的边界
- 金额用二进制 float 直接累加。
- 规则更新覆盖旧版，历史工资单不可解释。
- 支付 HTTP 超时后生成新付款 ID 重试。
- ‘Exactly once’只写在队列层，却没有支付端幂等与对账。
- 把税务字段和薪资数据暴露给无权限角色。
继续深挖
- 员工在 cutoff 后补报工时如何更正？
- 月薪与双周薪如何生成不同 pay period？
- 支付提供方不支持幂等键时如何控制重复风险？
- 跨国货币及税规则更新如何审核回滚？
