Raktim94/nodedr-restaurant-pos

如果你经营小餐厅，想把点单、桌台和厨房显示放在自己的硬件上，这个项目值得一看；但别急着向员工承诺全部功能，路线图里还有不少模块标着未完成。

解决什么问题

晚餐高峰时，餐厅最怕点单、打单和厨房小票同时出问题。使用云端 POS 时，一旦宽带断了，这三件事只能靠手写纸条和计算器临时顶替。OrderRestro 把 Postgres、API 和 Web 前端整套放在店内局域网的同一台机器上，收银台和厨房屏通过本机地址访问，跑起来之后不需要互联网。变化不是界面层面的：点单不再绕到公网，打印也不依赖外网连接。

有什么不同

它按堂食流程设计，没有把餐厅当成多摆几张桌子的零售店。项目包含可视化平面图、按档口分流的厨房显示、扫码点餐、预订和候位，以及面向印度的 UPI 二维码结账：收银屏和顾客屏显示与账单金额一致的二维码，不经过支付网关，也就不产生网关手续费。员工考勤、工资和按工时分配的小费池也在同一套系统里，管理员不必再把多个账号和导出表拼在一起。税务可按印度 GST、美国销售税、欧盟 VAT 等区域配置。

代价在于它宣称的规模。README 列出了 20 个模块的范围，并逐项标注状态：核心 POS、桌台、厨房显示、菜单、库存、采购、CRM 和工资标为完成，而分账和拆分支付方式尚未完成。原生支付网关收单、外卖平台与会计软件对接、称重秤、标签打印机、SQLite 版本和原生安装包都列为未建。也就是说，它比一堆拼起来的脚本更成体系，但今天还替代不了成熟商业 POS 的每一项功能。

部署方式同样是设计的一部分。推荐在店内一台机器上执行 docker compose up，也支持 CasaOS/ZimaOS 一键应用；Windows 收银机可以安装一个 WinForms + WebView2 的轻量客户端，指向服务器地址，而不是开浏览器标签页。由于所有服务都在一台服务器上，这台机器和局域网就成了业务连续性的关键点，员工需要理解这一点；README 没有给出故障切换方案。

谁值得试

适合已经有店内服务器或小型主机、且身边有人会用 Docker、看得懂日志的独立餐厅、咖啡馆或小型连锁。离线运行和 UPI 二维码结账在印度尤其实际：按笔支付网关手续费和断网时无法结账，都是反复出现的成本。

如果门店现在就需要分账或拆分支付方式，需要在柜台称重，或者指望开箱即用的外卖平台和会计软件对接，那它暂时不合适，路线图也写明这些尚在计划中。只有一台收银机、又没有技术人员可依靠的小店，也可能觉得本地服务器模式比托管 POS 更费心，尽管 CasaOS 一键应用已经降低了自托管门槛。

使用条件与边界

按 README 徽章，需要 Docker Compose v2 和 Node 22 以上，安装脚本会负责构建。Web 界面在主机 1995 端口，后端 API 和 Swagger 文档只能通过 Web 应用的 /api 代理访问，外部系统不能直接调用接口。Windows 上的安装步骤要在 WSL2 或 Git Bash 里执行，因为安装脚本是 shell 脚本。之后的升级是 git pull 后重跑安装脚本，会重新构建镜像并重启整套服务；服务器、Postgres 数据卷和局域网地址都成了你需要自己照看的东西，而不是供应商的责任。

AGPL-3.0 许可证会影响你修改代码后把它作为网络服务提供给别人的场景：那些用户必须能拿到你修改后的源码。餐厅自己内部使用一般不受影响，但打算基于它做托管服务的人要注意。报表可导出 Excel、PDF 和 CSV，定时邮件通过你自己的 SMTP 服务器发送，所以这项可选功能确实依赖互联网。

HotRepo 点评

该项目在 2026-10-27 首次出现在追踪的每日榜单上，当天 174 星、+35 星，这是它 85 天里的唯一一条记录。这只是快照，不是趋势，仅凭一次榜单记录无法判断热度能否持续。决定采用前，请对照路线图检查你实际用到的模块，尤其是分账和外卖平台对接，并确认门店的打印和档口分流方式已被覆盖。