别把 MES 标签打印做成一个按钮：从工单事件到可追溯打印任务

先给结论：打印不是一个动作，而是一条业务事件

很多 MES 项目把标签打印做成“传物料、数量、打印机，然后调用一次接口”。演示时很顺，到了产线就会遇到三类问题：网络超时后不知道是否已经出纸；工单切换时不知道用了哪个模板版本；操作员连点两次，序列号和箱码被重复占用。问题不在于打印机，而在于系统没有把“这次打印”当成可查询、可恢复的业务事件。

易打标公开页面列出了面向 C/S、B/S 场景的 API、SDK/OCX 与数据源集成能力。开发侧更值得优先定义的是边界：MES/ERP 负责提供可信的工单、物料、批次和数量；标签平台负责模板、条码规则和打印执行；对接层负责鉴权、幂等、状态与回写。这样标签规则不会散落在 MES 页面和多个客户端里，后续改版也不必改动每一个业务页面。

一个打印请求至少要带哪些信息

下面的 JSON 是对接层示意，不是易打标的正式接口参数。关键不在字段名称，而在每个请求都要有可追溯的业务身份、模板选择依据和可幂等的请求号。

POST /label-jobs {   "requestId": "MES-WO20260713-00018-PACK-01",   "source": "mes",   "businessNo": "WO20260713-00018",   "materialCode": "MAT-10086",   "lotNo": "LOT-0713-A",   "packageLevel": "carton",   "quantity": 24,   "printerGroup": "LINE-03",   "operator": "station-03" }

把幂等、版本和状态放在第一天

requestId 应从 MES 的报工、包装或入库事件派生，而不是让前端每次随机生成。服务收到相同 requestId 时，应返回第一次创建的任务结果，而不是再次分配流水号。标签模板也不能只保存“当前模板”：任务创建时要记录匹配到的 templateId、templateVersion、字段快照和规则快照。工程变更或客户标签更新后，系统才能解释某一箱货为什么在某个时间点使用那一版标签。

状态建议至少区分 CREATED、ACCEPTED、PRINTING、COMPLETED、FAILED、CANCELLED。这里的 FAILED 不是“业务失败”的同义词：打印机离线、纸张不足、字段校验未通过、模板被停用，恢复方式完全不同。MES 只在明确的状态变化后更新业务单据；不能因为 HTTP 已返回就默认标签已经打印成功。

产线架构不要让业务系统直连每台打印机

推荐把打印机放在站点服务或打印服务后面。MES 向统一对接层提交任务，对接层完成字段校验和模板匹配，打印服务负责把任务派到目标设备并记录执行结果。站点离线时，可暂存未完成任务；恢复后仍按 requestId 去重。这样换打印机、换端口或增加产线，不会迫使 ERP/MES 重新实现标签逻辑。

首个验证闭环不必一次覆盖整厂。选择一张高频箱标或产品标，跑通“工单取数 - 模板匹配 - 出纸 - 结果回写 - 失败重试 - 补打留痕”。验证项应包含断网、重复提交、模板停用、换线、打印机离线和作废后重打。能把这些异常讲清楚，比现场成功打一张样张更有价值。

常见问题

MES 已经有打印按钮，还需要标签服务吗？ 如果模板少、规则固定且只在单一工位使用，MES 内置能力可能足够。涉及多模板、条码规则、共享打印、版本和日志时，独立标签能力更易维护。

能否直接由前端调用打印？ 可以有前端触发，但业务身份、权限校验、流水号和最终状态应在服务端或受控服务中处理，不能只靠浏览器状态判断。

超时后到底要不要自动重试？ 先按 requestId 查询任务状态。只有确认任务未被接收或处于可重试状态时才重试，避免把“未知结果”直接变成重复打印。

模板变更会影响已经下发的工单吗？ 应由项目规则决定生效时间。已创建任务保留版本快照，待打印任务是否迁移到新模板需要明确审批或批量处理策略。

打印成功后必须回写 MES 吗？ 强监管或追溯要求较高的场景建议回写任务号、模板版本、打印时间和结果；是否阻塞业务单据，由现场流程决定。

如果正在评估 MES 或 ERP 的标签打印接口，建议先整理一张真实标签、对应工单字段和一次失败补打记录，再做字段与状态评审。易打标正式接口、部署方式和具体能力以项目资料与官网说明为准。