我司自研手机当扫码枪小程序通过边缘计算实现高并发库存管理的实战分享
去年双十一压测的时候，我们中心机房差点瘫了。当时仓里临时扩招了上百个分拣员，每人发一把租来的扫码枪，结果半天内坏了十几把。情急之下，好些人拿自己手机扫我们旧版H5页面，延迟高得离谱，一分钟内重复提交把库存数搅乱了。我那时是负责仓储数字化落地的，那次背了不小的锅。痛定思痛，我们决定自研一套“手机当扫码枪”的小程序，并且用边缘计算思路来化解高并发难题。
说起来，很多同行第一反应是：手机摄像头怎么比得上激光枪？其实千元机配合微信最新的扫码识别引擎，速度已经够快，真正卡点在于后端架构。我们之前的逻辑是“扫一次、传一次、查一次库、写一次”，在日均十万单的仓里，这种中心化请求就是自杀。复盘会上有个年轻开发提了句：能不能让手机先自己算？这给了我灵感——边缘计算不一定非得是机房加边缘盒子，员工的手机就是最现成的边缘节点。
我们产品技术线加起来才不到十个人，预算紧。选定小程序而非APP，原因很现实：仓管员流动性大，APP推送安装包他们嫌麻烦，激活率惨不忍睹；小程序扫码即开，且微信账号天然绑定了员工身份，权限管控省事。重点在架构：我们将商品条码库增量包通过后台静默下发到小程序本地存储，扫描动作完全本地完成解码和品类匹配。更关键的是，我们写了一个轻量状态机跑在JS逻辑层，对出入库操作做本地的预扣减和合法性校验。比如扫码数量超过采购单阈值，手机直接弹窗报错，根本不走网络。
实战是在今年618。我们自营的三个区域仓全面铺开。华东仓晚高峰每分钟扫码峰值冲到1800次以上，如果按老办法直击数据库，连接池瞬间耗尽。但那天空前平稳。监控曲线显示，由于边缘层做了批量合并和差分上传（每5秒或积满20条才发一次加密报文），云端实际接收的有效写请求削峰了差不多11倍。有个叫老王的仓管员，用一台碎了屏的红米Note，一晚扫了四万三千多件小商品，反馈“比枪还跟手”。
当然，踩坑也不少。仓库铁皮房信号死角多，早期版本在地下拣货区直接断链导致数据暂存丢失。我们紧急加了本地队列持久化，利用小程序的FileSystemManager做落盘，断网半小时也能恢复。还有安卓碎片化，某些OPPO老机型对焦慢，我们接入了微信的增强识别模式，并允许边缘端在识别失败时切换手动录入，但手动数据打特殊标签待云端复核。安全方面，边缘端只签发不可篡改的操作日志，核心库存落账必须云端用秘钥二次确认，防内鬼篡改。
回头看这半年，这套自研方案把高并发库存管理的门槛踩碎了。扫码峰值承载提升近9倍，专业扫码枪采购费省了四十多万，错单率反而降到万分之四。我常跟同行说，别迷信笨重硬件和无限堆服务器，把计算下沉到一线人员的手机，用小程序做载体，中小仓储也能玩转边缘智能。这算是我们交的学费换来的经验，希望能给在泥潭里挣扎的兄弟一点启发。
微信号：18581869297
