工业级手机搭载小程序替代扫码枪？仓储盘点中的技术落地与高并发架构实录
去年我们在给一家华东的汽配分销企业做仓储数字化改造时，客户提出一个很现实的需求：仓库里原来用的专业扫码枪每台两千多，电池衰了还得返厂，能不能直接用他们批量采购的工业三防手机，跑个微信小程序就把盘点干了？当时我们评估完觉得思路没问题，但真做起来才发现，把工业级手机当成扫码枪用，前端看着轻巧，背后的技术坑和数据并发压力一点不比原生APP少。
先说最基础的硬件对接。工业级手机像优博讯、东集这些牌子，主板上都集成了激光或影像扫码头，硬解码速度和容错率远超普通手机摄像头。但微信小程序原生API里并没有直接接收硬件扫码头系统广播的接口。如果你图省事只用camera组件做软解码（比如ZXing的wasm移植），在仓库昏暗、条码污损的环境下误码率能到3%以上，当场就得被仓管员骂死。我们的做法是让手机厂商刷了定制ROM，通过系统级Intent把解码后的字符串抛给一个轻量Native容器，小程序再以插件形式挂载，走onScanCode回调。这样扫码延迟控制在80毫秒内，和原生枪手感几乎无差。这里还有个细节：部分老批次机器广播Action名不一样，我们不得不在插件里维护了适配白名单，否则到了现场根本接不到码。
仓库网络死角多，小程序必须设计成离线优先。我们用了IndexedDB缓存放货记录，每次扫完先写本地日志，界面立刻返成功，后台 silently sync。端上做了指数退避和本地队列持久化，哪怕App被杀掉重启也能续传，否则高并发下服务端返回慢，小程序疯狂重试只会把网关打挂。实际压测时，一台手机断网扫了八百多条，恢复后五秒内全部补传完毕，这个体验才算过关。
真正麻烦的是高并发数据处理。盘点日往往全库全员上线，一个中型仓少说两三百人同时扫，每人每分钟扫10到20件，峰值写入QPS轻松破五千。如果小程序直接调REST接口往MySQL里upsert，数据库瞬间死锁没跑。我们的服务端架构是这样拆的：小程序端攒批，每满50条或间隔15秒，通过WebSocket压缩上报；接入层用Nginx做限流，后端丢进Kafka主题削峰。消费端起多个消费者组，先写Redis Cluster做暂存和去重（用SKU 库位做hash key），同时发异步消息给盘点调度服务。落库阶段我们没用强事务，而是搞了版本号冲突合并——同一个库位同一商品，不同人扫出不同数量，系统按时间戳和权重（比如正式工覆盖临时工）做最终一致。历史数据归档用HBase，便于后续追溯和审计。
还有一点容易忽略：盘点不是单纯写数据，还要实时看板。我们用了Redis Pub/Sub推送给大屏，但小程序侧只拉增量，避免全量轮询把移动网络拖爆。
整体下来，用工业级手机 小程序替代传统扫码枪，硬件成本降了七成，但技术投入其实转移到了边缘适配和后台弹性架构上。如果各位同行准备这么搞，记住一句话：别被厂商的“无缝对接”忽悠，真到了高并发盘点现场，拼的是你消息队列和离线策略够不够硬。
微信号：18581869297
