从条码到云端，我们研发的手机代替扫码枪小程序在零售盘点中的低延时架构实践
作为专注零售数字化八年的技术团队，我们去年夏天接手了一个挺棘手的活儿——国内一家区域连锁超市（有三百多家门店）找到我们，说他们每年大盘点光扫码枪的折旧和维修就花掉小几十万，还经常丢枪、电池罢工。他们想用店员自己的手机，通过微信小程序就能完成盘点，但提了个硬指标：体验必须和扫码枪一样快，也就是从扫条码到后台确认，端到端延时不能超过150毫秒。说实话，一开始我们心里也没底，毕竟当时市面上类似方案大多停留在“能扫就行”，延时动辄半秒以上，店员扫完还得愣一下等反应。
传统扫码枪为什么快？因为它本质上是纯本地输入设备，嘀一声就进系统了，数据走串口或蓝牙到POS机，再批量传。但手机小程序扫条码，链路是：相机取帧→算法识别→小程序逻辑→网络上报→云端处理→回执下发。这一长串，任何一环卡顿，店员就会觉得“不如枪好用”。我们目标很明确：把端到端延时压到人体无感，让手指头比脑子快。
端侧优化是第一战。微信小程序默认相机组件是连续帧回调，我们最初用 onCameraFrame 拿 RGBA 数据喂给 ZXing 的 JS 移植版，结果在红米 Note 9 这类千元机上识别一帧要 200ms 以上，手机烫得能煎蛋。后来改了策略：调用原生相机拍照而非实时流，配合自研的二值化加局部自适应阈值，只在用户点击瞬间抓拍解码，识别压到 30ms 内。同时，小程序里搞了本地 IndexedDB 队列，扫完先存本地，立刻震动反馈，不让店员等网络。这步很关键，体感速度都是靠本地闭环堆出来的。
网络传输是重头戏。普通 HTTPS POST 建连就要几十毫秒，加上小程序后台限制，根本达不到低延时。我们上了微信的 WebSocket 通道，并和一家云厂商合作，在他们的边缘节点（覆盖到地市）部署了接入网关。数据格式放弃 JSON，改用 Protocol Buffers 序列化，一个盘点包从 200 字节降到 60 字节。心跳 25 秒一次防回收。安全上，我们用国密 SM4 对商品条码和批次信息加密，避免中间人嗅探，毕竟盘点数据也算商业敏感。
云端架构也针对性设计。网关收到数据直接进 Kafka 高吞吐队列，消费者服务做幂等校验后写 Redis 热区，再异步刷 PostgreSQL。为极速回执，我们在网关层就直接回 ack“已收录”，而非等数据库落盘。压测中，单边缘节点扛 8k QPS 扫码峰值，平均往返延时 110ms（4G 网络下），iPhone 12 上甚至到了 90ms，比客户要求的 150ms 还低一截。
坑也不少。Android 微信里 WebSocket 在息屏后会被系统挂起，我们靠小程序后台音频播放的“歪招”保活，虽然有点讨巧但真管用；还有弱网门店（比如地下超市信号差），我们靠本地队列加指数退避重传，保证最终一致性，上线半年盘完点上传率 100%，没丢过一条记录。
上线那个月，客户三百家店用了这个小程序做月度盘点，硬件成本直接归零，单店盘点工时缩短 40%。最近我们在测 AR 辅助盘点，用手机摄像头直接框选货架，也许明年这个时候，连条码都不用对准了。
回头看，从条码到云端，所谓低延时不是玄学，就是一层层扒开链路，把每个毫秒都抠出来。如果你也在做类似零售数字化，欢迎交流，有些坑我们替你踩过了。
微信号：18581869297
