一、问题定义：上云之后，打印被拴在网络上
一个典型的现场：标签模板集中到云端管理，版本、审批、分发都在云上完成。某天夜班换线，正好撞上网络维护窗口，操作员在 Print Portal 点下打印，标签机没有响应------模板在云端，链路不通，现场停在那里。
这类评审会上被问的问题几乎固定：断网怎么办。提问者通常不是 IT，而是对停线时间负责的生产主管。
二、架构：管理面与执行面分离
标签业务天然有两套节奏。管理节奏关心版本与一致性：谁改了模板、哪一版生效、哪个站点还在用旧版；执行节奏关心即时性：这台机、这卷纸、这一批要出 3000 张，现在就要。
云适合前者（集中、可追溯、跨站点一致），现场适合后者（低延迟、不依赖外网、故障可现场处置）。
BarTender 12 引入的 Hybrid Labeling（混合标签）走的是拆开而不是二选一的路：云负责扩展规模与协作，控制权留在现场。
三、12.1 补上的两块机制
按官方 12.1 发布说明：
- Librarian 云地同步。Librarian 是 BarTender 的集中内容库，模板与文档可在 Cloud 与地端环境之间同步，让分布式团队、不同站点使用的标签数据保持一致。同时，云端打印机列表开始纳入地端打印机并按实例分组------云端看得见车间那台机，而不只是云端直连的几台。
- Offline Mode（离线模式） 。官方表述为：当现场遇到连接问题时，Offline Mode 有助于维持打印作业继续运行；启用后，Print Portal 与 Print Station 可以从本地缓存读取文件，让操作员以尽量少的中断（minimal disruption）继续打印。
两者的组合语义是：设计端改一次，多个站点同时生效；现场用哪台打印机出标签，仍由现场决定；网断时，已缓存的内容照常出纸。
四、能力边界：缓存不是本地重设计
"本地缓存"是已同步内容的本地副本，不是本地重新设计。三句话把边界说清：
- 断网期间能打的，是已经缓存到本地的模板；
- 断网期间在云端新改的模板，不会凭空出现在现场；
- 哪些模板、哪台打印机需要预热缓存，是实施阶段逐项确认的工作，不是开关一拨就自动成立。
把边界写进实施方案，比事后向操作员解释"为什么这张打不出来"成本低得多。
五、适用与不适用
| 场景 | 是否适合混合标签 | 要点 |
|---|---|---|
| 多工厂、多站点 | 适合 | 总部统一发布，各厂本地出纸，版本不再各自为政 |
| 外部供应商与代工厂 | 适合 | 开账号、表单打印，不必外发模板文件 |
| 新建厂房、弱网车间 | 适合 | 网络未稳，产线不能等 IT |
| 有审计要求的行业 | 适合 | 版本可追溯，同时保留现场连续打印 |
| 单机、单站点、模板少变更 | 不适合 | 复杂度大于收益，单机版更划算 |
六、上线前的四项确认
- 本地落点：现场的 Windows 主机、Print Gateway 与 Print Portal 装在哪台机器，开机自启与故障恢复由谁负责；
- 缓存预热：哪些模板、哪些打印机预先缓存，缓存更新的验证动作由谁执行；
- 版本策略：谁能发布、发布后多久同步到各站点、断网期间是否允许改模板；
- 断网演练：拔网线实测，覆盖补打流程与打印记录核对。文档写的"尽量少的中断"，演练过才知道在自己现场是几分钟。
组件名称与系统要求以官方文档为准，实际范围需结合现场环境评估。
七、小结
标签系统云化的难点，从来不是把模板搬上去，而是让生产主管相信：网不好的时候，线还转得动。BarTender 混合标签给出的路径是把管理面与执行面拆开------云端负责让所有人用同一版内容，本地缓存与 Offline Mode 负责让现场在网最差的情况下还能出标签。这套组合在具体现场成立与否，取决于上面四项确认的结果。