最近在做一个面向中小制造企业的生产管理系统代号「轻排 PMClite」。做到现在有一些架构层面的思考记录一下供有类似需求的同学参考。文章不谈具体实现细节主要聊技术选型的逻辑和踩过的坑。一、轻排 PMClite 是什么先给结论轻排 PMClite 是一款面向中小制造企业的本地部署、买断制、轻量级生产管理系统。它的目标场景很具体10-200 人的中小制造工厂销售、采购、仓库各一份 Excel数据永远对不上多级 BOM 用 VLOOKUP 拼改一个料号公式全乱缺料要等到开工才发现排产靠资深 PMC 人脑这个人一休假就乱轻排 PMClite 的核心定位是替代中小工厂里多份 Excel 各管一块的低效协作方式聚焦 PMC生产计划与物料控制最痛的几件事多级 BOM、齐套检查、排产、领料、追溯。它不做全流程 ERP只解决上面这几个具体问题。二、技术选型的逻辑轻排 PMClite 的技术栈是层级选型桌面框架Tauri 2.x后端语言Rust数据库SQLite SQLCipher前端原生 HTML/CSS/JS多机通信局域网 UDP HTTP为什么选 Tauri 而不是 Electron这是轻排 PMClite 最早做的一个决定。对比维度TauriElectron安装包~30MB~150MB内存~60MB~200MB渲染系统 WebView内置 Chromium后端RustNode.js面向工厂的软件装完不占资源、启动快比什么都重要。工厂电脑很多是几年前的老机器150MB 的包体加上 200MB 内存会直接影响体验。为什么不用 MySQL用户是工厂不是互联网公司。没人愿意为了一套管理软件再装数据库、配用户权限、定期备份。SQLite 单文件丢进应用目录就跑这是轻排 PMClite 最合适的存储方案。选择 SQLCipherSQLite 的加密分支而不是明文 SQLite是因为轻排 PMClite 的用户明确要求数据不能外流。为什么不用云轻排 PMClite 从一开始就确定了本地部署的路线。原因用户明确表示不信任公有云工厂网络条件参差不齐云端延迟不可控客户名单、成本价这类数据老板不想放在别人服务器上这不是技术问题是产品定位问题。轻排 PMClite 的目标用户就是不想上云那一批人。三、局域网多机同步的思路这是轻排 PMClite 做得最费劲的部分。用户不想上云但多台电脑要看到同一份数据。3.1 架构选择常见的多机同步方案有三种中心服务器—— 需要单独一台机器做服务端云同步—— 数据经第三方中转去中心化—— 每台电脑都能发现彼此轻排 PMClite 选了去中心化发现 主机-客户端模型局域网内所有节点通过 UDP 广播自动发现彼此一台电脑作为主机负责存储数据其他电脑作为客户端定时从主机拉取不需要单独买服务器也不需要任何云服务。3.2 节点发现轻排 PMClite 用 UDP 广播做节点发现每台机器定时向局域网广播自己的信息主机名、IP、角色同时监听广播维护一份附近设备列表超时未响应的节点自动移除踩坑UDP 广播在部分企业网络环境下会被路由器拦截。轻排 PMClite 目前依赖的是办公 WiFi 或交换机直连这个前提。3.3 数据传输主机启动一个轻量 HTTP 服务tiny_http暴露三个接口接口用途/api/info返回主机版本信息/api/snapshot返回全量数据快照/api/push接收客户端的增量推送为什么用tiny_http而不是axum/actix-web轻排 PMClite 只有一个 web 服务线程没必要引入异步框架。tiny_http足够简单编译后体积也小。踩坑CORS 必须显式处理。Tauri 的 WebView 发起 fetch 时会带 Origin 头服务端要返回Access-Control-Allow-Origin。3.4 增量同步全量传输显然不行——5 万行数据一次传几十 MB。轻排 PMClite 的做法是前端算差异、后端应用差异前端维护一份上次保存时的快照保存时对比当前数据与快照生成差异列表新增、修改、删除差异列表通过 IPC 发送到 Rust 后端后端在一个事务里应用所有变化设计取舍不追求极致性能优先保证数据一致性。目前已知的优化点是差异计算本身还可以加速但 5 万行以内体验完全可接受。四、几个具体的坑4.1 Tauri IPC 的类型陷阱轻排 PMClite 开发过程中遇到最隐蔽的一个 bug 是 Tauri IPC 的类型问题Rust 端某个命令参数是OptionString前端传了一个数字类型的 idserde 反序列化报错invalid type: integer, expected a string而这个错误被 Promise 的catch吞掉了表现为命令静默失败教训轻排 PMClite 后来统一约定了所有 id 相关字段前端传参前必须转字符串。4.2 手写签名的性能问题轻排 PMClite 的领料单支持手写电子签名可选功能。最初实现有个性能问题每次鼠标移动都调canvas.toDataURL()生成 base641600×400 的 canvas 上单次 10-20ms鼠标每 16ms 触发一次直接卡成幻灯片修正只在抬手时生成一次并改用 JPEG 格式。收益手写流畅签名体积降到原来的三分之一。4.3 批量操作的事务问题轻排 PMClite 的领料单一次可能涉及几十个物料。最初的实现里每个物料更新都会触发一次完整保存50 个物料 50 次差异计算 50 次 IPC 保存耗时约 10 秒修正给更新库存这个操作加了延迟保存参数循环内不保存循环外统一保存一次。效果10 秒降到 0.5 秒。4.4 数据备份轻排 PMClite 的备份不用文件拷贝会锁库、可能损坏用的是 SQLite 的VACUUM INTO原子操作生成的备份文件同样是加密的不需要停服务踩坑目标文件必须不存在否则报错。所以要先检查路径。五、一些设计原则做轻排 PMClite 这一年总结了几个原则原则一不做全流程 ERP大型 ERP 有 60% 的功能中小工厂根本用不上。轻排 PMClite 只解决 PMC 最痛的几件事——多级 BOM、齐套检查、排产、领料、追溯。其他模块比如总账、报税、HR一律不做。原则二数据安全优先轻排 PMClite 的用户画像里不相信云是很核心的一条。所以数据全部本地存储数据库加密不依赖任何第三方服务断网照常用原则三开箱即用工厂老板没有耐心等三个月实施。轻排 PMClite 的目标是下载、安装、3 分钟上手——不装数据库、不配服务器、不培训。原则四买断制SaaS 的订阅模式对中小工厂不友好——他们宁可为一次性投入也不愿意每年付续费。轻排 PMClite 从第一天就是买断制。六、目前还没解决的问题诚实地列一下轻排 PMClite 已知的优化点差异计算的全表扫描5 万行数据下每次保存约 300ms可以优化数据库连接每次重开每个命令约 20-50ms 开销可以缓存审计日志队列的 flush 时机目前是去抖机制极端情况下可能丢日志同步接口的认证目前依赖局域网内这个前提将来可能加共享密钥本地图片上传目前只支持在线 URL本地图片要考虑多机同步、备份、路径失效等一堆问题这些问题都不影响轻排 PMClite 的基本可用性但会在数据量增长或场景复杂后暴露。七、小结轻排 PMClite 的技术选型核心思路是用最小依赖解决最核心问题。不用 Electron因为 30MB vs 150MB 差太多不用 MySQL因为工厂不愿装数据库不用云因为轻排 PMClite 的目标用户明确不要不用异步框架因为单进程场景不需要不做全流程 ERP因为 60% 功能用不上这套方案不追求技术先进性追求的是在中小工厂这个具体场景下用最少的运维成本解决最痛的问题。轻排 PMClite 目前提供 30 天免费试用支持中文、English、Tiếng Việt、ไทย、Bahasa Indonesia、Español、Português 七种语言。如果对轻排 PMClite 的技术方案或产品定位有讨论兴趣欢迎交流。