去年黑五结束后的第三天早上，我接到一个电话。深圳一家做家居类目的卖家，五个平台店铺，大促三天累计成交 12847 单，但 ERP 里只落库 12691 单。差的 156 单，平台后台显示"已付款待发货"，ERP 里查无此单。客服被买家催了整整一个上午，仓库那边因为库存没扣减，有一个 SKU 超卖了 40 多件。
更麻烦的是，ERP 的同步日志里一条红色报错都没有。技术同事第一反应是"接口没挂"，第二反应是"可能是平台那边的问题"，然后两边开始互相等对方给结论。等到下午两点，运营自己拿 Excel 手工比对平台订单号和 ERP 订单号，才把 156 单捞出来。
这件事之后我把它写成了一份复盘文档，后来陆续又遇到重复发货、库存超卖、状态不同步、Token 静默失效几类问题。这些经历让我对"订单同步的案例拆解"有了一个和大部分教程不太一样的判断：案例拆解的价值不在结论，而在还原排查链路。下面把我真实的思路完整写出来。
第一，订单同步不是"抓单"功能，而是多系统状态一致性工程。平台、ERP、仓库、物流、支付、财务六个系统各自维护一份订单状态，任何一次同步本质都是"让六份状态达成一致"的过程。你把它当接口问题修，永远修不彻底。
第二，绝大多数漏单不是"挂了"，而是"静默失败"。接口返回 200，业务没落库；Webhook 推送了但被限流丢弃；重试三次全失败后平台方不再重推，这些都不会在你的日志里显示为 ERROR。
第三，案例拆解最容易犯的错，是从"我们用了什么方案"写起。正确的顺序是：现象量化、范围界定、链路排查、根因定位、修复补偿、验证防复发。少了前三步，后面的方案就是猜的。
我翻过很多 ERP 厂商的案例页，结构高度雷同：客户背景一段、痛点三段、方案四段、效果数据两个百分比。这种写法的问题在于，它把"事故"删掉了。
真实的订单同步问题，价值恰恰在事故里。哪一步没报错？谁先发现的？手工对账花了多久？补单的时候有没有覆盖到已经付款但还没审核的订单？这些细节才是别人能复用的东西。
所以我在写复盘时坚持一条规则：宁可写清楚我们当时判断错了什么，也不写"效率提升 80%"这种无法验证的数字。没有出处的提升率，对读者是负价值。
我见过最快的定位是 15 分钟，最慢的是四天。差别不在技术能力，在有没有先把范围定死。
范围包含五个维度：时间范围、平台范围、店铺范围、SKU 范围、订单状态范围。这五个维度不界定清楚，你连"到底少了几单"都说不准，更别说找根因。上面那个案例，运营一开始说"少了很多单"，我们把三个平台数据拉出来一比对，发现缺口全部集中在某个店铺、某个时间段（当天 20:10 到 20:14），范围一下就缩到了四分钟。
把链路画清楚，是排查的前提。一个跨境订单从产生到财务入账，至少经过这些状态节点：下单、支付成功、风控审核、ERP 审单、库存占用、生成发货单、仓库出库、物流揽收、妥投、结算、退款或售后。
每个节点都可能触发一次跨系统同步。我在做链路梳理时习惯分成三层：
这里有个容易被忽略的点：回写失败和拉取失败的危害等级完全不同。拉取失败是"少了一单"，回写失败是"单子在你手里但平台不知道你发了货"，后者会直接引发平台延迟发货处罚。
同步方式只有三种：Webhook 推送、API 轮询、两者混合。它们不是谁更先进的问题，是失效模式不同的问题。
| 同步方式 | 典型延迟 | 主要失效模式 | 适用场景 |
|---|---|---|---|
| Webhook 推送 | 秒级 | 平台侧重试耗尽即丢弃；接收端 5xx 会触发退避；限流期直接静默 | 订单量大、对时效敏感 |
| API 轮询 | 取决于轮询间隔 | 时间窗口缝隙导致漏抓；分页处理不当丢尾页；频率超限被限流 | 平台不提供可靠推送 |
| 混合模式 | 秒级到分钟级 | 两套逻辑的去重规则不一致，产生重复单 | 大多数多平台卖家的现实选择 |
我个人的判断是：混合模式是必须的，但两套逻辑必须共享同一套幂等键和状态机。我见过一家公司，Webhook 走一套去重逻辑，轮询走另一套，结果大促期间产生了 200 多张重复订单，仓库多发了 60 多件货。
我做过一个粗略统计：在我经手的十几起订单同步事故里，有 9 起在事故发生时监控面板是全绿的。原因很简单，绝大多数监控盯的是"接口有没有返回非 200"，而不是"业务数据有没有变多"。
接口返回 200 但业务零落库的情况至少有四种：返回体是空数组、返回体里 code 字段是业务错误码、字段映射后必填项为空被静默跳过、事务回滚但异常被上层 catch 后仅打了一条 info 日志。
所以我现在坚持的第一条监控原则是：不监控接口，监控业务增量。任何一个店铺，如果连续 30 分钟订单增量是 0，且该店铺历史同期平均增量大于 0，就必须告警。
接口故障的典型特征是"全店铺全平台同时中断"，而漏单的典型特征是"局部、时段性、特定 SKU"。这两者的排查路径完全不同。
如果你的缺口是集中在某个 5 分钟窗口、某个店铺、某类订单状态，那大概率不是接口挂了，而是时间窗口缝隙、限流丢弃或状态过滤条件写错了。我建议先用时间维度切一刀，再决定要不要动代码。
这是最常见的盲区。ERP 日志只能告诉你"我收到了什么"，不能告诉你"对方发了什么"。多平台卖家尤其要注意，绝大多数平台的开放平台后台都提供 API 调用日志与事件推送记录，可以查到某条订单到底有没有被推送、推送了几次、返回了什么。
上面那个黑五案例，最后定案就是在平台侧日志里发现：那 4 分钟内的推送全部收到 503，平台重试三次后放弃，而我们的接收端在那 4 分钟恰好重启了一次。
补单是止血，不是治病。我见过团队每周都要手工补单，补了三个月，没人问为什么一直补。
我的做法是：补单脚本必须记录"补单原因分类"。是时间窗口缝隙？是幂等冲突？还是字段解析失败？同一个原因一个月出现两次以上，就必须排期修根因，不能继续靠人工脚本兜着。
重复单的危害比漏单更大，因为漏单是"少做事"，重复单是"多做错事"，多发一次货、多扣一次库存、多开一张发票，逆向成本高得多。
重复单的根因只有两类：一是幂等键设计错误，二是两套同步逻辑的去重规则不一致。前者用数据库唯一索引就能兜住，后者必须靠统一的幂等表。
— 幂等键设计示例：平台订单号 + 店铺 ID 构成唯一约束
CREATE TABLE erp_order (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
platform_code VARCHAR(32) NOT NULL,
shop_id VARCHAR(64) NOT NULL,
platform_order_no VARCHAR(64) NOT NULL,
order_status VARCHAR(32) NOT NULL,
created_at DATETIME NOT NULL,
UNIQUE KEY uk_order (platform_code, shop_id, platform_order_no)
);
— 插入时使用 INSERT … ON DUPLICATE KEY UPDATE
— 只更新状态与更新时间，不重复创建订单主体
INSERT INTO erp_order (platform_code, shop_id, platform_order_no, order_status, created_at)
VALUES ('PLATFORM_A', 'SHOP_001', 'PO-20241129-8823', 'PAID', NOW())
ON DUPLICATE KEY UPDATE order_status = VALUES(order_status);我读过的案例里，几乎所有方案都是"上线后问题解决"。但真实情况是，每上一个方案都有代价：加了全量对账，数据库压力上去了；加强了幂等校验，同步时延从 3 秒变成 11 秒；加了零单告警，值班人员每天被误报吵醒两次。
写案例时不写代价，读者照着做就会踩新坑。我现在的复盘模板里强制有一栏叫"引入的新问题"，不填这一栏，复盘不算完成。
不要接受"少了很多单"这种描述。必须落成三个数字：影响订单数、影响金额、影响 SKU 数。如果还能算出影响买家数，更好。
量化之后立刻做一件事：判断这批订单现在处于什么状态。是还没发货（可补救）？还是已经超卖（需要联系买家）？还是已经产生平台处罚（需要申诉）？状态决定了你的响应优先级。
按时间、平台、店铺、SKU、订单状态五个维度做交叉切片。如果缺口集中在某一个维度上，通常指向配置或过滤条件问题；如果缺口在所有维度上均匀分布，通常指向账号级或系统级问题，比如 Token 失效。
我用过一个很土但很好用的方法：把平台订单号导出成 CSV，把 ERP 订单号导出成 CSV，用 Excel 做 VLOOKUP 找出差异集，然后把差异集按小时分组画个柱状图。峰值所在的时间段，就是根因所在的时间段。
沿着接入层、处理层、落库回写层逐段查。每一段都问三个问题：这段的数据源是什么？这段的失败会不会报错？这段有没有兜底机制？
根因分析我坚持要到"可修复的具体缺陷"这一层。"网络不稳定"不是根因，"轮询时间窗口存在 4 分钟重叠缝隙，导致该区间内下单的订单在两个窗口都被跳过"才是根因。
# 有缝隙的轮询窗口（错误示例） 假设每 15 分钟跑一次，取上一窗口的结束时间作为起点 def poll_orders(): end = now().replace(second=0, microsecond=0) start = end - timedelta(minutes=15) 问题在于：平台按"最后更新时间"过滤， 若订单在 20:14:59 更新但接口按分钟粒度截断，就会漏掉 return api.query(updated_from=start, updated_to=end) 修正方式：窗口重叠 3-5 分钟，配合幂等表去重 def poll_orders_fixed(): end = now().replace(second=0, microsecond=0) start = end - timedelta(minutes=18) # 15 + 3 分钟重叠 return api.query(updated_from=start, updated_to=end)
修复分两条线走。一条是止血线：把缺失的订单补进来，把重复的订单去重，把被超卖的库存校准。另一条是治病线：改代码、改配置、改监控。
两条线必须并行，不能先治完病再说补单，因为买家在等货，平台在算时效。
验证不能只看"补单后数量对不对"，还要回放历史数据。我的做法是把事故发生时间段的数据重新跑一遍修复后的逻辑，看是否还能复现缺口。同时补三样东西：监控指标、告警阈值、值班响应 SLA。
订单同步至少需要监控六个指标。我把自己的经验基线列在下面，需要说明的是这些是基于我经手项目的观察值，不是行业标准，不同平台和业务量下应该重新标定。
| 指标 | 健康区间（经验值） | 告警阈值建议 |
|---|---|---|
| 同步时延 P95 | 小于 30 秒 | 连续 5 分钟大于 120 秒 |
| 同步成功率 | 大于 99.5% | 单小时低于 98% |
| 重复单率 | 小于 0.05% | 单日超过 5 单 |
| 漏单率 | 小于 0.1% | 日对账差异超过 3 单 |
| 队列积压量 | 小于 500 条 | 超过 2000 条或持续增长 15 分钟 |
| 异常恢复时长 | 小于 30 分钟 | 超过 60 分钟升级 |
这张表里我最看重的是"零单告警"，也就是某个店铺在营业时段连续 30 分钟订单增量为零。它几乎是唯一能抓住 Token 静默失效的手段。
下面四个案例都来自我参与过的真实项目，订单量、时间、店铺信息做了脱敏处理，数据做了等比缩放，但排查逻辑和根因是原样的。请把它们当作方法示例，而不是可以直接套用的数字。
五个平台店铺，大促三天平台侧成交 12847 单，ERP 落库 12691 单，缺口 156 单，缺口率 1.21%。ERP 同步日志无 ERROR 级别记录，接口可用性监控显示 100%。
按平台切分，缺口 100% 集中在 A 平台；按时间切分，138 单落在当天 20:10 到 20:14 之间；其余 18 单分散在另外两个时段。按订单状态切分，全部是"已付款待审核"状态。
这个切片结果已经排除了 Token 失效、全平台接口故障这两类可能，把范围压缩到了一个 4 分钟窗口。
A 平台没有可用的订单推送能力，只能靠轮询。我们查了平台侧的调用日志，发现在 20:10 到 20:14 这 4 分钟里，我们的接收服务重启了一次，重启期间的轮询任务被跳过。而轮询任务的窗口是按"上一窗口结束时间"推算的，重启后新任务的起点直接跳到了重启时刻，导致中间 4 分钟成了无人区。
换句话说，这不是接口故障，是时间窗口设计缺陷加上一次计划外的服务重启。
止血：写了一个按时间区间强制拉取的补单脚本，20 分钟补完全部 156 单，其中 40 多单已经接近平台发货时效，优先处理。
治病：轮询窗口改为向前重叠 5 分钟，配合幂等表去重；轮询任务改为持久化调度，服务重启后从数据库记录的最后成功时间点续跑，而不是从当前时间往前推。
仓库主管反馈，同一批订单里有 23 单出现了两次出库记录。查 ERP，确实存在两条订单主体，平台订单号完全相同。
查 API 调用日志发现，这 23 单在首次创建时都出现了接口超时（网关 504）。客户端的重试策略是"超时即重试，最多三次"。但服务端在第一次请求时其实已经成功落库，只是响应在返回途中超时。
服务端的去重逻辑用的是自增主键作为幂等键，重试请求生成了新的主键，自然绕过了去重。
修复方式是加数据库唯一索引（平台 + 店铺 + 平台订单号），并且把重试策略从"超时即重试"改成"先查询后重试"。
代价是同步时延上升。原来创建订单平均 3 秒完成，加了查询确认后变成 11 秒。这个代价可以接受，但必须提前跟运营说清楚，否则他们会以为系统变慢了。
某爆款 SKU 在 A 平台和 B 平台同时上架，共享同一批 300 件库存。某天晚上 A 平台卖爆，实际卖出 340 件，超卖 40 件。
库存回写延迟。A 平台下单后，ERP 扣减库存，然后向 B 平台回写最新库存。这个链路的 P95 延迟是 47 秒。在这 47 秒内，B 平台仍显示旧库存，被买家抢下 40 多单。
这是典型的"共享库存 + 回写延迟"导致的并发超卖，不是 bug，是架构层面的固有风险。
三个措施同时上：一是设置安全库存缓冲，实际库存 300 件，对外只暴露 285 件；二是增加库存预留池，下单时先在池中预留，支付成功后才真正扣减；三是设置主动下架阈值，某平台销量占比超过 60% 时自动下架其他平台的该 SKU。
某周一上午，运营在准备发货时发现 C 平台已经 4 小时没有新订单。上前台一看，平台后台有 87 单已付款订单，ERP 里一单没有。而监控面板显示接口成功率 100%。
Token 刷新任务失败，接口开始返回 401。但代码里的异常处理是 try...catch 后打了一条 info 日志，没有抛异常也没有上报监控。所以从监控角度看，接口"调用成功、返回正常"。
三件事：一是把所有平台接口的业务错误码做分类映射，401/403 归类为"需要人工介入"，直接触发电话告警；二是加零单告警；三是把 Token 剩余有效期做成每日巡检项。
这个案例最值得记的一点是：接口成功率这个指标在订单同步场景里几乎没有用，因为它衡量的是"通信是否发生"，而不是"业务是否达成"。
上面四个案例里，最耗时间的其实不是修复，是对账。每次事故都要手工导平台数据、导 ERP 数据、做 VLOOKUP、按小时分组。这个动作在 3 个店铺时还能忍，到 10 个以上店铺就完全不可持续。
我后来在几个项目里用数跨境来承担这部分工作。需要先说清楚定位：我把它当作"对账层和异常看板层"，而不是"抓单层"。抓单、幂等、状态机这些还是应该由 ERP 或自建服务来处理，这是它的职责边界。
按六步复盘法来看，数跨境发挥作用最大的是第二步"范围界定"和第六步"验证防复发"。
范围界定阶段，它能把多个平台的订单数据和 ERP 订单数据放到同一张表里做关联，直接输出差异清单，并按时间、店铺、SKU 分组。以前我用 Excel 做这一步要 40 分钟到 2 小时，用它对账看板之后基本压缩到几分钟内就能定位到时间窗口。
验证防复发阶段，我把它配成每日自动跑一次的三方对账：平台账单、ERP 订单、实际库存扣减。这三者只要有一方对不上，第二天早上就会有一条差异记录，而不是等买家来催。
我在实际使用中确认了几件事，也建议你在选型时重点确认：
我的使用经验是：把它放在"发现问题"的位置，把修复留给 ERP 和自研服务。这样分工之后，团队的角色也清晰了，运营自己就能看对账看板定位差异范围，技术只处理已经定位好的根因，不用再陪运营做三个小时的 Excel 比对。
这个阶段不建议上复杂的同步架构。优先做两件事：一是确认你用的 ERP 是否提供订单同步失败的邮件或短信通知；二是每周做一次平台订单数与 ERP 订单数的数量比对，差一单就查。
人工对账在这个量级是完全可以接受的，日单 200 的话，一次比对不超过 20 分钟。真正需要担心的是"从来不比对"。
这个阶段最容易出事，因为业务量已经超过了人工核对的能力，但团队还没有专职的技术运维。我的建议是分三步走：
这个量级必须把订单同步当作独立系统来建。核心是四件事：统一幂等键、统一状态机、多级兜底（推送 + 轮询 + 全量对账）、值班响应 SLA。
特别提醒一点：这个量级下，全量对账的成本会变得很可观。我的经验是全量对账不要每天跑全天数据，而是滚动窗口，每天跑最近 7 天，加上每月一次全量历史对账。这样既覆盖了延迟暴露的问题，又控制了数据库压力。
| 判断维度 | 倾向自研 | 倾向采购 |
|---|---|---|
| 平台数量 | 少于 3 个，且平台 API 稳定 | 5 个以上，需要频繁接入新平台 |
| 技术团队 | 有稳定的后端与运维 | 无专职技术，靠外部实施 |
| 异常处理要求 | 业务有特殊状态机，标准产品改不动 | 与行业通用流程差异不大 |
| 数据敏感度 | 订单数据不允许出内网 | 可以接受第三方托管 |
| 时间窗口 | 有 3 到 6 个月建设期 | 需要两周内上线 |
我个人的判断是：抓单、幂等、状态机这三块值得自研或深度定制，对账和报表分析不值得自研。因为前者的差异直接决定业务能不能跑通，后者是通用能力，自研投入产出比很低。
我给订单同步的一致性分过四个等级，每一级对应的投入差别很大。这不是一个"越高级越好"的问题，而是"你的业务毛利能不能撑住"的问题。
| 一致性等级 | 典型做法 | 漏单率量级 | 相对投入 | 适用业务 |
|---|---|---|---|---|
| L1 人工对账 | 每周比对数量 | 0.5% 到 1% | 1 倍 | 低客单价、低毛利 |
| L2 日对账 | 每日三方自动比对 | 0.1% 到 0.3% | 3 倍 | 常规多平台卖家 |
| L3 实时告警 | 零单告警 + 积压告警 + 幂等 | 0.03% 到 0.1% | 8 倍 | 爆款多、时效敏感 |
| L4 端到端对账 | 事件溯源 + 全链路可重放 | 小于 0.02% | 20 倍以上 | 高客单价、强合规 |
我的建议是不要跳级。从 L1 直接跳到 L4，团队既建不起来也用不起来。更现实的路径是先用 2 到 4 周把 L2 做到位，覆盖 80% 的漏单风险。
很多卖家上来就要求"秒级同步"。我一般会问一句：你的订单从付款到发货，中间平均隔多久？如果答案是 8 小时以上，那秒级同步对发货时效几乎没有帮助，但会把系统复杂度和故障面显著抬高。
我的判断标准是：同步时延应该小于"最紧急业务动作的最短间隔"。如果你有自动审单加自动发货，最短间隔可能只有几分钟，那实时同步有必要；如果发货至少等到第二天，那 5 分钟到 15 分钟的准实时完全够用。
库存回写是唯一例外。共享库存的场景下，回写延迟直接等于超卖风险，这一块值得单独优化到秒级。
全量对账是最有效的兜底，也是最贵的兜底。频率越高，数据库压力越大，告警噪音越多。
我的经验做法是分层：
这个分层覆盖了"同步延迟导致延迟暴露"的情况。有些问题在当天看不出差异，要等到退款或对账周期结束才会浮现，所以定期回溯是必要的。
有些平台的开放平台会提供推送失败通知，但可靠性和时效性差异很大。我的态度是：永远不要把平台的失败通知作为唯一告警手段。
原因很简单，平台通知你的是"我尝试推送但失败了"，它不会通知你"我应该推送但漏了"。后者只能靠你自己的对账和零单告警发现。
这四条取舍背后其实是同一个判断逻辑：先算清楚一次漏单的业务成本，再倒推你能承受多大的技术投入。如果你的订单平均客单价是 30 美元、毛利 20%，那一次漏单损失 6 美元，你可以容忍 0.5% 的漏单率；如果是 300 美元客单价的品类，同样比例就完全不能接受。
写到这里，我想回到最开始那个判断：订单同步的案例拆解，价值不在结论，在链路。一份好的复盘文档，应该让一个没参与过这次事故的人，拿着它就能独立处理同类问题。
为了做到这一点，我现在的复盘模板里固定包含五块内容，缺一块就不算完成：
另外，我强烈建议在建完监控之后做一次故障演练：人为把某个平台的 Token 改错，看系统多久能告警；人为把接收服务停 5 分钟，看补数逻辑能不能自动追平。我做过三次这样的演练，有两次都发现了真实故障时才会暴露的盲区。
回到操作层面，如果你今天就要开始动手，我的建议顺序是这样：
订单同步这件事，做得好的团队和做得差的团队，差距往往不在技术选型，而在有没有把每一次事故变成一条可复用的检查项。漏单会发生第二次、第三次，但如果你每次都把时间线、根因、代价和改进项写清楚，第二次的恢复时间就会从 6 小时变成 40 分钟。这才是我认为案例拆解真正的价值。
我们店大促后平台后台显示订单已付款，但 ERP 里就是找不到，客服天天催发货，财务也发现金额对不上，我完全不知道该从哪儿下手。我想知道有没有一套不靠猜的排查顺序，而不是挨个问技术、问运营。
先把漏单拆成"平台侧有没有产生"和"ERP 侧有没有接收"两段，不要一上来就翻代码。第一步在平台后台按订单号、下单时间、店铺导出原始订单清单，同时从 ERP 导出同时间段的入库订单清单，用订单号做外连接比对，得出精确的漏单集合和漏单率，比如 10000 单里缺 37 单就是 0.37%。
第二步确认这些漏单是否集中在某个店铺、某个时间段、某个 SKU 或某种支付方式，范围一旦收敛，根因通常就浮出来了。第三步按链路逐段验证：平台 Webhook 推送日志有没有这条记录、消息队列有没有堆积、字段映射有没有因为新加字段报错、数据库是否写入了但状态没更新。
判断依据是，如果平台推送日志里就没有，问题在平台侧授权或订阅配置；如果推送了但队列没消费，问题在消费端或限流；如果落库了但状态不对，问题在状态机或回写逻辑。最后一定要做补单和补偿，并对补单结果二次对账，确认修复后不再新增漏单，而不是补完就算结束。
我们 ERP 有时候几分钟就同步过来了，有时候要等一两个小时，运营说"能同步就行"，但我总觉得这不正常。我想知道行业里到底用什么指标衡量，多少算及格、多少必须告警，不然我没法跟技术提要求。
不要用"感觉快慢"来评估，要定义三个可量化指标：同步时延（订单在平台创建到 ERP 可见的时间差）、同步成功率（成功入库订单数除以应同步订单数）、积压量（队列中待处理消息数）。
日常时段建议把 P95 时延控制在 5 分钟以内、成功率 99.9% 以上，大促期间可以放宽到 P95 15 分钟、成功率 99.5%，但这只是起步参考线，真正该做的是先连续采集两周自己的基线数据，再根据业务容忍度定阈值。
判断依据来自业务后果：如果客服承诺 2 小时内发货，那时延超过 30 分钟就该预警，因为后面还有审单、拣货、打包的时间。告警不能只看平均值，平均值会把长尾掩盖掉，必须看 P95 和 P99。
另外要把"延迟"和"漏单"分开监控，延迟是慢，漏单是丢，前者靠扩容和限流优化，后者靠轮询补偿兜底，两者的处理动作完全不同，混在一起看会误判。
我们有次同一个订单在 ERP 里出现了三条，仓库按其中两条发了货，客户收到两份，退款加运费全是我们承担。我一直以为是接口不稳定导致的，但技术说接口没问题，我想搞清楚这中间到底是什么机制出了漏洞。
重复订单绝大多数不是"接口坏了"，而是"重试 + 无幂等"的组合事故。典型链路是：平台推送订单，ERP 处理超时没返回成功，平台按规则重推，ERP 第二次才处理成功，于是同一条订单被写入两次。要避免必须在三个位置设防。
第一，入库时用平台订单号加店铺 ID 组成唯一键，数据库层面建唯一索引，重复写入直接报错而不是新增记录，这是最后一道硬防线。第二，消费消息时记录已处理的消息 ID，用 Redis 或数据库做去重表，处理前先查、处理中加锁，防止并发重复消费。
第三，发货回写同样要幂等，回写前先查平台当前状态，已经是已发货就不再重复调用。判断依据很简单：任何一次重试都可能造成重复，所以要假设重试一定会发生，而不是祈祷它不发生。另外建议每周跑一次重复订单巡检，按订单号分组统计出现次数大于 1 的记录，主动发现而不是等仓库或客户反馈。
我们每次出问题都写复盘，写得挺认真，但过两个月同类问题又冒出来，感觉复盘就是走个形式。我想知道怎么把一次事故拆解转化成能落地的东西，而不是存进文件夹就没人看了。
关键是把复盘从"描述发生了什么"升级为"产出可执行的改进项"，并且每个改进项都要有负责人、截止时间和验证方式。
具体做法是：复盘文档固定包含五个字段，时间线（精确到分钟）、影响面（涉及订单数、金额、店铺）、根因（区分直接原因和系统性原因）、改进项（分立即修复、机制建设、监控补强三类）、验证标准（怎么证明改好了）。
其中只有"立即修复"能当天关掉，"机制建设"和"监控补强"必须进入迭代排期，否则一定会被业务需求挤掉。判断改进是否真的落地，看三个信号：同类告警是否还会触发、值班人员是否知道该做什么、补偿操作是否有 SOP 而不是靠某个人记忆。
建议每月做一次改进项回头看，把逾期未完成的改进项升级到管理层可见的清单里。另外把高频故障场景写成值班手册，新人在没人带的情况下也能按步骤处置，这样组织能力才不依赖某几个老员工。案例拆解的价值不在于文档写得多完整，而在于下次同类故障的恢复时间是否明显缩短。
读者评论
文章把漏单拆成四段损耗的瀑布图很直观，比笼统说'少了156单'清楚多了。不过平台侧推送日志只有部分平台开放，实际操作中有的平台根本查不到，这块能不能再说说替代方案？
不监控接口，监控业务增量'这条我特别认同。我们之前也是接口全绿，结果某个店铺两个小时没进单，最后是客服发现用户催发货才知道的，监控只盯状态码确实不够。
幂等键用平台订单号加店铺ID做唯一约束，这个方案简单有效。但两套同步逻辑共享同一套幂等表，改造起来对已有系统成本不低，小团队落地可能会比较吃力。
帕累托图那个根因分布挺有参考价值，Webhook丢失加幂等冲突占了一半以上，说明资源确实该往推送可靠性和幂等设计上倾斜，比平均用力修修补补强。
文章强调案例拆解要还原排查链路而不是只写方案，这点比市面上大部分ERP厂商案例页实在。不过补单原因分类这个做法，需要团队有执行力坚持记录，不然还是容易流于形式。