2023 年 11 月 11 日凌晨 1 点 47 分，仓库主管在群里发了一张截图：某个 Amazon 店铺的 312 个订单，全部卡在 ERP 的"待同步"状态，而平台后台显示这些订单在两小时前就已经付款完成。那一刻我们并不知道，问题不在接口，而在我们三个月前配置的一条时间窗口参数，增量拉取只覆盖"付款后 30 分钟内未处理"的订单，超过 30 分钟的单子，被静默丢掉了。这不是一次技术故障，这是一次设计缺陷，而它在那天晚上之前，从来没有被发现过，因为日常单量下，几乎不会有订单在 30 分钟内没被拉到。
这件事之后，我把订单同步整条链路重新拆了一遍，把所有"看起来能跑"的部分逐个改成"能被证明能跑"的部分。这篇文章就是那次重做的完整记录：订单同步到底在同步什么、它会在什么地方坏、坏了按什么顺序查、以及怎么向你的老板或者技术方证明它已经跑稳了。涉及具体平台能力的地方我会标注"以官方文档为准"，所有具体数值如果来自我们自己的项目，我会明确说明它是经验值而不是行业统计。
大部分关于跨境电商 ERP 的操作手册，写到"在 ERP 里绑定店铺、开启订单同步、设置同步频率"就结束了。但如果你的目标是"落地"，这三个动作只是起点，连一个合格的中间状态都算不上。我判断一个订单同步方案是否真正落地，只看三个可验证的标准。
"能拉到"只证明网络通、Token 有效。真正的同步成功，指的是平台订单的每一个状态变化，都在 ERP 里有对应的、时间戳可追溯的记录。这包括下单、付款、部分付款、取消、退款、部分退款、地址修改、拆单、合单、发货、妥投、退货入库。
我用一个简单的判断句来区分这两件事：如果订单在平台侧发生了状态变化，而你的 ERP 里没有任何痕迹，那这条链路就还没打通。拉到订单只是"读"，状态对齐才是"同步"。
我在做 ERP 实施复盘时习惯看一个指标：每天因为异常需要人工介入的订单数量占当日总单量的比例。这个比例在刚上线的系统里通常在 1%，3%，跑顺之后应该压到 0.3% 以下（这是我们几个项目的经验值，不是行业统计）。
关键不是数字本身，而是这个数字有没有被记录。如果一个团队连"今天有多少单需要人工兜底"都答不上来，那说明异常要么被静默吞掉了，要么根本没人知道它存在。
这句话我说得比较绝对，但它救过我两次。对账的逻辑很简单：把 ERP 里的订单量、金额、状态分布，与平台后台的数据做周期性比对。日粒度对单量，周粒度对金额和状态，月粒度对退款和退货。
没有对账，你就只能依赖"感觉系统正常"。而有对账，你能在客户投诉之前发现问题。我们后来把对账做成了每天早上 8 点自动跑的定时任务，输出一张差异表，差异不为零就推送给运营主管。
讲方法之前，我想先讲三个具体的故障现场。它们分别对应三种不同的失败类型：设计缺陷、并发问题、数据口径问题。这三种类型，几乎覆盖了我见过的 90% 以上的订单同步事故。
就是开头提到的那个场景。时间窗口设置成"付款后 30 分钟内"，设计时的假设是"同步频率 5 分钟一次，30 分钟窗口足够覆盖三次重试"。这个假设在日均 200 单的时候完全成立，但在大促零点后的半小时里，平台接口响应时间从 300ms 涨到 4s，同步任务被限流，单次拉取耗时超过了窗口跨度，于是出现了一个"永远追不上"的空洞。
这个故障的排查过程很有代表性。我们第一时间查的是接口错误日志，结果是空的，因为没有报错，任务确实"成功执行"了，只是每次都漏掉了前面的一部分。真正的定位靠的是一次手工对账：把平台后台导出的大促订单明细，和 ERP 的订单表做一次全量比对，差了 312 条，全部集中在 00:15，00:55 这 40 分钟内。
这类故障的共同特征是：不报错、不告警、不可见。如果没有对账，它可能几个月都不会被发现。
第二个故障来自重试策略。我们的同步任务在遇到接口超时时会重试三次，重试逻辑写得很正常，但它缺少一个关键的东西：幂等校验。当第一次写入因为数据库连接超时而实际上已经成功、但客户端收到了超时响应时，重试就会产生第二条记录。
更麻烦的是并发。我们当时有两个同步实例（为了避免单点），两个实例在同一时间窗口内拉到了同一批订单，各自判断"这条订单不存在"，然后各自写入。这就是典型的并发写重。
17 单重复发货的损失，加上两个平台的绩效扣分，我们算了 2.1 万元。修复方案只花了半天：给订单表加唯一索引，写入前先做存在性检查并在同一事务内完成，同时把两个实例改成按店铺分片，避免同一店铺被两个实例同时处理。
第三个故障最隐蔽。我们的同步任务拉取的是"状态为已付款及之后的订单"，退款订单虽然在状态枚举里，但我们的过滤条件写的是"付款时间在近 7 天内"，而退款发生的时间往往在付款后 15，30 天。结果就是：这些订单我们从来没拉取过第二次，也就永远不知道它们后来退款了。
这个问题的表现是月度利润表对不上，ERP 里的销售额比平台后台高 2.3 万。财务怀疑是汇率或者佣金计算的问题，查了两周才发现是收入确认口径的问题。它本质上不是同步故障，而是同步范围的定义错误。
把三次故障放在一起看，会发现一个共同规律：它们都不是"接口不通"，而是"定义不清"。时间窗口怎么定义、幂等边界怎么定义、同步范围怎么定义，这三个定义如果没写清楚，接口再稳定也没用。
上面三个故障，往深里挖，都对应着一些很常见的认知误区。我把它们整理成五条，每一条我都亲眼见过至少两次。
这是最根本的误区。订单同步实际上包含四个方向的数据流：订单下行（平台到 ERP）、状态上行（ERP 到平台）、库存回写、物流信息回传。只做第一个方向，会在库存环节爆雷，因为 ERP 里的库存不会因为平台卖出一单而自动扣减，超卖几乎是必然的。
我见过一个团队，订单同步做了三个月很稳定，结果第一次大促就超卖了 400 多单。原因是他们的库存是人工每天手动同步一次的。
接口调通只是个开始。真正的稳定性考验来自：Token 过期、频率限制触发、平台接口版本升级、平台侧字段语义变更、网络抖动、数据库锁等待。
我的经验是，订单同步系统上线后的前三个月，是问题最集中的时期，因为所有的边界情况都会在这个阶段逐渐暴露出来。三个月之后如果还有问题，通常就是设计层面的了。
测试用例里如果没有"订单取消""部分退款""买家修改地址""订单被平台风控冻结"这几条，那这个测试基本等于没做。异常流程的测试成本是正常流程的三到五倍，但它是唯一能在上线前发现问题的方法。
我们后来形成的一个做法是：每次平台接口有变更公告，先不急着改代码，而是先把变更点对应的异常场景整理成一份测试清单，逐条验证当前系统的行为。
时间窗口和状态过滤单看都没问题，组合起来就出事。比如"近 7 天付款的订单" + "状态为待发货"这个组合，会漏掉所有"近 7 天付款但已经发货"的订单，而后者恰恰是需要回写物流单号的对象。
判断这个组合是否有问题的方法很简单：把你所有的过滤条件列出来，然后问一句，一个订单从创建到最终关闭，会经历哪些状态？我的过滤条件能覆盖这个全生命周期吗？
平台文档告诉你的是"这个字段叫什么、什么类型"，它不告诉你"这个字段对应你 ERP 里的哪个业务概念"。这两件事之间存在一个必须由业务方来填的空白。
举个例子，平台有 order_status、fulfillment_status、payment_status 三个维度，而你的 ERP 可能只有一个"订单状态"字段。这时候三个维度到一维的映射，就是一个业务决策，不是技术实现。谁来决定这个映射，决定了这套系统以后会不会天天扯皮。
踩过足够多的坑之后，我把订单同步拆成了一个四层模型。这个模型的好处是：每一层都有明确的交付物和验收标准，出现问题时也能快速定位到是哪一层坏了。
这一层的交付物是一张显式的状态映射表，以及一个明确的兜底状态。核心原则是：平台状态到 ERP 状态的映射必须是多对一的、可穷举的，任何无法映射的状态都必须落到一个确定的兜底状态上，而不是丢失或者报错。
我在实际项目中用的映射表结构大概是这样：
{
"mapping_version": "2024-11-01",
"platform": "generic",
"rules": [
{
"platform_status": ["PENDING_PAYMENT", "UNPAID"],
"erp_status": "WAIT_PAY",
"note": "未付款，不进入履约流程"
},
{
"platform_status": ["PAID", "READY_TO_SHIP"],
"erp_status": "WAIT_SHIP",
"note": "已付款待发货，进入仓库队列"
},
{
"platform_status": ["SHIPPED", "IN_TRANSIT"],
"erp_status": "SHIPPED",
"note": "已发货，需回写物流单号"
},
{
"platform_status": ["CANCELLED", "CLOSED_BY_PLATFORM"],
"erp_status": "CANCELLED",
"note": "取消订单，需释放库存占用"
},
{
"platform_status": ["PARTIAL_REFUND", "REFUNDING"],
"erp_status": "REFUND_PROCESSING",
"note": "部分退款，金额需单独记录，不改变发货状态"
}
],
"fallback_status": "MANUAL_REVIEW",
"fallback_alert": true
}
注意最后两行：兜底状态和兜底告警。任何没有命中规则的订单状态，都会进入人工复核队列，并且触发一次告警。这条设计在两年里帮我们抓到了三次平台静默上线新状态的情况。
这一层的交付物是一个明确的唯一键定义，以及一套可验证的幂等写入逻辑。唯一键通常由三段组成：平台标识 + 店铺标识 + 平台订单号。
为什么是这三段？因为同一个订单号可能在不同平台重复（尤其是一些平台自增 ID 的规则相似），同一平台在不同店铺也可能重复。少了任何一段，都可能出现跨平台或跨店铺的误判。
幂等的实现要点是在同一个事务内完成"检查存在性 + 写入"，而不是先查再写。伪代码大概是这样：
— 唯一索引（这是底线，即使应用层有校验也要加）
CREATE UNIQUE INDEX uk_order_identity
ON erp_order (platform_code, shop_id, platform_order_no);
— 写入时依赖数据库的唯一约束，捕获冲突而不是先查后写
INSERT INTO erp_order
(platform_code, shop_id, platform_order_no, erp_status, created_at)
VALUES
(?, ?, ?, ?, ?)
ON DUPLICATE KEY UPDATE
erp_status = VALUES(erp_status),
updated_at = NOW();这里有一个容易忽略的点：唯一索引是最后一道防线，不能因为应用层有校验就省掉它。并发场景下，应用层的"先查后写"几乎必然出问题。
这一层要回答的问题是：用主动轮询、事件推送，还是两者并存。我的判断逻辑是分三个维度看的：实时性要求、异常可容忍度、以及团队的技术储备。
主动轮询实现简单，但受频率限制，延迟取决于轮询间隔。事件推送实时性好，但要处理签名验证、事件乱序、事件丢失、重放攻击。现实中最稳的组合是：用推送做实时性保障，用低频轮询做兜底对账。即使推送全丢，轮询也能在下一个周期把订单补回来。
关于各平台具体支持哪种模式、频率上限是多少，必须以各平台官方开发者文档的最新版本为准，这类参数变更比较频繁，我这里不给具体数字。
这一层是前面三层的"证明系统"。它的交付物是三样东西：一张对账差异表、一组关键指标看板、一套告警规则。
对账差异表要能回答"差了多少、差在哪里、差的是什么类型"。关键指标至少包括：同步延迟的中位数和 P95、失败队列长度、重试成功率、人工介入单量、Token 剩余有效期。告警规则要区分"必须立刻处理"和"记录即可"两档，否则告警会很快被忽略。
我的经验是：告警条目超过 15 条的监控系统，基本等于没有监控。因为没有人会认真看每一条。把告警收敛到 8，10 条，每一条都对应一个明确的处置动作，这才是有效的。
下面这个案例来自 2024 年上半年我们参与的一个项目。我把可以公开的部分整理出来，包括背景、步骤、以及上线前后的数据观察。所有具体数字都是我们项目的实测值，不是行业统计。
卖家规模：亚马逊 3 个站点、Shopee 2 个站点、TikTok Shop 1 个，合计 11 个店铺。日均订单量 1800 单左右，大促峰值约 9500 单。原有系统是一套自研的订单拉取脚本 + Excel 台账，运营每天手工核对一次。
核心痛点有三个：大促期间漏单严重、退款订单状态不同步导致财务对不上、库存靠人工同步经常超卖。项目目标不是"上一套 ERP"，而是"把订单同步这条链路做成可验证的"。
第一步是店铺授权与 Token 管理。这里的关键不是"能不能授权成功"，而是"Token 过期后怎么办"。我们给每个店铺配置了独立的 Token 刷新任务，并把"剩余有效期少于 3 天"作为一个独立的告警项。这个细节在项目上线后的第 47 天救了一次，某个店铺的 Token 刷新因为平台侧权限变更失败，告警提前 3 天发出。
第二步是状态映射表。我们花了整整两天时间和运营主管一起，把三个平台的状态枚举值逐条对到 ERP 的六个内部状态上。这个过程最大的收获不是映射表本身，而是我们发现运营团队对"什么算已发货"的理解存在分歧，有人认为"平台标记为已发货"就算，有人认为"物流有第一条轨迹"才算。这个分歧在以前是靠人脑自动消解的，系统化之后必须明确写下来。
第三步是全量初始化。我们把每个店铺近 90 天的历史订单全量拉取一遍，然后与平台后台导出的订单做总量核对。11 个店铺里，有 4 个店铺第一次核对就不一致，差异原因是时区处理，平台返回的是 UTC 时间，我们按北京时间做了日期切分，导致跨日订单被分到了错误的日期。
第四步是增量同步。我们采用了推送加轮询的混合模式：支持推送的平台订阅事件，不支持推送的平台做轮询，同时所有平台都保留一个 15 分钟的兜底轮询（这个 15 分钟是我们根据业务量和接口限额定的经验值，不适用于所有场景）。
增量同步上线后第一周，我们做了一件很重要的事：每天手工对比推送接收到的订单数和轮询拉到的订单数，看两者的差集。结果发现推送有大约 0.4% 的事件丢失，主要集中在平台侧的系统维护窗口期。这个比例如果不上对账，永远不会被发现。
第五步是下游打通。订单进来之后要流转到仓库、库存、物流面单三个环节。这里最容易出问题的是库存扣减时机，是订单付款即扣，还是发货时扣？我们的选择是付款即扣，同时在退款和取消时释放。这个选择会带来"未发货但已占用库存"的情况，需要用"可用库存 = 总库存 – 占用 – 安全库存"这个公式来管理。
第六步是状态回写。ERP 发货后要把发货状态和物流单号回写到平台。这一步的失败率往往被低估，因为回写失败不会影响 ERP 内部流程，只会导致平台侧订单一直显示"待发货"。我们给回写单独做了一个失败队列，失败三次进入人工队列，并在看板上显示队列长度。
第七步是监控与告警。最终收敛到 9 条告警规则，包括：单店同步延迟超阈值、失败队列长度超阈值、Token 有效期不足、映射表未命中、对账差异不为零、回写失败队列积压等。
项目上线后我们持续跟踪了 90 天。几个比较有代表性的变化：日异常人工介入率从 6.2% 降到 0.31%，对账差异单量从日均 40 单降到 3 单以内，同步延迟 P95 从不可测（人工台账）降到 4.5 分钟，大促期间 P95 是 18 分钟。
还有一组值得说的数据：上线后第 30 天到第 60 天，人工介入率出现了反弹，从 0.31% 涨到 0.9%。排查发现是新接入的两个站点地址字段包含特殊字符，导致解析失败。这说明"稳定"不是一个静态状态，每次业务扩张都会重新引入新的异常类型。
项目跑到第三个月的时候，出现了一个新需求：运营想要看"按平台、按站点、按 SKU 维度的订单履约时效分布"，还想要"退款订单的归因分析"，到底是质量问题、物流问题还是描述不符。这些需求已经超出了 ERP 自带报表的能力范围，ERP 的报表擅长的是订单本身，不擅长跨平台的多维分析。
这时候我们的做法是在订单同步链路的下游，再挂一层数据分析层。订单同步负责把数据"对齐"，数据分析层负责把数据"用起来"，这两件事的目标函数是不一样的。前者要的是准确和幂等，后者要的是灵活和维度丰富。
我们在这个环节用过的一个工具是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），它的定位是跨境电商的数据分析平台，可以对接多个平台店铺的数据源，把订单、广告、库存这些原本分散在不同后台的数据归集到一起，做多维度的分析看板。
它在我们的订单同步体系里承担的是"下游验证"的角色：ERP 的订单表同步到分析层之后，我们用它做几个固定看板，按店铺的订单量趋势、退款率趋势、履约时效分布。这几个看板后来变成了我们每天早上第一眼看的对账依据，因为一旦某个店铺的订单量趋势出现异常拐点，通常就意味着同步链路又出问题了。
需要说明的是，它不是订单同步工具，也不解决订单拉取、幂等、状态回写这些核心问题。它的价值在于把同步结果变成可观察、可对比的业务视图，这对于"证明系统跑稳了"这件事很有帮助，但前提是你的同步链路本身已经对齐干净了。数据源没对齐，分析层只会把错误放大。
上面讲的是完整的一套方法。但现实中每个人的起点不一样，我按四种常见情况给出不同的行动序列。
这个阶段最重要的事不是选工具，而是先把你的状态映射表和唯一键定义写出来。这两份文档跟你选哪家 ERP 无关，它是你自己的业务资产。拿着这两份文档去和供应商谈，你会立刻发现哪些供应商在认真做对接、哪些只是在卖功能列表。
具体动作：第一周，梳理你所有在售平台的状态枚举值，列成一张表；第二周，和运营、仓储、财务各开一次会，把分歧点记录下来；第三周，再去看供应商的方案能不能覆盖这些分歧点。
这种情况不要急着改代码，先做三件事。第一，做一次全量对账，把 ERP 订单表和平台后台导出做逐条比对，算出真实差异率。第二，把失败日志按错误码分类统计，看看问题集中在哪几类。第三，检查唯一索引是否存在。
我见过太多团队直接跳到"改架构"，结果改完还是同样的差异率，因为真正的问题在一条过滤条件上。
这个规模下，单实例同步会开始出现瓶颈，需要做分片。分片的维度我建议按店铺分，而不是按时间分。原因是按时间分片会导致同一店铺的订单被不同实例处理，并发写重的风险大幅上升。
同时这个规模下必须要有独立的失败队列和人工兜底入口。让运营能自己处理失败订单，而不是每次都找技术，这是效率的关键分水岭。
大促前两周要做的不是加机器，而是四件事：容量估算、频率临时调整、降级预案、值班安排。
容量估算的方法是：用上一次大促的峰值单量乘以本次预估的增幅，算出峰值 QPS，然后测算当前的接口调用配额能不能覆盖。如果不能覆盖，就要提前和平台申请配额提升，这个流程通常需要提前一到两周走。
降级预案要想清楚：当同步延迟超过某个阈值时，哪些环节可以先降级？我的建议是优先保订单拉取，可以暂时降级的是实时告警推送和非核心的分析数据同步。
订单同步的很多决策没有"正确答案"，只有"适合当前阶段的答案"。我列四个最常见、也最容易争论不休的取舍点。
实时性越高，链路越复杂，能出问题的环节越多。如果你的业务是预售或者长周期发货，实时性要求其实很低，用 15 分钟轮询完全够用，没必要上事件推送。
我的判断标准是：如果订单延迟 15 分钟会造成实际的业务损失（比如超卖、错过物流截单时间），才值得为实时性付出复杂度代价。否则，稳定性优先。
自研的优势是可控，劣势是维护成本会随着平台数量线性增长。每接入一个新平台，就意味着一套新的授权、字段、异常处理逻辑。
粗略估算：自研一套覆盖 5 个平台的订单同步，初期开发大约 30，50 人天，之后每年维护投入约 20，30 人天（这是我们的项目经验值）。如果你只做 1，2 个平台，自研是合理的；如果超过 5 个平台，采购或者混合方案的边际成本会明显更低。
全量对账最准确，但成本高。抽样对账成本低，但会漏掉低频异常。我的建议是分层：单量对账做全量（因为只是数字比对，成本很低），明细对账做抽样。
具体做法是每天自动比对订单总数和总金额，差异为零就跳过；差异不为零才触发全量明细比对。这样既保证了发现能力，又控制了日常成本。
自动重试的次数不是越多越好。重试次数过多会放大平台侧的限流问题，也会让错误订单在队列里停留更久。我的经验是：自动重试 3 次，间隔递增（1 分钟、5 分钟、30 分钟），之后进入人工队列。
同时，人工队列必须有人负责。如果没有人定期清理，这个队列会变成一个新的黑盒，问题只是从"看不见"变成了"看得见但没人管"，本质上没有改善。
这一节是我从项目里沉淀下来的一份自检清单，你可以直接拿去对照自己的系统。12 项里如果有 4 项以上不满足，说明这套同步系统还处在"能用但不稳"的阶段。
| 序号 | 检查项 | 合格标准 | 不满足的后果 |
|---|---|---|---|
| 1 | 状态映射表是否显式存在 | 有文档化映射，含兜底状态 | 新状态静默丢失 |
| 2 | 唯一索引是否建立 | 平台+店铺+订单号三段唯一 | 重复发货 |
| 3 | 是否覆盖取消与退款状态 | 退款、部分退款、取消均被拉取 | 财务口径对不上 |
| 4 | 是否有分页中断保护 | 分页失败可续拉，不丢中间页 | 大促批量漏单 |
| 5 | Token 有效期是否监控 | 剩余不足 3 天触发告警 | 同步静默停止 |
| 6 | 是否有失败队列与人工入口 | 运营可自助处理失败单 | 异常积压无人处理 |
| 7 | 是否有日粒度对账任务 | 每日自动比对单量与金额 | 问题长期不可见 |
| 8 | 是否监控同步延迟 P95 | 有分店铺的延迟看板 | 平均值掩盖大促堆积 |
| 9 | 是否覆盖时区与币种处理 | 时间统一为 UTC 存储，展示层转换 | 跨日订单错分 |
| 10 | 是否回写物流单号与发货状态 | 回写失败有独立队列 | 平台侧长期显示待发货 |
| 11 | 是否有库存占用与释放逻辑 | 付款占用、取消退款释放 | 超卖或缺货 |
| 12 | 是否有大促降级预案 | 明确降级顺序与责任人 | 大促期间全面失控 |
（1）订单同步频率设多少合适？没有通用答案，取决于单量和业务对延迟的敏感度。单量小的时候，15 分钟轮询通常够用；单量大且有时效要求时，用推送加兜底轮询。关键是不要为了"看起来更实时"而设过高的频率，那只会增加被限流的概率。
（2）为什么我的 ERP 显示订单已同步，但平台上还是待发货？这是典型的状态回写问题，不是订单拉取问题。检查回写任务是否在运行、回写的物流单号格式是否符合平台要求、以及回写失败后是否有重试。另外要确认平台是否要求先标记发货再上传单号，顺序错了也会失败。
（3）漏单问题应该从哪里开始查？我的排查顺序是：先做一次全量对账确认漏单范围和集中时间段，然后查该时段的同步任务执行日志和接口返回条数，再查时间窗口与状态过滤条件，最后查分页与限流。不要一上来就查代码，先确定漏的是哪一段。
（4）对账差异在多少以内算正常？理论上应该是零。实际运行中，由于平台侧数据更新时间差，会有少量短暂差异，但如果日粒度对账在次日仍不为零，那就是真实差异，需要排查。把"差异不为零就告警"作为规则，比设定一个容忍阈值更安全。
回到开头那个凌晨的电话。那次事故之后我最大的认知变化是：订单同步不是一个技术功能，而是一套业务定义的载体。时间窗口怎么定义、状态怎么映射、异常算不算异常、谁来兜底，这些问题在系统化之前，都是靠人的经验自动消解的；系统化之后，它们必须被显式地写下来，而写下来的过程，恰恰是逼着团队把模糊的共识变成明确规则的过程。
这也是为什么我在文章里反复强调"对账"和"验收标准"。一个没有被证明跑稳的同步系统，和一个跑稳了的同步系统，在功能列表上看起来完全一样，但前者会在你扩张的时候集中爆雷。你接入第三个平台的成本，取决于前两个平台有没有把地基打干净。
如果你读到这里，想立刻做点什么，我建议按这个顺序来：
最后说一句可能不太中听的话：订单同步这件事做得好的标志，是它变得无聊。没有人再在群里问"这单为什么没同步"，没有人在大促后连夜补数据，没有人在月度对账时争论口径。当它变得无聊的时候，你才算真正落地了。
我们刚上ERP，店铺里已经跑了半年多订单，我担心一次全量拉下来，要么把老的已发货单又重新推一遍仓库，要么漏掉中间某几天的单。运营天天催进度，我也不敢一次性把同步开关打开。
把全量初始化拆成两段：只读落地和转入业务流。第一段先按平台可回溯的时间范围拉历史单，多数平台只保留有限天数，具体以各平台官方开发者文档为准，别默认能拉一年；拉下来的数据全部写入中间表，带上唯一键（平台+店铺ID+平台订单号），用唯一索引或upsert在写入层拦重复，不要在应用层先查后写。
第二段给初始化数据打上回填标记，并限制状态范围：只让待发货、部分发货这类还需要你处理的单进入仓库、库存、面单流程，已发货、已取消、已退款的只作留档，不触发任何下游动作。
核对口径是按天比对：把ERP里按创建时间分天的单量与平台后台同维度导出的单量逐天对比，差异不能只看总数，必须能逐条列出订单号并解释原因，比如平台侧含测试单或未付款单。经验上差异率控制在千分之一以内、且每一笔差异都有归属，才算初始化通过；对不上的天数不要靠差得不多放过，那批单后期会变成对账黑洞。
我们做多店铺运营，最怕早上来发现昨晚少了几十单，或者仓库收到两张一模一样的发货单。每次都是临时去平台后台手动补，但一直没人说得清根因在哪，我不想每次都靠运气。
先分清是漏还是重，路径完全不同。漏单按四步走：一看时间窗口，增量同步要用平台侧的更新时间而不是创建时间做游标，并且每次拉取往回重叠5到10分钟，防止边界订单被跳过；二看状态过滤，只拉待付款的单会漏掉先付款后退款以及拆单后生成的子单，过滤条件应该按已付款及以后的全集，而不是某个白名单状态；
三看分页，分页中断或游标丢失会造成中段整段缺失，日志里必须记下每页条数和当前游标；四看授权，Token过期通常表现为任务成功但返回0条，这是最容易被误判成今天没单的假象。
重复单几乎只有一个根因，就是幂等缺失，唯一键用平台+店铺ID+平台订单号，并且要在数据库写入层做唯一约束，多实例部署时还要确认重试不会有两个worker同时跑同一批。处置上建议每类异常配固定动作：可自动重试的进重试队列，用指数退避、上限3到5次，超限的进人工兜底队列并告警，绝不静默丢弃。
技术同学建议上Webhook说实时性更好，但我担心丢消息；运营又嫌轮询慢，大促时订单要等十几分钟才进系统。我想知道真实业务里这两个方案各自的代价是什么，能不能混着用还是一定要二选一。
不要二选一，成熟做法是推送做实时、轮询做兜底。主动轮询的代价是延迟和限额：延迟取决于轮询间隔，间隔越短越容易撞上平台的调用频率限制，具体上限各平台官方文档不一致且会调整，必须按最新文档配置，不要照抄别人的参数；好处是实现简单、可重放、出问题能重拉。
推送的代价是它只保证发过，不保证你处理成功：签名校验失败、乱序到达、处理超时都会让事件石沉大海，所以必须有幂等写入、事件落库留痕、失败重试和一个定时补偿任务。判断依据是三条：一是单量与时效要求，日单量几百、发货窗口宽松，纯轮询就够；日单量上万、要求分钟级进仓，推送优先。
二是平台能力，部分平台不提供订单事件通知，只能轮询，以官方开发者文档为准。三是团队运维能力，没能力维护签名验证和重试监控的团队，硬上推送反而更容易出事。
混合方案的落地方式是：推送负责把订单第一时间落到中间表，轮询每5到15分钟按更新时间窗口扫一遍做补偿，两侧共用同一个唯一键去重，这样即使推送全丢，最坏结果也只是延迟一个轮询周期。
老板问我系统稳不稳，我只能回答目前没出大问题。但到底什么标准算稳？下次上线或换ERP时，我希望有一套能直接拿出来的验收口径，而不是靠感觉。
给一套能对账、能看趋势、能定位责任的口径。第一层是对账，按日做三个维度：订单量对账，ERP按创建时间分天的单量对平台后台同维度导出量；金额对账，看订单实付总额，但币种和汇率换算口径必须固定，是用下单口径还是结算口径要写进文档；状态对账，ERP里的待发货单与平台后台同状态单逐单比对。
差异要能下钻到订单号，不能只给总数。第二层是延迟与失败，看中位数和P95而不是平均值：P50反映常态体验，P95暴露长尾卡顿，大促前尤其要看P95；失败率要把接口失败和处理后失败分开统计，前者反映平台侧稳定性，后者反映自己的业务规则；还要单列人工介入单量，这个数字长期不为零说明自动化没闭环。
第三层是告警有效性，能自动处理的只记录，需要人介入的必须告警：同步任务心跳中断、失败队列积压、单店延迟超阈值、授权即将过期、限流被触发。阈值给个起点参考：延迟P95超过一个轮询周期的3倍、失败队列超过当日单量的1%、连续两个周期对账不平，都该告警。这些是经验值不是平台标准，按自身单量和发货时效调整。
上线验收建议要求连续跑满7天并覆盖一个周末或小活动日，对账全平、差异逐笔有解释，才算通过。
读者评论
对账闭环这段很认同。很多团队上线后反而停了对账，因为系统看起来没问题，文中基础同步阶段日对账执行率0%特别真实，不出事根本想不到查。
时间窗口加状态过滤的组合效应太容易被忽略，我们之前用近7天付款加待发货，结果已发货订单全漏了，物流单号一直回写不了，确实要按全生命周期检查。
幂等和并发写重讲得很具体，17单重复发货损失2.1万不算夸张。唯一索引加事务内存在性检查、按店铺分片，基本是订单同步必须补的课。
异常人工介入率这个指标有用，但0.3%对多平台多店铺可能偏理想，类目、客单价、售后复杂度不同，最好先记录基线再定压降目标。
退款未同步导致财务口径差2.3万，说明同步范围定义比接口稳定更关键。建议把退款、退货入库也纳入日对账，否则利润表对不上时排查成本太高。