做连锁门店系统，最容易被忽视、却最影响一线体验的，不是高峰并发，而是门店那不稳定的网络。商场地下一层信号差、沿街门店晚高峰宽带拥塞、收银机偶尔直接掉线——如果系统一断网就无法收银，再好的架构在店员手里都等于零。一个可靠的连锁系统必须做到：断网时门店照常开单、不超卖，网络恢复后单据自动补传、各端数据最终对齐。本文围绕这个目标，把数据归属、离线交易、库存裁决、冲突对账串成一条完整链路，并给出可落地的实现要点。
一、先划清三类数据的"可写权"
很多对不上账的问题，根源在设计之初就让多个端都能改同一份数据。动手写同步逻辑前，先按"谁产生、谁负责"把数据分成三类，各自只保留一个可写入口：
- 下行类（商品资料、售价、会员等级规则）：唯一可写方是总部后台，门店终端只读。门店看到的旧价格只是"还没同步到"，永远不允许就地改价后回传覆盖总部；
- 上行类（门店订单、收银流水、本地库存变动）：唯一可写方是产生交易的那台终端，总部只接收、不反向改写门店已生成的流水；
- 中心化类（会员储值、积分、优惠券核销）：全渠道共用一份，必须走中心校验，门店不落地可写副本，避免同一张储值卡在两台设备上同时消费。
可写权一旦划清，同步方向就不会乱：下行的追总部版本，上行的追门店流水，中心化的实时问中心。后面所有机制都是在维护这条边界。
二、下行数据：用版本水位做增量追平
门店终端在本地缓存一份商品主数据以供离线售卖。总部每次修改都让对应记录的版本号向前走一格，门店记住自己"已追到的版本水位"，每次轮询或重连时只拉水位之后的增量。
// 总部侧：每次变更产生一条版本递增的变更日志
function bumpMaster(spuId, patch) {
const next = db.masterVersion.next("product");
changelog.insert({
spuId, version: next, patch, at: new Date() });
}
// 门店侧：以本地水位拉增量，反复调用结果一致（天然幂等）
async function catchUp(storeId, localWatermark) {
const batch = await api.get("/master/changelog", {
params: {
storeId, since: localWatermark, size: 200 }
});
for (const change of batch.list) applyInOrder(change); // 严格按版本号顺序应用
return batch.latestVersion; // 返回新水位并持久化
}
三个细节决定它在弱网下稳不稳：增量必须按版本号顺序应用，乱序会让旧补丁覆盖新值；应用时以版本高低裁决，低版本补丁遇到高版本现状直接丢弃；服务端保留一段变更历史窗口，门店离线两天也能从旧水位连续追平，而不是被迫全量重拉。
三、离线交易：本地先落账，队列化补传
收银不能等网络。终端在本地维护一个可靠的待传队列：开单瞬间写本地库并生成"门店号+终端号+本地流水号"拼成的全局唯一单号，状态置为"待传"，顾客当场即可完成结账。网络恢复后，后台调度器把待传单据逐张上报，成功一张标记一张。
async function flushPending() {
const pending = localDb.orders.where("syncState").equals("PENDING").toArray();
for (const order of pending) {
try {
await api.post("/order/upstream", order, {
headers: {
"Idempotency-Key": order.globalNo } // 用业务单号兜底重复
});
localDb.orders.update(order.id, {
syncState: "ACKED", ackAt: new Date() });
} catch (e) {
if (!isRetryable(e)) markManually(order, e); // 业务级错误转人工，不无限重试
else break; // 网络仍不通，保留队列下次再传
}
}
}
这里的关键不是"能重试"，而是区分两种失败：网络抖动类可以放心重传，业务拒绝类（比如中心判定该单已退款）必须摘出来人工处理，否则会在队列里死循环。单号即幂等键，保证同一张单无论重传多少次，中心只入账一次。
四、库存：本地预占 + 中心裁决，杜绝超卖
离线状态下无法实时问中心库存，又不能让顾客拿着最后一件商品在两台收银机上同时结账。可行的做法是"本地预占、中心裁决"：
-- 中心侧：一条带条件的语句完成"判断+扣减"，拒绝先查后扣
UPDATE central_stock
SET locked = locked + :need, ver = ver + 1
WHERE sku_id = :sku AND ver = :seenVer AND available - locked >= :need;
影响行数为 0 即代表版本已变或可用量不足，本次预占失败。门店离线时先按本地缓存的可用量做软预占并记录占用凭证，补传时由中心用上面的原子语句做最终裁决：裁决通过转为正式扣减，裁决不通过（例如别的门店已先卖掉）则挂起该单、提示店员与顾客协商换货或退款。这样既保证了断网可售，又把"是否真的还有货"的最终决定权收敛到中心，从机制上消灭超卖。
五、最终对齐：分级对账而不是盲目覆盖
再严谨的实时链路，也挡不住人工改库、极端宕机和边界 bug，所以对账不是可选项。建议每天营业结束后跑一次三方核对：总部主数据版本 vs 各门店水位、中心库存流水 vs 门店销售流水、中心订单金额 vs 门店收银金额，产出差异清单。差异要按性质分级处置：
- 主数据版本落后：无歧义，以总部为准自动追平；
- 库存数量对不上：先回放出入库流水定位差异来源，再决定补扣或回补，不直接改结余数字；
- 订单/金额类差异：只告警、冻结，必须人工核对凭证后处理，绝不能用自动任务"抹平"，否则会把真实的丢单或错账永久掩盖。
每一次自动追平、每一笔人工修复都要留下"来源版本、时间、操作方"的审计记录，做到任意一张单都能向前追溯。
六、容易踩的坑
- 让门店也能改商品主数据并回传，结果旧价覆盖新价——下行类必须单一可写源；
- 离线只缓存不记本地水位，重连后只能全量拉取，商品上千时弱网必然超时；
- 库存"先 SELECT 判断再 UPDATE 扣减"，并发窗口内双双读到旧值，超卖由此产生；
- 补传接口不幂等，超时重试把同一笔订单入账两遍；
- 对账发现差异就自动覆盖，看似账平了，实则把丢单问题藏得更深；
- 业务拒绝和网络超时混为一谈，坏单在重试队列里空转到天亮。
七、工程落地建议
这套链路的骨架可以概括为四句话：可写权先划清、下行靠版本水位增量追平、上行靠本地队列加业务单号幂等、库存靠本地预占加中心原子裁决，最后用分级对账兜底。团队若在成型的门店经营系统上做二次开发，应优先确认平台是否已提供离线开单、断点续传、多门店库存协同与对账报表这些底层能力，把自研精力集中在自身的异常处置流程和对账规则配置上；若选择自研，请务必在第一个版本就把幂等键、版本号、对账任务这三样做进去，事后补做的代价远高于一开始就规划。
八、上线前自检清单
- 每一类数据是否都只有一个可写入口，不存在多端同时可写；
- 主数据是否带单调版本号，门店能否从任意旧水位连续、有序、幂等地追平；
- 主动断网后能否正常开单，恢复网络后待传单据是否自动补传且不重复；
- 业务拒绝与网络失败是否被区分处理，坏单能否被及时发现；
- 库存是否为中心原子裁决，是否压测过两台终端同时抢最后一件的场景；
- 日终对账是否覆盖版本、库存、金额三条线，差异是否分级、全程留痕。
结语
弱网和断网在连锁门店里不是异常，而是日常。围绕"断网可营业、恢复能对齐、最终不超卖、差异可追溯"来设计，本质上是用清晰的数据归属、幂等的同步链路和克制的对账策略，把不可靠的网络环境对业务的影响降到最低。把这几件事在第一版做扎实，门店数量从十家扩到几百家时，系统才不会被一笔笔对不上的账拖入泥潭。
