软件系统公司技术复盘：手机代替扫码枪小程序在连锁门店库存同步中的边缘计算应用
我们公司主要给连锁零售做定制化ERP和SaaS中台，这几年手里有大约两百来家门店客户。今天这篇算是内部技术复盘的对外精简版，聊一个挺接地气但技术含量不低的项目——怎么用手机小程序替代传统扫码枪，并且在库存同步里把边缘计算真正用起来。
这事起因很简单。去年初，一家做母婴连锁的客户跟我们吐槽，说他们每家店配4把扫码枪，一把两千多，一年坏好几把，系统升级还得挨个门店跑。他们问：现在店员人人有手机，能不能用手机扫条码，直接在我们系统里改库存？产品经理一听觉得可行，原型很快画出来了：微信小程序调起相机，识别EAN-13码，调云端接口写库存。
但我们在技术评审时直接否了这个“直连云”的幼稚方案。为啥？因为门店网络太烂了。我们后来实测，那些开在地下商场或老社区的门店，WiFi抖动严重，4G死角多。小程序直接发HTTPS请求到中心云，高峰期延迟能到1秒多，扫码后转圈圈，店员骂娘。更致命的是，一旦断网，小程序本地缓存靠不住（微信对本地存储有清理机制），盘点数据说没就没。
于是我们定了架构：端（手机小程序） 边（门店边缘计算节点） 云（中心库存服务）。
边缘节点我们没用花哨的玩意儿，就是门店收银台底下塞一个无风扇工控小主机（x86，8G内存，跑Docker）。手机小程序通过店内局域网，用MQTT协议把扫码事件发给边缘节点。注意，这里手机只做采集，不做逻辑。当时我们前端用uni-app写的扫码页，调用原生相机插件，比纯webview识别快不少。
边缘节点承担的核心计算有这几块：
1. 主数据就近缓存。云端把该门店的SKU、价格、供应商表每天增量推到边缘，扫码时立刻本地校验，不用跨公网。
2. 库存流水合并。店员盘点经常连扫，边缘按商品ID在10秒窗口内做累加合并，减少上行包量。
3. 离线兜底与最终一致。断网时边缘照单全收，存在本地SQLite；网络恢复后，按向量时钟标记版本，批量回传云端。云端用“门店最后写入获胜”策略解决冲突。
听起来美好，落地全是血泪。第一个大坑：边缘节点和云断了40分钟，某店周六满仓促销，边缘攒了3000 条流水。网络一通，瞬间全发往云端，我们的Spring Cloud网关直接被击溃，连累其他客户。后来我们加了边缘侧滑动窗口限流（每秒最多传50条），云端引入Kafka削峰，才解决。
第二个坑更细：安卓千元机在门店冷白光下扫码识别率仅70%，iOS反而95%。我们不愿推高端机，就把部分图像预处理放到边缘——手机传低分辨率预览帧到边缘，边缘跑轻量OpenCV做对比度增强再识别，相当于把视觉计算边缘化，识别率拉到92%以上。
安全方面也得提一嘴，门店边缘节点和云端通信用了双向TLS，手机到边缘是局域网内HTTP 门店动态token，避免有人拿手机乱扫。这块我们安全团队一开始没重视，后来渗透测试查出漏洞才补上。
还有个插曲：架构组当时和运维吵，运维想用树莓派当边缘，便宜啊。结果门店高温密闭环境跑两周，SD卡坏了。换工业级盒子后稳定。
从去年6月推到年底，120家门店全量上线。复盘数据：单店年硬件成本从约2000元降到150元（利旧手机 小主机分摊）；本地扫码到库存可见延迟<50ms；云端日处理冗余请求降80%；因为边缘合并，大促期间带宽费省了三分之一。最关键是店员接受度高，不用培训，拿出手机就扫。
总结一句，手机代替扫码枪，表面是前端采集方式变更，背后必须依赖边缘计算做缓冲和预处理。云边协同在零售库存这个场景，不是PPT概念，是续命良药。同行若做类似项目，切记边缘设备别贪便宜，以及断网重连的洪峰一定要在边侧压住。
微信号：18581869297
