1. 项目定位与整体设计思路做私厨服务系统最开始要解决的问题不是“怎么做”而是“这个系统到底服务谁、服务什么场景”。很多人一上来就照着外卖平台抄把菜品、购物车、订单、骑手配送全做一遍结果发现私厨和外卖完全是两套逻辑。外卖的核心是“标准化商品即时配送”而私厨的核心是“人预约信任”菜品只是信任建立之后的载体。我做这套基于Node.js的私厨服务系统核心口径是私厨不是卖菜的是卖时间和手艺的。用户下单买的不只是那道菜而是某个厨师在某个时间段里专门为他服务的确定性。所以整个系统围绕三条链路设计找厨师、约时间、履约。至于菜品的标准化程度、配送方式都排在后面。基于这个定位系统拆成几个核心域用户域食客和厨师都用同一套账号体系、厨师店铺域私厨的个人主页、可接单时段、菜品菜单、预约履约域档期锁定、订单状态流转、取消和退款、以及交易域下单、支付回调、分账。整体架构采用前后端分离服务端用Node.js Express搭建RESTful接口数据存储用MySQL做主库、Redis做热点缓存和临时状态前端用Vue做用户端和管理后台。选择Node.js不是因为“时髦”而是私厨这类业务的核心特征是长连接通知多、状态流转频繁、异步任务不少Node.js的事件循环模型在处理这类I/O密集场景时确实顺手前后端同用JavaScript也让沟通成本低不少。2. 数据库建模与核心模块拆解2.1 双角色账号体系与厨师入驻审核私厨系统里最常见的坑是“用户”和“厨师”各自建一套表后面越维护越乱。我的做法是一张user表用role字段区分食客和厨师厨师入驻时额外维护一份chef_profile记录真实姓名、厨龄、擅长菜系、健康证照片、短视频简介、服务价格和可服务区域。之所以这样拆分是因为很多用户既是食客也想在某天成为厨师单一账号体系能平滑支持这个转变。厨师入驻不能只靠前端传几个字段必须走审核流程。chef_profile里增加audit_status字段枚举为pending、approved、rejected。管理员在后台审核时需要查看健康证图片和厨艺视频审核通过后才允许厨师设置“可接单时段”。这个流程一开始我不够重视后来发现如果让新厨师直接上架菜单会导致菜品质量参差不齐食客差评最后全算在平台头上。2.2 菜单、菜品规格与价格策略私厨的菜单不能照搬外卖的“商品SPU/SKU”模型。外卖的SKU是“口味规格”私厨的SKU应该是“份量服务形式”。我设计了dish表和dish_spec表dish记录菜名、图片、描述、所属菜系dish_spec记录规格名称、价格、份量、是否支持打包、是否支持上门服务。举个例子同样是“红烧肉”可以在家吃选“小份堂食”也可以请厨师上门做“六人份家宴”这两者的成本结构和定价逻辑完全不一样拆成spec后预约单才能准确计算金额。价格策略这块我推荐私厨用“基础价 服务费”的展示方式而不是直接叠加到菜品单价里。因为食客对“菜价贵”很敏感但对“服务费”有心理预期。系统在订单确认页会清晰展示菜品金额、食材代购费、上门服务费、平台服务费这样既能保障厨师收益也能降低食客的比价焦虑。2.3 厨师可接单时段与档期锁定这是私厨系统区别于外卖系统的关键表。chef_schedule记录厨师在某一天的某个时间段是否可以接单比如“周六 10:00-14:00 可承接家宴”。真正下单时系统会先把选中的时段写入pending_order同时对该时段加锁避免两个食客同时抢到同一个厨师的同一个档期。实现档期锁定时需要注意不能只对整点时段做锁定因为私厨服务往往跨时段比如“16:00-19:00”做一顿晚餐。我采用“时段离散化”方案把一天按半小时切分为48个slot一个预约单占用多个连续slot写入schedule_lock表时检查这些slot是否全部空闲全部空闲才允许插入。这样既支持灵活的起止时间又能精准防冲突。3. 服务端关键实现与业务代码剖析3.1 预约下单的时段检查与订单生成下单接口是系统最核心的接口不能简单往订单表插一条数据就返回成功。完整流程是前端提交厨师ID、菜品spec列表、服务日期和时段后端先校验参数再开启Redis分布式锁锁的key设计为chef:schedule:{chefId}:{date}:{slotIndex}然后逐个slot尝试写入。如果发现某个slot已经被占用立即回滚已写入的锁返回“该时段已被预约”的提示。锁通过后生成订单号。订单号不要用自增ID太容易暴露业务量也不方便做多机唯一标识。我采用“时间戳 随机数 厨师ID后四位”的方式组合既保证唯一性又能在日志里快速定位到具体厨师。订单初始状态为pending_payment同时创建一个未支付订单定时任务15分钟后如果未支付自动释放已锁定的slot。代码层面有一个容易踩的坑Redis锁的过期时间不能设置太短否则业务还没处理完锁就过期了另一个请求就能抢到同一时段。我一般是把过期时间设为10秒并加上一个value作为锁标识释放锁时用Lua脚本判断value是否一致防止误删别人后来获取的锁。在业务执行完成时主动释放锁不要让锁依赖过期时间兜底。3.2 订单状态机设计与状态流转私厨订单的状态比普通电商复杂因为涉及“预约”和“履约”两个阶段。我把订单状态定义为待支付、待确认、已确认、服务中、待评价、已完成、已取消、已退款。厨师后台可以对“待确认”订单进行接受或拒绝接受后订单变为“已确认”此时才真正锁定厨师的档期拒绝后自动释放档期并向食客全额退款。状态机的好处是让所有状态迁移都在一处集中管理避免业务代码里到处乱改状态。我在服务端维护了一张状态流转表只有合法迁移才允许执行。比如“待支付”只能迁移到“已取消”或“待确认”“已确认”不能直接跳到“已完成”必须先经过“服务中”。这在后续做数据统计时非常有用能够准确计算每个环节的转化率到底卡在哪一步。3.3 支付回调与异步通知支付环节我接入的是主流第三方支付后端只处理异步回调。回调接口设计的要点是先去重后改单。因为支付平台在网络异常时会重复推送回调如果每收到一次回调就更新一次订单状态容易出现幂等破绽。我的做法是回调接口内部先查订单当前状态如果已经是“已支付”或“已确认”直接返回成功不再重复处理。支付成功之后还需要处理几个联动动作通知厨师“新订单待确认”、通知食客“支付成功等待厨师确认”、如果订单关联了食材代购还要生成一条采购任务。通知方式我采用了WebSocket推送配合站内消息表兜底。WebSocket负责实时提醒消息表负责离线补推两者配合能保证信息不丢。4. 应用场景、二次扩展与常见问题排查4.1 典型应用场景分析这个系统最典型的使用场景是家庭聚餐和好友聚会。用户搜索附近的私厨厨师查看厨师的拿手菜和可约时段下单后厨师按时上门自带食材或在平台代购食材现场制作。整个过程的关键不是“菜品多不多”而是“这个厨师靠不靠谱”。所以系统里必须把厨师的评分、历史服务次数、食客评价这些信息放在菜单信息之前的显眼位置。另一个场景是企业团建和小型商务接待。这种场景有几个特点一次性下单人数多、菜品需求量明确、对时间和场地要求高。系统为这类需求增加了“宴会预约”入口厨师可以批量设置不同标准的套餐比如“10人标准、3888元”下单后自动生成一份食材清单方便厨师提前备货。还有一些衍生场景是私厨培训。部分厨师的业务不局限于做饭还提供“私厨教学”服务比如教食客做三道家常菜按小时收费。我在chef_profile里预留了service_type字段扩展出cook_training类型这样不需要改动核心订单模型就能支撑新的增值服务。4.2 高频问题的排查方法与避坑实录问题一订单支付成功但厨师没收到通知。排除网络因素后最常见的原因是WebSocket连接因服务器重启而断开前端没有自动重连。解决方法是建立心跳检测机制前端每隔30秒发送心跳包后端在60秒内没有收到心跳就主动断开连接前端触发重连同时所有通知落库用户刷新页面后通过“未读消息”接口补拉保证不遗漏。问题二同一个厨师的时段被并发下单抢到。出现这个问题的原因多半是Redis锁没有设置在最外层或者锁的粒度太大比如锁了整个厨师全天导致明明不同时段却互相阻塞。正确做法是按半小时slot加锁并且抢锁的顺序要一致防止死锁。建议在开发环境直接用两个并发请求压测下单接口能快速暴露这类问题。问题三退款不及时导致客诉。退款必须做成异步补偿机制不能只依赖主流程里的退款操作。我在订单表里增加refund_status字段配合一个定时任务扫描“已取消但未退款”的订单自动发起退款并记录退款流水号。这样即便退款接口临时故障后续扫描也能补上不会漏掉。问题四菜品图片加载慢。私厨菜品图片通常比外卖图片更大而且厨师上传的图片质量参差不齐。建议在服务端做图片压缩和格式转换统一转为WebP格式并根据不同展示位裁剪三种尺寸列表缩略图、详情大图、分享卡片图。Redis缓存图片访问链接的映射关系避免每次请求都去查数据库。问题五订单价格算错。这往往是多规格菜品在数量改动时没有重新计算总额导致的。我的建议是金额计算统一在后端完成前端展示的金额只做参考。后端把菜品基础价、服务费、食材代购费、平台服务费每一项单独存字段数据库记录每一项金额后续对账时逐项审计而不是只存一个总额。5. 部署上线与运营数据观察部署架构我采用了比较务实的方案单台云服务器运行Node.js服务MySQL和Redis各自独立部署前端静态资源走对象存储加CDN。为什么不用复杂的微服务和容器编排因为私厨类业务初期用户量有限复杂架构只会拖慢迭代速度。先保证核心流程稳定等日订单量明显增长时再按需拆服务、加负载均衡这是成本最低的做法。上线后需要重点观察的指标有三个一是厨师确认订单的平均时长这个指标如果过长说明厨师端通知触达有问题直接影响食客体验二是未支付订单比例如果比例过高可能是价格展示不清晰或支付流程太繁琐三是取消率集中在哪个环节取消最多就说明那个环节的信任感没有建立起来。有一次我发现某个厨师的取消率异常高排查后是因为他的菜品图片和实际差距太大食客上门后失望而取消后续把图片审核规则收紧取消率立刻回落。运营数据里还有一个容易被忽视的点时段占用率。通过分析不同日期、不同时段被预约的频率可以引导厨师更多地开放热门时段。比如周末晚间的时段占用率长期超过90%而工作日下午几乎为零系统可以在厨师端展示“热门时段建议”让厨师动态调整自己的可接单时间平台整体供给效率也会随之提升。我在实际项目中的体会是私厨服务系统最难的永远不是技术而是业务逻辑的合理建模。把“档期”当作和“菜品”同等重要的资源来设计是这套系统最大的价值所在。另外有一点要提醒后来者数据结构设计时尽量把金额和状态字段拆细宁可多几个字段也尽量不要用复合状态因为后期每一个运营报表都可能让你重新改表拆得越细改造成本越低。