开源社区有个数据挺有意思：GitHub上「POS系统」标签的仓库，80%要么五年没更新，要么直接是某家公司的商业代码泄露。真正从零开始、用2024年技术栈重写的，屈指可数。
开发者Ahmed Ali属于后者。他用React、SurrealDB和Docker搭了一套餐厅收银系统，最近把代码全扔上了GitHub。项目不大，但技术选型很敢——没选PostgreSQL或MongoDB，押注了一个国内开发者相对陌生的名字：SurrealDB。
为什么不用传统关系型数据库？
Ahmed的原话是：「Most Point of Sale systems are either bloated enterprise software or outdated legacy apps.」他见过太多收银系统，要么是SAP级别的臃肿怪物，要么是Windows XP时代苟延残喘的VB程序。
SurrealDB的多模型特性（multi-model）让他省了不少事。同一张表既能当文档数据库用，也能直接跑图查询，订单、库存、员工权限的关系不用跨表JOIN。WebSocket层是原生的，订单状态变更能实时推到所有终端——这对餐厅场景很关键，后厨出菜、前台结账、店长看报表，三方数据不能有时间差。
前端用了React+Tailwind CSS，没选Ant Design这类重型组件库。持久化状态用Jotai管，配合自定义Hook处理移动端离线场景。整套UI的打包体积控制在200KB以内，老旧平板也能流畅跑。
Docker组网：预期3天，实际3周
容器化部署是项目的卖点之一，但Ahmed在博客里坦承：「The biggest challenge was definitely the infrastructure networking.」
具体卡在哪？Docker bridge网络的DNS解析在跨容器场景下表现不稳定，SurrealDB的WebSocket连接频繁断连。他花了大量时间调试，最后发现是Nginx反向代理的SSL配置和WebSocket升级头冲突——这个问题在本地开发环境完全复现不了，只有用真实域名+HTTPS证书才会暴露。
另一个坑是Docker Compose的db-init profiles。SurrealDB启动时需要初始化schema，但容器健康检查机制没等初始化完成就标记为「就绪」，导致应用层连上去直接报错。Ahmed的解决方案是写了一个自定义的wait-for脚本，但这违背了Docker官方「一个容器一个进程」的哲学，属于无奈妥协。
「Container-first」的承诺兑现了，代价是手动维护了一套Nginx/Caddy配置模板，生产环境还得自己扛SSL证书轮换。
SurrealDB的赌注：赢在哪，输在哪
选SurrealDB而不是PostgreSQL+PostgREST，Ahmed的核心诉求是减少技术栈层级。传统方案需要：数据库→ORM→REST API→前端状态管理→WebSocket推送（可选）。他的方案压缩成：SurrealDB→前端直接连WebSocket→Jotai同步状态。
链路短了，调试也简单了。但代价是生态成熟度——SurrealDB的Node.js客户端在GitHub只有1.2k star，遇到边缘问题基本得自己读源码。Ahmed提到一个细节：移动端Safari对WebSocket的节流策略比Chrome激进得多，他不得不给心跳包间隔做了平台差异化配置。
项目开源后，GitHub Issues里最常见的反馈不是功能请求，而是「怎么部署到VPS」。Ahmed的README写了Docker Compose一键启动，但读者发现：没有域名、没有SSL证书、没有反向代理经验，根本跑不起来。这暴露了一个尴尬现实——「modern stack」的现代化是有门槛的，中小餐厅的IT能力未必接得住。
代码之外：一个收银系统的真实成本
我翻了下项目的commit记录，从first commit到v1.0.0标签，跨度11周，共847次提交。单看代码量不算大，但Ahmed的工时分布很典型：40%写业务逻辑，35%调基础设施，25%处理边缘case（离线同步、数据冲突、权限粒度）。
他没有选Electron做桌面端，而是直接用了PWA。这个决策省了大量打包体积，但也意味着放弃了打印机原生驱动——餐厅后厨的小票机、标签机，最终要靠CUPS（通用Unix打印系统）中转，配置复杂度转移到了运维侧。
开源协议是MIT，商用免费。但Ahmed在README底部加了一行小字：「Production deployments are not officially supported.」翻译成人话：代码给你，出事别找我。
这套系统能替代Square Toast或客如云吗？短期看很难。连锁餐饮要的从来不是技术先进，而是合规、售后、和银行通道的对接资质。Ahmed的项目更适合单店或小型连锁，老板懂点Linux、愿意自己扛运维的那种。
GitHub仓库的star数刚过300，但Watch列表里有几个ID值得关注——两个是SurrealDB官方工程师，一个是某连锁披萨品牌的Tech Lead。后者在Issue #17下面留了一条评论，问有没有计划支持多门店数据隔离。Ahmed回复说：「Not on the roadmap, but PRs welcome.」
这个交互本身或许比代码更有信息量：一个个人项目，正在被动地承接真实商业场景的需求。它会不会从「练手作品」滑向「准商业产品」，取决于Ahmed愿不愿意接下那个PR——以及，他还有没有下一个3个月可以投入。
热门跟贴