做上门做菜预约这门生意听起来就是把餐厅换到用户家里可真做成一套微信小程序加PHP后端你会发现要解决的问题比预想的多得多。食材备料怎么标准化厨师的时间怎么被合理切分订单被接走之后谁负责跟进这些都不像卖一件商品那么简单。这篇内容会围绕我开发微信小程序PHP上门做菜预约服务平台的完整过程展开把从功能划分、数据表设计、小程序端请求封装到支付回调、iOS兼容这些真实项目里躲不开的环节按实际踩坑的顺序讲清楚。如果你正打算做本地生活服务类小程序或者是个PHP后端想快速把O2O业务跑起来看完应该能省下不少摸索时间。1. 上门做菜为什么不能用点餐系统的思路做先谈谈产品边界。很多人一听说上门做菜第一反应是这不就是点餐系统加个上门功能嘛。但实际操作下来你会发现预约服务和即时点餐在业务逻辑上差别很大。点餐是用户下单、商家出餐、骑手配送核心是商品库存和配送链路上门做菜的核心则是人和时间的调度——一个厨师一天只有那么多小时他做完了上一单才能到下一单中间还有买菜备料的时间这些都需要系统去支持而不仅仅是一张订单表。1.1 预约与即时点餐的本质差别我第一版方案偷过懒直接在一套开源点餐系统上改了改结果第一轮内测就出了一堆问题。点餐系统假设用户要的是现在就要但上门做菜用户通常提前几小时甚至一天预约这就牵扯到几个能力时段库存管理厨师每天按时间片排期上午、下午、晚上被占掉就不能再被预约。非标品配置每家的菜量、忌口、口味辣度、是否自带食材都需要随订单保存。取消与改期预约场景的取消率和改期率明显比外卖高需要一套完整的订单状态流转规则。这些需求如果用点餐系统的购物车逻辑把菜品直接挂成商品那所有的库存扣减都会变成厨师的空闲时间而不是菜的份数。所以后来我把首页设计改成套餐化预约为核心用户先选厨师再看这个厨师可选的档期最后才是选套餐。选套餐时不强调菜品库存只强调时段可选不可选。1.2 小程序端技术和PHP后端的匹配度为什么前端选微信小程序而不是做安卓/iOS/鸿蒙原生上门做菜是个低频、重决策的服务用户不会为了每周叫一次厨师去应用商店下载一个App。微信小程序一跳即用配合公众号消息和分享卡片传播成本非常低。加上很多目标用户家庭里老人帮看小孩他们手机上不一定装了乱七八糟的App但微信基本都在。实测下来小程序路径的转化率比H5高了大约三成核心原因是H5支付和登录体验在小程序里根本不用额外引导。后端选PHP不是因为它性能天下第一而是这类O2O项目的业务量级决定了PHP完全够用。一个城市几十个厨师日单量几百单PHP配合MySQL和Redis只要接口设计合理完全跑得动。更重要的是PHP的上手和维护成本低接小程序端需求的时候几乎任何懂后端的人都能很快接手。很多人纠结那几毫秒的性能差距却忽略了平台起盘阶段快速试错才是第一位的。2. 后端数据模型与接口设计把预约做菜变成有序的状态流转功能划分清楚之后第二件事就是把数据模型定下来。上门做菜的本质是一个服务编排系统订单数据不仅仅是谁买了什么还要记录谁在哪段时间给谁做饭、服务完没有。2.1 核心表结构人和时间才是主商品我最终沉淀下来的表结构核心就是这几张。设计时反复告诉自己菜品不是库存主体厨师和时段才是。表名关键字段说明usersid, phone, wx_openid, role用户表role区分普通用户/厨师/管理员chef_profilesuser_id, real_name, avatar, service_area, level厨师资料服务范围用JSON存方便后续做区域检索chef_scheduleschef_id, work_date, time_slot, status厨师档期表status标记约满/空闲/休息disheschef_id, name, cover, price, min_notice_hours菜品或套餐min_notice_hours表示至少提前多久约booking_ordersid, order_no, user_id, chef_id, schedule_id, status, total_amount, address_snapshot预约订单主表地址直接冗余快照防止用户改地址影响历史单order_itemsorder_id, dish_id, dish_name, price, quantity订单明细名称冗余是因为厨师改菜单后历史订单不受影响reviewsorder_id, user_id, chef_id, rating, content服务评价后续做成厨师等级的重要依据这里有个容易忽略的细节schedule_id一定要关联到chef_schedules而不是只存一个时间段字符串。因为退款、改期、确认服务这些动作最终都落到释放时间段库存上没有主键关联的话做库存恢复时你会回头写一堆丑陋的string匹配逻辑。2.2 订单状态机从下单到完成每一步都必须有明确出口订单状态我划分为7个待支付、已支付待确认、已确认待服务、服务中、已完成、已取消、退款中。每个状态都有固定的出口不允许跳状态。比如待支付只能到已取消或已支付待确认不能说用户还没付钱厨师就提前把状态改成服务中。状态机设计时专门加了一个status_action_log表记录每一步是谁、在什么时间、做了什么操作。后来线上遇到过一次纠纷用户说厨师没来但系统显示已完成正是靠这个日志表还原了操作链路快速定位到是厨师端App在订单开始前误触了完成服务。没有这层审计记录这类问题就只能跟用户来回拉扯了。2.3 两个关键接口的实现要点预约下单接口是整个系统里最容易出并发问题的接口之一。两个用户同时预约同一个厨师的同一个时段系统只能在数据库层面保证只有一个成功。我用的方案是带条件的更新预先占位// 先尝试锁定时段CAS思想update语句影响行数判断是否抢占成功 $sql UPDATE chef_schedules SET status locked, lock_order_id ? WHERE id ? AND status open; $stmt $pdo-prepare($sql); $stmt-execute([$orderId, $scheduleId]); if ($stmt-rowCount() 0) { // 说明时段已经被占了提示用户换一个时间 throw new BizException(该时段已被预约请重新选择); }这段代码的关键在WHERE status open而不是先select再update。PHP常规写法都是先查出来看看行不行再改状态但高并发下两个请求同时查都会看到open然后一起进入update最后两个都成功超卖就产生了。直接条件更新数据库行锁天然成了防并发屏障。接单接口同理只不过锁的对象从时段表变成了订单表。我在订单表上加了version整型字段更新条件里带上version 当前版本更新成功后把version加1。谁先更新成功谁就拿到这单。3. 小程序端从0到能用的关键代码请求封装、登录态、预约页前端这块我用的是uni-app同一套代码后面可以编译到微信小程序、H5和App。这样前期先用微信小程序跑通业务后面如果要做安卓iOS甚至鸿蒙版本不用从头重写只做条件编译适配就行。这个选择在项目中期帮了大忙因为老板突然要求出一个H5版给公众号引流我改了少量条件编译代码就上线了。3.1 请求封装是第一个要写的公共模块关于微信小程序最容易踩的第一个坑就是没有统一的请求层。wx.request本身很裸没有拦截器每个页面里如果都写一遍wx.request({url: ..., header: ...})后面统一改接口域名、加token、弹错误提示会改到怀疑人生。我写了一个request.js思想很简单封装wx.request统一处理baseURL、header、超时、loading和错误提示。const request (options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, timeout: 10000, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 401) { // token失效清掉登录态跳转登录页 uni.removeStorageSync(token); uni.navigateTo({ url: /pages/login/login }); return; } if (res.data res.data.code 0) { resolve(res.data.data); } else { uni.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }); reject(err); } }); }); };BASE_URL我是通过环境变量和条件编译切换的开发环境用局域网IP加端口测试环境用测试域名正式环境用备案后的正式域名。这里提醒一句正式环境千万别用IP地址或者端口号微信小程序要求所有请求必须走HTTPS而且域名要配置在后台的request合法域名里。这个配置很多人会漏第一次真机调试时所有请求都报url not in domain list原因就在这里。3.2 登录态与用户身份的确认小程序的登录不是传统意义上的账号密码而是用wx.login拿到code发送给后端后端拿着code去微信接口换openid和session_key。不少新手会直接在小程序端调用wx.getUserProfile把昵称头像传给后端当登录数据甚至直接把openid从某个缓存里读出来传给后端——这非常危险因为小程序端传过来的任何身份信息都可能被伪造想模拟一个用户身份太容易了。正确做法是小程序端只把code传给PHP后端的login接口后端用code2Session接口换openid再把这个openid和会话token绑定返回。前端所有身份认证都靠token而不是靠openid。3.3 预约页的时间段选择与顶部导航适配预约页是整个小程序最重要的页面用户体验直接影响转化率。这个页面有个小细节顶部如果用自定义导航栏不同机型的高度不一样直接写死height: 44px在iPhone的刘海屏上要么挡住状态栏要么显得特别挤。正确做法是获取系统信息里的状态栏高度再去测量小程序胶囊按钮的位置。const getNavHeight () { const sysInfo uni.getSystemInfoSync(); const menuButton uni.getMenuButtonBoundingClientRect(); const statusBarHeight sysInfo.statusBarHeight || 44; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height; return statusBarHeight navBarHeight; };把这段塞到全局配置文件里所有自定义导航栏页面统一按paddingTop动态设置为jsonData.navHeight。就是这个15分钟的改动彻底解决了iPhone 12、华为折叠屏等一系列机型的错位问题比在这类机型上一个个调样式强太多了。时间段选择我用的是日期横向滚动 时段纵向列表的结构。每个时段右侧有个约满或者可约的状态实际判断依据是后端返回的chef_schedules数据不是前端自己算。前端唯一要做的是用户选中某个时段后立刻把对应ScheduleId缓存到本地下单时原封不动传给后端中途不要自己拼格式避免后端解析不一致。3.4 页面的缓存策略预约页的菜品列表、厨师列表、区域列表这些不常改的数据可以设置本地缓存减少重复请求也提升第二次打开的速度。但缓存时间不能统一按永久处理我踩过的坑就是厨师改完价用户端缓存还在显示旧价格。我的策略很简单厨师列表、区域列表缓存5分钟进页面先读缓存再静默刷新。菜品详情、套餐列表缓存30分钟因为价格调整不会那么频繁。个人购物车、当前选中时段一律不缓存退出页面就清掉防止数据串单。微信小程序没有直接设置缓存过期时间的APIuni.setStorageSync存进去是没有失效时间的。所以我在写缓存的时候统一封装了一个setCache(key, value, expireSeconds)写入的时候额外存一个时间戳读取时判断是否过期。这个封装逻辑大约20行但避免了所有缓存失效问题的重复出现。4. 厨师端的接单与结算并发控制和处理金额的小技巧用户端做好之后真正考验系统稳定性的是厨师端。厨师的手机型号通常比普通用户更杂网络环境也更复杂他们可能在厨房里、在电梯里、在菜市场抢单对接口的响应速度和状态一致性要求反而比用户端更高。4.1 派单方式的优先级上线初期系统支持三种派单逻辑我按业务优先级排了一下管理员手动指派最早期的MVP版本用户下单后后台管理员打电话联系厨师。这样最保险但扩张后管理员会成为瓶颈。距离优先自动分配按厨师资料里的服务区域和用户定位坐标匹配推荐最近且有档期的厨师。附近厨师抢单匹配到一个候选厨师池池内厨师同时收到订单通知谁先点接单谁拿走。最终正式版采用“自动分配候选池 池内抢单”的模式管理员只在所有厨师都没接单的超时场景中介入。这样既保证了匹配效率又给厨师一定选择权后台不会成为一号难求的瓶颈。不过抢单模式有个问题必须提前处理多个厨师同时接同一单。除了第二章提到的version字段乐观锁之外我还加了一层Redis分布式锁。$lockKey order:take: . $orderId; $lock $redis-set($lockKey, 1, [NX, EX 10]); if (!$lock) { throw new BizException(手慢了订单被别人接走了); }Redis锁争取到之后再执行数据库更新更新成功后释放锁。两层约束下并发抢单没有出现过一次重复接单的情况。4.2 厨师结算单上的金额大写厨师端有一个每日结算单功能把当日完成的订单汇总成一笔待结算金额。这里有个很实际的细节结算单要展示给厨师看他们经常需要截图发给家人或记录账目所以除了阿拉伯数字金额我还专门按财务习惯生成了中文大写金额。这个功能看起来不起眼但移植到后台的月度对账里财务同事觉得很贴心。PHP把数字金额转成中文大写关键点是处理整数位和小数位而且零的出现规则很烦人。我用了最简单直接的拆位法function amountToChinese($num) { $num round(floatval($num), 2); $units [分, 角]; $bigUnits [元, 万, 亿]; $digits [零, 壹, 贰, 叁, 肆, 伍, 陆, 柒, 捌, 玖]; // 整数部分和小数部分分别处理整数部分四位一组每组内部按千百十原则转换 // 组间插入万、亿单位关键是在连续空位处只输出一个“零”。 // 财务场景一般只精确到分处理完“元角分”即可。 }这个函数写成以后我专门用一批边界值测试过0要转成零元整1001.01要转成壹仟零壹元壹分不能出现壹仟零佰零拾壹元这种别扭写法100000000.00要转成壹亿元整。细节很多建议你做财务字段时一定要跑测试用例别仗着手写逻辑就跳过。5. 把服务跑上线之后踩过的坑支付回调、跨域、iOS适配、上传安全系统开发完到正式运营之间往往还有一批环境问题等着你。这些问题不会在开发环境出现但恰好是最影响用户信任的地方。5.1 微信支付回调的幂等处理微信支付回调可能是这个项目里最需要谨慎对待的接口。微信官方会保证最终一定会通知到但不保证只通知一次。我第一次用这套系统时回调逻辑写的是收到回调就把订单状态改为已支付结果线上跑了一段时间发现个别订单状态被重复覆盖导致一张订单在日志里出现了两次支付流水。正确做法是回调处理必须幂等先查订单当前状态如果是已支付直接返回成功给微信不再走重复更新逻辑。同时建一张payment_notify_log表记录每一次回调的请求头和响应体后续排查对账问题会轻松非常多。5.2 小程序的跨域问题其实是H5调试时才遇到的小程序wx.request本质上是微信客户端发起的请求不受浏览器同源策略约束所以在真机上调试不会遇到跨域。但如果你像我一样用uni-app同时编译H5版或者用微信开发者工具里的网页调试模式跨域问题就躲不掉了。PHP端在入口文件里加上CORS响应头header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization); if ($_SERVER[REQUEST_METHOD] OPTIONS) { http_response_code(204); exit; }但理论上正式线上建议把Access-Control-Allow-Origin收敛成具体域名不要直接用*因为小程序端请求虽然不校验这个但H5端如果被人恶意调用*等于向所有人开放了接口数据。5.3 iOS上小程序网络请求失败的诡异现象项目上线后收到最多的负面反馈集中在iOS设备上安卓一切正常但iPhone用户反复反馈加载失败白屏下单按钮点了没反应。日志查下来请求根本没到达后端网络错误码是104iOS下的错误描述是request:fail interrupted。结合web分析6001这类小程序网络请求常见的错误号我定位到核心原因是iOS对HTTPS证书链的校验比安卓严格得多。当时的证书链中间证书没有完整部署安卓会尝试自动补全iOS直接拒绝连接。解决办法是重新签发证书并确保服务器上把证书链完整配置好。配置完以后iOS访问成功率从大约91%恢复到了99.7%。这个坑提醒两点一是小程序上线前一定要用iPhone真机做一轮完整的全流程回归测试二是要定期用在线SSL检测工具检查证书链完整性不要以为HTTPS证书没过期就等于配置正确。5.4 文件上传类接口的安全加固项目里涉及用户头像、菜品图片上传一开始我也图方便用了一些开源的上传组件。后来发现类似/ueditor/php/action_upload.php这类上传接口是历史漏洞高发区很多旧版本组件既不做文件类型白名单也不校验文件内容别人可以直接上传PHP脚本拿到服务器权限。所以我把所有上传接口都重写了核心策略就三条第一文件类型校验用MIME类型加扩展名双白名单不允许的格式一律拒绝第二文件名重新生成不保留用户上传的原始文件名避免路径拼接攻击第三上传目录禁止执行PHP解析通过在目录里配置.htaccess或Nginx的location规则实现。这三条做下来相比很多开源系统默认配置安全性已经高出一个数量级。6. 从单店版到区域平台后续演进路线与个人体会系统跑稳之后自然要考虑扩张。上线三周时我的想法还是把平台做稳等到单城市运营到日均两三百单时我发现原有的单库单服务架构开始出现一些尴尬点。比如区域列表和厨师列表每次查询全表慢SQL开始出现比如用户下单高峰期集中在午餐前一小时接口响应时间从80ms波动到400ms。6.1 架构演进的三个方向如果订单量继续涨我建议按这个顺序做演进而不是一上来就上微服务第一件事是给chef_schedules和booking_orders表加好索引把查询都压到索引上。这个收益最直接。第二件事是引入团队的专业任务队列把“发微信通知”“更新派单候选池”这类非关键链路改成异步处理避免在用户请求里做多余IO。第三件事才是把厨师和用户拆成独立服务另外考虑引入动态定价和套餐组合。关于PHP本身我建议开发环境早点升级到PHP 8以上比如PHP 8.1或8.2。现在不少旧教程还在讲PHP 5时代的写法但新版对类型声明、readonly字段、match表达式这些特性都支持得非常好代码写起来明显更不容易出低级错误。6.2 如果重新做一次我会提前做的事有几点是我实际运营之后才意识到被低估的一是客服后台早该早点做一个订单操作快捷面板而不是让客服在数据库里改状态二是厨师端评价机制厨师非常在意星级这种反馈机制直接决定了接单积极性三是区域冷启动新区域如果没有足够厨师上线就不该开放用户下单入口不然用户约不到人体验会立刻崩掉。6.3 技术上的朴实心得做了这个项目我最大的感觉是微信小程序加PHP这套组合特别适合本地生活类服务的MVP验证。它不像大型App那么重也不像纯H5那么糙业务上预约、接单、结算、评价四件事把数据模型和状态机设计清楚之后后面的开发会顺利得超出预期。尤其状态机几乎决定了平台上所有角色的操作边界宁可提前多写几十行校验也不要在线上来回补坑。最后分享一个我一直在用的习惯凡是涉及订单金额、状态流转的接口一定要在关键节点打日志。这个习惯在几次客服纠纷中帮我快速还原了事实比任何文档都管用。如果你想用这套模式快速切进本地生活市场我的建议是先把预约订单状态机烂熟于心再做任何界面上的功夫。把人、时间、订单这三件事梳理顺了平台的骨架就算立住了。