去年八月的一个周六，中午十一点半，其中一家店的宽带断了。施工队在门口挖沟，把进户的光纤带断了，报修之后等了四个多小时才接上。那四个小时正好是周末的高峰，店里六个人，收银台前排着队，扫码枪还能扫商品，但支付码刷不出来，会员也查不了。

当天我们只能收现金，一笔一笔记在纸上，晚上手工补录。四小时记了六十三笔，补录时错了五笔，其中两笔金额录反，一笔重复录了两次，还有两笔漏了会员折扣。第二天对账对到晚上八点。这事之后我把离线收银做了一遍，现在断网只影响扫码付，收银、开单、库存扣减照常，网络回来两分钟内自动补完。

结论是：断网收银的关键不在"能不能开单"，而在"补传的时候账不重复、不乱序、不覆盖"。开单谁都会做，补传做不好，等于给对账埋雷。

## 一、断网时到底丢了什么

### 1.1 扫码付不了，现金还能收

断网不等于停业，这是先要认清的事。支付通道依赖网络，断网时扫码付确实走不通，但现金、储值卡（本地能验）、店内挂账都能继续。真正卡住的是三件事：商品价格查不到、会员折扣算不出、库存扣不了。

这三件事的共同点是都依赖服务端。所以离线方案的头一步不是改支付，是让收银端手里有一份能用的数据副本：商品价格表、会员等级规则、当前库存余量。这三份数据每天开门前同步一次，断网时读本地副本。

### 1.2 单据断档比少收钱更麻烦

少收一笔钱是小事，单据断档是大事。断网期间开出的单如果没有本地编号，补传时就分不清哪些传过、哪些没传，重复传一次就是一笔虚增的销售，少传一次就是一笔漏账。两种情况都会让当天的日报对不上。

所以离线模式要先做的一件事，是给每笔单一个本地单号。这个号在断网期间自己生成，不依赖服务端，网络恢复后随单一起上传。服务端认这个号，重复的丢弃，缺号的报警。

### 1.3 补传容易出的三类错

我们踩过的坑归成三类。重复：同一笔单传了两次，销售虚增，库存多扣。乱序：后开的单先传，先开的单后传，日结的时段统计错位。覆盖：断网期间改过价的商品，补传时把服务端的新价覆盖回旧价。

这三类错里，重复靠幂等键解决，乱序靠单号排序加时间戳，覆盖靠"补传只写交易、不写主数据"。末了这条是原则：补传只允许新增流水，不允许修改商品、价格、会员这些基础数据。

## 二、本地先记账，网络回来再补

### 2.1 本地单号怎么编

单号规则是"店号 + 设备号 + 当日序号 + 校验位"，比如三号店的二号收银机当天的第十七笔。这个号全局不重复，因为它带店号和设备号；它又可排序，因为序号按时间递增。

生成单号不需要联网，本地存一个当日计数器，写在磁盘上，每次开单加一。计数器要落盘，不能只放内存，否则收银机一重启，序号回到零，当天就会出现重复单号。

### 2.2 幂等靠一个键，不靠查重

服务端判断重复，不能靠"查一下有没有这个单号"——断网补传是并发的，两台设备同时传，查重有竞态。做法是给流水表建一个唯一索引，键就是本地单号，插入冲突就丢弃并记一条日志。

这个做法简单但要求单号真的唯一。所以单号里必须带设备号，两台收银机各自生成序号，光靠店号加序号一定会撞。

### 2.3 库存和会员的账怎么补

断网期间的库存扣减在本地做，补传时随流水一起上传。库存服务收到流水后按单号幂等扣减，重复的单不会再扣一次。这里要接受一个现实：断网期间本地库存和服务端库存会短暂不一致，可能出现超卖，恢复后要能对出来。

会员积分和折扣同理。折扣在本地按快照规则算，积分在补传后由服务端补记，补记用流水时间而不是上传时间，否则会员会看到积分在某一天突然集中到账。

## 三、同步配置怎么写

### 3.1 配置项逐个说

配置分四块：队列、触发、重试、核对。队列管本地存多少条、多久刷一次；触发管什么时候开始补传；重试管失败怎么办；核对管补完之后怎么验。

队列容量要给个上限，不能无限攒。按我们的量，一个店断网一天攒三百到五百笔，上限设五千条够用两三天。超过上限就转为"只记账不上传"并告警，不能悄悄丢单。

### 3.2 完整配置

```yaml
offline:
  enabled: true
  spool_dir: ./spool            # 本地队列落盘目录
  local_id: "{store}-{device}-{seq}-{check}"   # 本地单号模板
  queue:
    max_records: 5000           # 攒满转只记账模式并告警
    flush_interval_sec: 15      # 有网时也按这个间隔刷盘
    batch_size: 50
  sync:
    trigger: [net_up, timer]    # 网络恢复或定时唤醒
    idle_seconds: 30            # 网络稳定 30 秒后才开始补传
    order: fifo_per_store       # 同一门店按单号先后补传
    concurrency: 1              # 单店串行，避免乱序
    idempotency:
      key: local_ticket         # 服务端唯一索引字段
      dedupe_window_hours: 72
    retry:
      delays_sec: [10, 30, 90, 300, 900]
      jitter: 0.2               # 加抖动，避免多店同时重试
      give_up_after: 8
      on_give_up: mark_manual   # 转人工处理，不丢弃
  reconcile:
    compare: [count, amount, stock_delta]
    mismatch_action: hold_and_report
    report_after: shift_close
  snapshot:
    goods_ttl_hours: 12
    member_ttl_hours: 24
    fallback: last_known        # 快照过期仍用上次数据，不用空值
```

### 3.3 重试和退避

重试的次数和间隔有讲究。间隔太短，网络刚恢复时几十台设备一起冲，服务端顶不住；间隔太长，一笔单要等半小时。我们用的是十秒起、五倍递增、至多五次，加两成随机抖动，把请求摊开。

放弃重试不等于丢单，转成人工待处理。这类单进一张清单，标上失败原因，第二天由店长逐笔确认。放弃的条件写清楚：连续失败八次，或者服务端返回明确的业务错误（比如商品已下架）。

这套离线队列的落库、补传任务和核对报表，我们放在搭贝里跑，改配置不用发版。

## 四、演练比配置重要

### 4.1 每月拔一次网线

配置写得再好，没演练过就是纸面方案。我们每月挑一个平峰时段，把收银机的网线拔掉十分钟，走一遍完整流程：断网、开单、恢复、补传、核对。头一次演练就发现了两个问题：本地单号没落盘，重启后重号；补传时排序按上传时间而不是单号。

演练要选在有人能处理的时间，别在打烊后做，因为打烊后没人开单，演练等于没演。我们选周二下午三点，客流平，店员有空配合。

### 4.2 断网期间的收银口径

断网时要给店员一个明确口径，不能让他们自己判断。我们的口径是三句话：能收现金就收，扫码付引导顾客稍后再付或者换现金，会员折扣按本地快照算、事后不补差。

第三句常有争议。有顾客会问为什么这次没打折，店员要能解释清楚。我们印了一张卡片放在收银台，写明断网期间折扣按本地记录算，如果算错，凭小票补差。这张卡片省了很多口舌。

### 4.3 恢复后的核对

网络恢复后不能只看"补传成功"就完事，要核对三个数：笔数、金额、库存变动。笔数对比本地队列条数和服务端新增条数，金额对比本地汇总和服务端汇总，库存变动对比补传前后的余量差。

三个数里常出问题的是库存。因为断网期间可能有多台设备同时卖同一件商品，本地各自扣各自的，补传后服务端的余量可能出现负数。出现负数不要紧，要紧的是当天能查出来，别等到盘点才发现。

### 4.4 断网和弱网要分开处理

完全断网和网络时断时续是两种情况。完全断网好判断，直接进离线模式；弱网麻烦，请求发出去没回音，收银端不知道该等还是该走离线。我们的做法是设一个三秒超时，超时就按离线处理，同时后台继续探测，探测通了再补传。

这条规则的价值在于不让收银员等。顾客站在收银台前，收银员盯着转圈的界面，这三十秒比断网四小时更伤体验。

## 五、做完之后的账

### 5.1 影响面收窄了

现在断网影响的是扫码付一个通道，其余照常。上个月又断过一次，两个多小时，店里开了四十一单，全部是现金和储值，网络回来后两分钟补完，对账当晚就平了。

### 5.2 心态变了

比数字更重要的是店员不再慌。以前一断网，店长先想到的是打电话报修，第二反应是问"要不要关门"。现在流程写在卡片上，谁当班谁按卡片做，店长该做什么做什么。

离线收银这套东西，技术上是本地队列加幂等补传，没什么新鲜算法。真正难的是把边界想清楚：哪些数据可以本地算，哪些必须等服务端，补传允许写什么、不允许写什么。边界清楚了，代码就不难写。

## 常见问题

**问：本地队列存在收银机的磁盘上，机器坏了单子是不是就没了？**

答：会丢，所以要双写。一笔单同时写本地队列文件和一张本地数据库表，两者落在同一块盘上，机器整体损坏仍然一起丢。要防这种情况，得把队列同步到店内的另一台设备或者一台小服务器上，代价是复杂度上升。我们的取舍是接受单机风险，但要求收银机每天备份队列文件到U盘。

**问：补传时服务端怎么判断是重复还是真的重传？**

答：靠本地单号的唯一索引。服务端流水表对本地单号建唯一约束，插入冲突就返回已存在，客户端把这条从队列里删掉，不再重试。这个判断不依赖时间窗口，所以隔一天再传也不会重复。要注意的是单号里必须含设备标识，否则两台机器会生成一样的号。

**问：断网期间商品价格变了，补传按哪个价？**

答：按开单时的本地快照价，因为顾客是按那个价付的钱。补传只写交易流水，不写商品主数据，所以不会把服务端的新价覆盖回去。为了让这个规则可执行，本地快照要带版本号和生成时间，补传时一起上传，事后能查出这笔单用的是哪一版价格。

**问：离线模式要不要限制时长？**

答：要。我们的规则是连续离线超过四小时就提醒店长确认是否继续营业，超过八小时转入只收现金、不接挂账。原因是离线时间越长，本地数据和服务端的偏差越大，补传后需要人工核对的量也越大。限制时长不是技术限制，是风险控制。

去年八月的一个周六，中午十一点半，其中一家店的宽带断了。施工队在门口挖沟，把进户的光纤带断了，报修之后等了四个多小时才接上。那四个小时正好是周末的高峰，店里六个人，收银台前排着队，扫码枪还能扫商品，但支付码刷不出来，会员也查不了。

门店断网收银：本地记账后补传

门店断网易导致收银停滞、手工补单出错。该离线收银方案提前缓存商品、会员、库存快照，断网时本地生成唯一单号落盘开单，支持现金、储值收款。网络恢复后串行补传流水，依靠幂等机制防重复、乱序，只同步交易数据。搭配重试校验、定期演练，仅扫码支付受限，有效减少对账差错。

人工智能

断网收银关键在补传不重复、不乱序、不覆盖。本地单号+幂等键解决重复，按序补传避免乱序，只写流水不写主数据防覆盖。每月演练，明确收银口径，恢复后核对笔数、金额、库存三项数据。

代码解释

数据库

服务器

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

门店断网收银：本地记账后补传-腾讯云开发者社区-腾讯云

门店断网收银：本地记账后补传

门店断网收银：本地记账后补传

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐