骑手多类型订单收益怎么核对：事件去重与账单一致性设计

骑手一天完成多类型订单，又发生取消和补差，收益明细应按骑手、主体、币种和记账区间逐笔汇总，再分开核对钱包与提现。工程上最容易出错的是把订单完成日当记账日、把重复补差当新收入，以及读明细和总计时混入不同版本。本文给出事件模型与一致性读取方案，用来解释采购时如何验证这些问题。

先确定业务事实，而不是先写求和

同一订单可以有基础配送收益、经批准的补差及补差撤回，日奖励可能不属于单一订单。帮买商品款、代收款不自动成为骑手收益。取消只说明业务发生变化，是否补偿或冲回，仍要核对履约节点、责任和有效约定，不由数据库状态值替人作责任判断。

微订产品页以第一方口径介绍骑手App可查看订单配送及收益、支持提现，平台侧可管理订单状态与资金流水。它说明核对涉及两个角色端，不证明下列数据库结构已在具体版本使用；补差、审批与导出仍需演示确认。

收益事件与订单主表分开

下面是PostgreSQL风格设计，未在数据库实际执行。一个账本限定一个结算主体，金额单位为分；示例只处理人民币。source_key表示上游批准的同一真实业务动作，不能每次重试随机生成。唯一键处理消息重复，payload_hash用于判断重复键是否携带不同内容。

CREATE TABLE rider_income_event (
 event_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 source_key text NOT NULL UNIQUE,
 payload_hash text NOT NULL,
 rider_id text NOT NULL,
 order_id text,
 kind text NOT NULL CHECK(kind IN ('base','adjustment','reward','reversal')),
 amount_fen bigint NOT NULL CHECK(amount_fen<>0),
 currency text NOT NULL CHECK(currency='CNY'),
 fulfilled_at timestamptz,
 booked_at timestamptz NOT NULL DEFAULT clock_timestamp(),
 approval_id text NOT NULL,
 reason text NOT NULL,
 reverse_of bigint REFERENCES rider_income_event(event_id),
 CHECK((kind='reward' AND order_id IS NULL) OR
       (kind<>'reward' AND order_id IS NOT NULL)),
 CHECK((kind='reversal' AND reverse_of IS NOT NULL) OR
       (kind<>'reversal' AND reverse_of IS NULL)),
 CHECK(kind NOT IN ('base','reward') OR amount_fen>0)
);
CREATE UNIQUE INDEX one_income_reversal ON rider_income_event(reverse_of)
 WHERE reverse_of IS NOT NULL;

事件写入必须走鉴权服务，批准号从服务端已审核记录读取，不能接受客户端自行填“已批准”。数据库的CHECK不验证业务责任。撤回事务还要锁定原补差，校验同骑手、同订单、原事件类型为adjustment及反向金额恰好相抵；这几项跨行校验由受控写入逻辑完成，表约束本身没有代劳。

处理重复、冲突和更正

首次收到事件，规范化字段后计算内容摘要并尝试插入。source_key冲突时读取原行：摘要一致返回原event_id，摘要不同返回冲突并保留原记录。两个并发插入竞争相同键时由唯一约束决定唯一记录，冲突方重新读原行比较，不能一律把ON CONFLICT当成成功。应用角色不应有修改历史金额或直接删除事件的权限。

已入账补差撤回时新增反向事件，保留reverse_of；未批准申请仍停留在审批域，不提前写入收益账。一个订单出现多次不同的合法调整，分别保留各自来源键。不能直接按order_id唯一，否则第二次真实补差会被吞掉。

明细与合计在同一读取快照中产生

先校验查询骑手归属和时间参数，再在同一只读事务内生成明细与全量总计。下面以半开区间筛选记账时间；参数必须由服务端绑定，不做字符串拼接。REPEATABLE READ保持本事务中两次读取一致，不代表生成了可永久复现的历史账单。

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ READ ONLY;
SELECT event_id,source_key,order_id,kind,amount_fen,booked_at,fulfilled_at
FROM rider_income_event
WHERE rider_id=:rider AND booked_at>=:start_at AND booked_at<:end_at
  AND booked_at<=:cutoff
ORDER BY booked_at,event_id;
SELECT kind,COALESCE(SUM(amount_fen),0) AS total_fen
FROM rider_income_event
WHERE rider_id=:rider AND booked_at>=:start_at AND booked_at<:end_at
  AND booked_at<=:cutoff
GROUP BY kind;
COMMIT;

跨请求分页与导出不能各开新事务后假装共享旧快照。实际交付可保存关闭账单的明细事件ID、金额、版本及摘要，后续按该版本读取；数据库序列号也不天然代表提交顺序，不能只取某个最大event_id就断言所有更早事务均已入账。记账时间由受控服务生成，履约时间可关联昨日订单，禁止为调整统计而回填已关闭账期。

一组正常输入与异常反例

假设本期基础收益8000分、取消补偿300分、昨日订单本期补差200分、日奖励500分，总收益增量为9000分。重复发送该200分事件，仍为9000分；相同键改成400分，应返回冲突。另一笔不同批准来源的补差可独立入账，不能被订单号去重拦掉。以上金额是设计示例，不是实际费率或产品测试结果。

在下一期撤回200分，只在下一期出现负向调整，原期已关闭账单保持版本。午夜恰好发生的事件只属于新区间。若本期另申请提现2000分，收益增量仍为9000分，钱包内部冻结与渠道出款另核；申请、出款和到账各保留真实状态，不能用收益SQL替代资金核验。

怎样用设计验证交付

演示时固定同一骑手、主体与截点，依次做正常入账、重复补差、同键内容冲突、跨期调整、补差撤回和分页导出。记录实际输入输出，确认每笔差额可以定位到源事件。本文SQL只说明约束与读取方法，没有数据库实跑、云部署或产品验收结论；账号授权、支付联通与持久账单仍需独立验证。

作者：微订（上海逊柯计算机科技有限公司）。