手机取代扫码枪？我们零售中台团队在门店库存数字化中的实战笔记
去年夏天，华东区运营负责人老周在月度会上甩出一张维修单：旗下210家直营门店标配的工业扫码枪，季度报废替换花了87万。他半开玩笑地甩了一句，“现在店员人人揣着旗舰机，能不能让微信扫一扫就把进货出库给办了？”作为零售系统部的技术负责人，我当场就皱了眉。扫码枪那玩意儿虽说古董，但专用激光头毫秒解码、皮实耐造；微信小程序隔着一层沙箱调摄像头，能扛住大促盘点的蹂躏？
老板却当了真，要求我们两周出PoC。于是我们悄悄启动了内部叫“轻舟”的专项，目标是用手机小程序彻底替掉扫码枪，重构门店库存管理链路。
真做起来，才发现水有多深。
第一道坎是识别率和功耗。门店光环境太妖：冷柜玻璃反光、射灯过曝、还有配送箱上被雨淋糊的条码。起初我们偷懒用了小程序原生scanCode，实测一次扫码成功率仅68%，尤其对褪色的EAN-13码，误识率离谱。后来狠下心，把ZXing的C 核心通过Emscripten编成WebAssembly，直接在小程序逻辑层抓相机帧。为了不让中低端安卓机变暖手宝，我们把识别区锁死在屏幕中央一块“血条”框，做多帧投票——连续三帧解出同码才响铃。这一改，iPhone 8这种老古董也能做到120毫秒出码，综合成功率拉到99.3%。
可盘点不是扫一个就完事。大促前全店盘点，店员举着手机连扫上千件，手机降频后帧率从30掉到8，小程序直接假死。我们被迫把解码丢进Worker线程，主线程只管UI和震动反馈。这里有个坑：微信基础库2.19之前，Worker里拿不到相机帧，我们只好用canvas定时截取并转ArrayBuffer塞给子线程，虽然绕，但救了命。
网络更是鬼门关。社区店共享宽带，晚高峰信号只剩两格。若每扫一笔就调后台接口，库存请求堆积，超卖分分钟发生。我们的解法是“本地事务优先”：小程序内嵌IndexedDB，所有出入库先写本地，打门店ID和时间戳。网络恢复后，以门店维度批量上报。中台那边我们早改成了事件溯源架构——小程序传的不是“减库存1”指令，而是“门店A于T时刻发生出库事件，条码X”。后端用Kafka削峰，落MySQL同时刷Elasticsearch。这样即便每秒涌进上万条扫码，系统也稳如老狗。
安全不能马虎。手机是店员私人设备，丢了扫码枪顶多赔钱，丢手机可能泄库。我们在小程序入口加了企业微信身份 动态令牌双因子，每次进库存模块刷脸续期。所有操作日志精确到“谁在几点扫了哪码，SKU状态变更”，审计组后来靠这日志揪出两起门店截货案。
其实技术之外，我们还倒逼供应链做了条码治理。原先供应商贴的码段制式五花八门，甚至有自己打印的CODE128没校验位。小程序上线前，我们联合质控部门推行了“一物一标”清洗，把异常码提前拦截在入库前。这也是为什么后期识别率能冲上99%的隐形功臣。
上线半年，账面上：210家店硬件采购费归零，单店盘点工时从14小时压到5小时，库存差异率由1.8%降到0.3%。Gartner去年那张零售技术曲线里，“消费设备企业化”还在爬坡期，我们相当于自己先蹚了河。
回头看，手机替代扫码枪绝不是装个相机API就完事。它逼着我们把重后台做轻、把边缘端做智。下一步，我们正测试手机NFC桥接RFID，或许不久后，店员一部手机就能接管全店货品流。
微信号：18581869297
