从手持终端到云端的进化：软件系统公司谈手机代替扫码枪小程序的离线缓存架构设计
早些年去仓库走访，见到库管员手里那个巴掌大的扫码枪，或者更贵一点的工业级手持终端（PDA），总觉得那是数字化的“铁疙瘩”。它们稳定、专一，但死贵，一台动辄两三千，系统升级还得返厂刷机。这两年智能手机性能过剩，加上微信小程序的生态成熟，我们作为一家做了八年企业软件系统的服务商，接触到不少零售、物流客户，都想用便宜的安卓手机加小程序把扫码枪替了。这事儿我们很早就切入做替换方案，但真正落地时才发现：把扫码枪的功能搬进手机界面不难，难的是让手机在没网、弱网的时候，依然像个真枪。
为什么这么说？扫码枪本质是离线优先的终端，数据存在本地Flash，按键即存，网络只是后台可有可无的同步通道。而普通小程序开发者习惯性依赖云端API，一旦仓库角落信号差，页面转圈，扫码就卡死，一线员工直接骂娘。所以我们从第一个仓储项目开始，就强制要求架构组按“终端级离线”标准来设计缓存层，不然这方案根本交不了货。
在我们交付的手机替代方案中，离线缓存架构主要分三层来落地。最底层是本地持久化存储。微信小程序自带的Storage同步接口只有5MB且性能一般，扛不住高频扫码写入。我们后来采用了基于IndexedDB封装的本地库（通过小程序基础库提供的插件能力实现），单库能扩到50MB以上，写读都在毫秒级。我们把商品主数据、批次号、当前盘点任务快照全塞进去，开机先拉一次，之后本地查，体验上和手持机内置数据库没两样。
中间层是操作日志队列。员工每扫一个码，不管有没有网，先往本地队列里推一条事件，状态标记“待同步”。这保证了交互零延迟——和原来按扫码枪扳机听到“滴”声出字一模一样。我们甚至做了本地冲突预检：比如同一个SKU在本地已被出库，再扫入会立即弹窗提醒，不用等服务器往返。这个设计是跟一家服装仓的组长聊出来的，他们最怕重复扫。
最上层是智能同步与冲突仲裁。网络恢复时，客户端按时间戳加业务单号向云端发起批量提交。这里头有个坑：多台手机同时操作同一托盘怎么办？我们的云端采用“最后写入优先加业务规则修正”，比如入库以实扫数量最大为准，出库以先提交为准，避免超卖。同步过程做增量压缩，走MQTT而不是HTTP长轮询，省流量且快。
去年双十一，我们给华东一家汽配城做的统仓统配项目，正好验证这套架构。那天仓库Wi-Fi崩了将近二十分钟，十几个临时工拿着自己手机在小程序上继续收货、上架，没人停工。网络恢复后，后台两分钟内吞下三千多条离线记录，库存账面秒级平账。老板后来跟我说，这比他以前买的十万块手持设备还稳当。
当然，手机代替扫码枪不只是技术问题，还有安全和管控。本地缓存必须加密，我们用了国密SM4对落盘数据加密，手机丢了远程可擦除。权限上也收口到企业微信，非本企业员工打不开业务缓存。
回头看，从笨重的手持终端到轻巧的云端小程序，并不是简单把屏幕变小、把系统上云，而是把终端的“离线韧性”和云的“弹性计算”真正融合。作为软件系统公司，我们一直认为：好用的企业级产品，从来不是炫技，而是在没网、没电、没耐心的时候，还能让员工顺利扫完那一箱货。这，就是我们在设计手机扫码小程序时，坚持做重离线缓存架构的初衷。
微信号：18581869297
