桌面应用
🏦 场景与客户
一家做定制家具的制造企业，设计部与生产车间之间靠文件传递。设计师在电脑上出图，导出 PDF 后发到群里，车间再下载打印。版本一多就乱：车间拿到的可能是三天前的图纸，改过的尺寸没人通知。
客户要的是一台装在工位电脑上的桌面程序：能直接读写本机文件、能调打印机、断网也能用，图纸版本与流转状态在本地可见，联网后自动同步。浏览器方案满足不了，因为需要访问本地文件系统与打印设备。
📅 实施节奏
- 第 1–2 周：梳理车间与设计部的实际流转路径，确定最小功能集
- 第 3–6 周：开发桌面端主体：文件监听、图纸列表、状态标记、打印
- 第 7 周：在两台工位机与一台设计机上试用，观察真实操作步数
- 第 8 周起：分批下发安装包，配套自动更新与版本回滚机制
🗝️ 方案要点
- 本地优先：核心操作全部走本地，断网时仍可打开图纸、打印、标记状态，联网后做增量同步与冲突提示
- 文件系统能力是选它的理由：可以直接监听设计稿目录，文件一落地就进列表，不需要人工上传
- 打印走系统能力：调用操作系统的打印接口，图纸尺寸、纸张、打印机选择交给用户，程序只负责送文件
- 自动更新要能回滚：新版本出问题必须能一键退回上一版，不能让车间停线等修
- 多版本兼容：工厂电脑系统版本参差，安装包需要覆盖较老的操作系统版本，且不依赖最新的运行时
- 安装包体积控制：内网分发虽有带宽，但安装包体积直接影响装机效率，把非必需依赖全部剥离
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 技术路线 | 桌面客户端而非浏览器 | 能读写本地文件、调打印；代价是每个工位都要装，升级与运维比网页麻烦 |
| 数据存储 | 本地库 + 服务端同步 | 断网可用；代价是冲突处理复杂，需要明确的「以谁为准」规则 |
| 更新策略 | 静默下载、提示重启 | 不打断工作；代价是版本收敛慢，得倒逼用户重启才能整齐 |
| 系统支持范围 | 覆盖旧版本系统 | 装机无障碍；代价是不能用新框架的新特性，开发效率受影响 |
🚧 实施难点与排查
- 杀毒软件误报：安装包首次下发被企业杀软拦下，整批装机失败。做了代码签名并与企业 IT 报备后解决
- 打印机型号各异：有的打印机驱动不支持程序调用的接口，打印直接无响应。改为优先走系统默认打印对话框，把选择权交回用户
- 文件监听漏事件：大文件写入过程中就触发了事件，读到的是半截文件。改为等文件稳定（大小不再变化）后再入库
- 同步冲突丢版本：设计部与车间同时改了状态，后写覆盖先写。改为字段级合并并保留冲突记录，由人决定
💵 成本与收益
- 成本结构：开发一次性投入 + 装机与培训 + 内网分发与服务器（成本很低）
- 收益侧：车间拿到旧图纸的情况基本消失，图纸流转从「靠喊」变成「靠状态」；沟通成本下降比省打印纸重要得多
- 省钱的关键：自动更新做扎实，能省掉日后大量上门重装的人力
🛡️ 风险与保障
- 可用性：断网可用的设计本身就是最大的保障，核心流程不依赖云端
- 回滚：保留最近两个版本的安装包与降级入口，新版出问题可当天退回
- 安全：程序只访问指定目录，不越权读取其他文件；上传内容加密传输
- 兼容：发布前在工厂实际的几类机型与系统版本上做过装机验证，不只在开发机测试
♾️ 可复用与演进
- 这套「本地文件监听 + 状态流转 + 打印」的结构可以复用到其他需要车间协同的制造场景
- 演进方向：把图纸版本与生产排程关联，车间看到的不只是图纸，还有它的排产顺序
- 再往后：接入设备端的扫码或工位屏，把开工与完工记录也纳入同一条流转链路
