面单号有了，打印机没动：云打印对接的真实故障现场
电子面单开放平台与云打印组件，把「出单成功」和「打印成功」拆成两段。授权、模板、任务队列与幂等重打，决定大促现场吵不吵。
事故复盘纪要（节选）：11:20 出单接口返回成功；11:21 仓库反馈空白纸；11:35 发现云打印组件未登录；11:48 模板仍指向停用的三联规格；12:10 有人手动重打，部分平台提示重复取号。损失不是接口宕机，是状态机以为世界已经结束。
所以打单中台要有两段生命周期：取号/出单，打印任务。前者对平台，后者对现场。少了后者，再漂亮的电子面单 API 也只服务了开发者控制台。
对象可以少，但不能糊
- 授权：店铺/承运商，到期提醒
- 账户：面单余额与预警
- 模板 ↔ 打印机规格
- 出单请求与单号回写
- 打印任务：成功 / 失败 / 重试中
幂等比「再点一次」文明
现场最爱的补救是连点。系统要用业务键保证：同一包裹在规则允许下重打，不在不允许时重复扣费取号。具体以各开放平台规则为准，适配器里写清楚，别靠口头「应该没事」。
快递飞接尾程打单时，会把打印失败工单与大促队列一并进首期——因为客户看不见你的 API 成功率，只看得见桌面上那一摞空白热敏纸。
常见问题
为什么出单成功还会打不出来？
出单拿到单号/面单数据后，还要经过云打印组件、打印机驱动、模板与纸张规格。任一步失败都应有打印任务状态，而不是业务单显示成功就结束。
对接开放平台首期盯什么？
店铺授权与过期、面单余额、模板绑定、异步出单回写、失败码可读、重打幂等（按平台规则避免重复扣单）。
大促怎么验收？
队列化、限流重试、失败进工单；现场能看到「哪单卡在打印」，而不是让仓库狂刷浏览器。
所属专题
列表筛选「尾程与打单」 · 列表筛选「对接与运营」 · 列表筛选「交付与选型」