分布式MES架构下的扫码终端抉择：自研App与“手机变扫码枪”小程序的实战思考
做工业软件尤其是MES系统快十二年了，我们团队交钥匙的分布式项目少说也有三十多个。最近不少客户在选型会上问同一个问题：车间里到底是用专门的手机扫码App，还是直接搞个微信小程序把手机当扫码枪使？这问题看似简单，真要在跨工厂、跨园区的分布式部署里落下去，里头门道比想象中深得多。
先说背景。现在的制造型企业，尤其是那些上了一定规模的，单一厂区中心式MES早就不够看了。我们给客户做规划时，基本默认是“集团云中心 边缘车间节点”的分布式骨架。数据要在边缘侧完成预处理，再和中心做双向同步。扫码作为车间最基础的采集动作，频次极高，环境却极差——金属屏蔽、网络波动、人员流动大，这些现实逼迫我们重新审视终端形态。
关于手机扫码App，我们一直坚持认为它是分布式架构里的“重装甲兵”。以我们去年交付的某新能源电池客户为例，他们在三地设厂，每个基地靠本地边缘服务器跑Kubernetes管理的MES微服务。工人手里的安卓App，底层嵌了优化的ZBar解码库，不仅能扫，还能在断网时把报工、配料数据落本地SQLite。等网络通了，通过MQTT协议向边缘节点补传。这种App我们一般用Flutter写，热更新方便，也便于推送新业务规则。在分布式里，App本质是边缘数据采集器，不依赖中心云实时在线，韧性极强。
但App有个软肋：分发和培训成本高。临时工、外来供应商根本不愿意装一个几十兆的企业应用。这时候，“手机当扫码枪”的小程序价值就出来了。我们给一家做汽车零部件的客户做二方物流收货时，就用了企业微信小程序。外来司机微信扫个码，手机摄像头瞬间变成扫码枪，调起我们后端的解析接口，直接完成送货单与MES物料码的绑定。小程序无需安装，权限随扫码场景动态下发，在分布式系统里它走的是中心API网关，适合轻量、低频、非核心的扫码动作。
不过得泼盆冷水。有些集成商把小程序吹成万能，我们实测下来，在纯离线车间里小程序基本瘫痪——微信本身断网就限制了调起相机后的后端校验。所以分布式部署中，我们明确划定边界：核心工序、需要离线缓存的，上App；访客级、依托现场稳定WiFi的，用手机当扫码枪小程序。两者通过统一的设备抽象层接入MES，后端用工厂编码做路由，不管是App来的MQTT报文还是小程序来的HTTPS请求，最终都进同一个分布式消息总线。
从ISA-95层级看，这两种终端都属于Level 0/1到Level 3的桥梁。我们在设计接口时，严格遵循工业互联网标识解析的二级节点规范，确保扫码得到的Ecode能跨工厂追溯。这里头有个细节：小程序的码解析往往依赖微信后台域名校验，部署时得在中心云配好合法回调域名，而App是我们自己域名直连边缘，运维侧要分开管控。在跨域专线不稳定时，App的本地队列长度可配置，而小程序只能依赖微信的TCP长连，这一硬伤目前无解。
坦白说，很多企业IT部门一开始迷信“小程序取代一切”，结果在西北某装备制造园区的项目里吃了大亏——车间钢结构屏蔽严重，小程序扫完传不上去，工人干瞪眼。后来我们补了一批定制化App终端，才把良率数据捡回来。所以作为软件系统方，我们的建议很明确：分布式MES不是炫技场，得让合适的终端干合适的活。
未来我们也在探索把小程序的核心解码逻辑wasm化，逐步弥补离线短板，但现阶段，App与手机当扫码枪小程序在分布式中的互补格局不会变。如果你正规划跨厂区MES，欢迎来聊，咱们拿实际产线说话。
微信号：18581869297
