软件系统公司实战分享：手机当扫码枪小程序如何借助边缘计算实现离线极速盘点
做了十几年软件系统，最怕客户轻描淡写来一句“这个需求很简单”。但去年秋天，华中一家连锁生鲜超市的老板就这么对我们说：“让店员用手机当扫码枪，小程序扫扫就行，不难吧？”作为深耕仓储零售信息化十二年的老江湖，我们当时笑笑没反驳，心里清楚，坑都在后头。
客户是华中地区一家连锁生鲜超市，三十多家门店，单店SKU常年在四千到六千浮动。他们老板原先图省事，买了批手持扫码枪，结果不到两年，电池鼓包、系统断更，维保报价贵得离谱。去年找上我们，提了上文那个粗暴需求。这需求听着简单，真做起来水很深。
最大的坑在网络。超市仓库多在地下室或后场，4G信号两格，WiFi一穿墙就掉线。如果用传统小程序直连云端API，每次扫码后要把条码、批次、数量POST到服务器，等返回成功再允许下一扫。我们工程师扛着抓包工具在门店蹲了三天，压测发现，在弱网环境下，单次交互延迟能飙到800毫秒甚至直接超时。店员扫一瓶酱油，得盯着加载圈转半天，一天扫两千件，纯等待时间就吃掉半小时以上，还极易漏扫、重扫。老板原想省设备钱，结果效率反而塌了。
我们团队一琢磨，不能把所有算力压在云端啊。于是架构上做了个当时看来挺大胆的改动：引入边缘计算节点。具体落地的样子是，在每家门店的后台办公区塞了一台无风扇工控机（成本不到八百块），预装轻量边缘服务，通过店内路由器形成局域网。手机小程序不直接连云，而是先连这个边缘节点，走内部WiFi或蓝牙配网。
这里得夸一下微信小程序的能力，很多人以为它只是个前端壳，其实利用本地存储和JS引擎，能做不少边缘侧计算。我们在手机端就完成了条码格式校验、重复扫描拦截、盘点单预聚合。比如同一商品扫两次，手机本地立刻提示“已录入，数量 1”，根本不用问边缘节点。只有遇到新品或库存不一致时，才向边缘节点查本地缓存的库存基准表。边缘节点和手机之间网络延迟稳定在10毫秒内，店员手速再快也跟得上。
真正让客户拍案叫绝的是离线能力。我们设计了三级缓存：手机小程序IndexedDB存草稿，边缘节点Redis存正式盘点差异表，云端仅做最终归档。有一次门店搞夜间大盘点，正好路由器抽风死机，半个钟头纯离线。店员接着扫，数据全暂存在手机里，恢复后自动同步边缘再上云，零丢失。这要是老式扫码枪或者纯云方案，当场就得歇菜。
项目上线后我们拉了实测数据：改造前云端方案平均扫码间隔320ms，改造后本地边缘闭环压到15ms以内，盘点效率提升近20倍——别怀疑，因为等待消失了。一家店六千件货，原来四人两小时，现在两人一小时出头搞定。错误率从之前手工记录的千分之五降到万分之二。
这个项目给我们团队蛮大触动。很多同行觉得边缘计算是工业互联网、自动驾驶才玩的高端词，其实在民用级小程序里，只要想清楚数据在哪里算、在哪里存，一样能落地生花。我们甚至把这套方案抽离成标准模块，叫“轻边缘盘点引擎”，后来给一家服装客户部署，一周就接好了。
如果你也在被盘点效率折腾，或者觉得扫码枪是笔冤枉钱，不妨想想手里的手机。它可能比你想的更强大，缺的只是背后那点不炫酷但踏实的技术巧思。
微信号：18581869297
