扫码即操作：Trier OS 如何把工厂工单流程压缩成「一拍一按」

你有没有见过这样的场景？

产线工人站在设备前，掏出手机——对准机器上的二维码，“滴”一声，工单自动弹出；
手指点一下，就开工；再点一下，就完工；点一下，转给下个班组；点一下，暂停并选个原因……
全程不用输文字、不翻菜单、不等加载——真·扫码即干。

这不是 Demo，也不是 POC（概念验证），而是已部署在真实工厂环境里的 Trier OS 3.4.0。

它不追求“能跑起来”，而专注一个更狠的问题：当网络断了、延迟飙到 2s、接口批量超时、设备离线一整天……它还敢不敢让工人继续干活？

团队做了两件事，硬核但朴实：
– 在内部用「混沌测试」轮番暴击 600+ 接口端点（模拟断网、丢包、随机超时、服务宕机）
– 拉着真实司机和现场运维，在 3000+ 终端节点 上反复“主动搞破坏”——不是测“它多稳”，而是测“它崩在哪、怎么救、能不能离线续命”

结果？工单状态本地缓存 + 离线操作队列 + 网络恢复后自动同步。哪怕手机飞进信号盲区，扫完照样点、点完照样记，回来连上就补传——工人不卡顿，系统不甩锅，数据不丢。

更关键的是，它没堆技术术语：
✅ 不需要装 App（是渐进式 Web 应用 PWA，扫码即用）
✅ 不绑定特定硬件（支持普通安卓/iOS 手机 + 市面常见扫码枪）
✅ 不强求 NFC（先用 QR 码跑通闭环，后续平滑升级）

开发者最关心的几个实战细节，也直接写在代码里了（摘自官方仓库 src/worker/sync-manager.ts）：

// 同步管理器：负责离线操作暂存与恢复上传
class SyncManager {
  private queue: SyncOperation[] = []; // 【注：所有待同步操作都存在内存+IndexedDB双备份】
  private isOnline = navigator.onLine;  // 【注：实时监听网络状态，非轮询】

  // 【注：用户点击“完成工单”时，不直连后端，先存本地队列】
  enqueue(operation: SyncOperation) {
    this.queue.push(operation);
    this.persistToIndexedDB(); // 【注：立刻落库，防页面意外关闭】
  }

  // 【注：网络恢复后自动触发，按顺序重试失败请求】
  async syncWhenOnline() {
    if (!this.isOnline || this.queue.length === 0) return;

    for (const op of this.queue) {
      try {
        await fetch(op.endpoint, { method: op.method, body: JSON.stringify(op.data) });
        this.removeFromQueue(op.id); // 【注：成功才移除，失败保留重试】
      } catch (err) {
        console.warn("Sync failed, will retry later:", op.id, err);
        break; // 【注：遇到第一个失败就停，避免雪崩；下次online再续】
      }
    }
  }
}

如果你也在做工业现场、物流调度、设备巡检这类「人+移动终端+物理设备」强耦合的系统：
– 你是否也让资产（机器/车辆/工位）直接挂 QR/NFC 标签？
– 你踩过哪些 PWA 在安卓老机型或微信内嵌浏览器里的坑？怎么绕开的？
– 你如何设计「离线优先」的交互逻辑，又不让前端变成状态黑洞？

欢迎去源码里看他们怎么用 200 行核心同步逻辑，扛住 3000 终端的真实压力——没有魔法，只有对「坏情况」的诚实预设和耐心打磨。

直达网址：https://github.com/DougTrier/trier-os