简介面向同城上门服务行业的运营级预约源码聚焦美容家政、足浴水疗、技师派单等场景适合具备PHP与uniapp基础、希望快速搭建多端预约平台的开发者。后端采用PHP前端基于uniapp实现前后端分离可发布为公众号、H5、小程序及APP源码全开源。压缩包共288个文件以168个vue页面、65个js逻辑为主辅以json配置、wxss样式、md说明及png、svg图标等整体仅764KB目录结构清晰适合直接对照二次开发。已有2692人学习可灵活应用于预约私教、瑜伽健身、美发美甲、理疗推拿、清洁保洁、维修安装、保姆月嫂等上门服务。源码完整包含前端页面、后端接口与多端适配配置涵盖预约管理、技师派单、服务分类、订单流转等核心模块目录按功能拆分有助于理解同城上门服务平台的业务闭环加速同类商业项目落地。1. 运营版上门预约小程序 APP一套同城服务派单系统到底值不值得做先说结论这个标题拆开看它不是一个小程序模板而是一整套「同城美容、家政、足浴、SPA 技师上门服务」的运营型系统。核心价值不在页面多好看而在派单逻辑、技师端接单、距离计算、结算分账和运营后台这些才是线上线下能跑通的关键。适合谁做有本地商家资源、想做平台撮合生意的开发者或者想私部署一套给自己门店用的服务商。我看过不少类似的模拟项目也实际参与过某公司内部的「某跨平台系统」开发。最大的误判就是把重心放在用户端下单界面结果真正跑起来商家、技师、用户三方互相找不到人订单指派靠人工打电话整个系统就废了一半。所以这篇文章不绕弯子直接给你拆解这套「仿东郊到家」模式的最小可行系统角色拆解、技术选型、核心派单流程、参数设置和最容易翻车的几个坑。新手照着能搭出一版可演示的熟手可以拿来做架构比对。2. 角色拆解和技术选型为什么这单生意必须分成四个端2.1 四个角色的职责边界这类同城上门预约系统最常见的错误是一开始就做成两个端用户端 后台。等真正上线就会发现技师没有独立接单入口、结算靠手动转账、订单状态靠电话同步运营工作量直接翻倍。我一般会遵循这个成熟的角色划分用户端小程序负责下单、支付、评价技师端 APP 负责抢单、接单、服务状态流转商家/门店管理端负责上架项目、设置服务范围、管理技师排班平台运营后台负责派单策略、分账结算、营销活动配置。四个端的数据模型是共通的核心表是技师表、服务项目表、订单表、结算明细表、优惠券表。技师和门店之间是多对一关系一个技师可以属于多个门店但结算归属必须靠门店维度去分。运营后台做财务统计时如果直接按技师汇总门店成本和平台抽成就容易对不上。2.2 技术栈选型小程序原生还是跨端框架用户端如果用微信小程序我习惯用原生加轻量状态管理不用重型框架。原因很简单预约类页面的核心交互是选择的组合——选服务、选技师、选时间、填地址这种表单型交互原生就很顺手。用跨端框架反而会在日历组件和时间选择器的兼容性上花额外精力。技师端 APP 则优先考虑跨端方案因为技师使用的手机型号差异大某跨平台系统用一套代码同时出 Android 和 iOS能省不少维护成本。地图组件是技师端的核心接单页要常驻地图显示用户位置和距离所以选框架时先确认地图插件在对应端上的稳定性这个要放在技术选型的第一优先级。后台管理端直接做 Web 管理界面技术栈用和主项目一致的语言生态。前后端分离API 统一走网关权限按角色区分。整个系统的架构边界要清晰用户端不直连数据库所有操作走后端接口技师端和后台可以走同一套业务 API只是返回字段和权限不同。2.3 后端服务拆分单体优先还是微服务这里不卖弄概念。初期业务量未起色做微服务纯粹给自己添乱。我给出的做法是单体应用起步按业务模块分目录。预约模块、派单模块、支付模块、结算模块先在一个工程里跑模块之间用接口隔离后续真要拆边界已经留好了。这样部署简单调试方便一台 2C4G 的机器就能扛住初期流量。等单量真正上来优先拆出来的是派单服务。因为派单的实时计算和订单状态更新是高频写操作其他模块读多写少拆出去后方便独立扩容。消息推送单独做一个服务对接极光或个推也行用微信订阅消息也行看运营需求。直播和视频这些重功能先不碰预约到店的业务不需要。3. 核心预约与派单流程从用户下单到技师上门3.1 用户端下单的数据模型与状态流转用户下单这条链路的字段设计决定了后期派单能不能自动化。我的做法是订单表除了基本字段必须冗余技师位置快照、用户位置快照、距离估算这些在派单计算时高频使用。实时问地理坐标接口会拖慢派单性能所以下单时取一次坐标存入订单表派单用快照算距离接单后再拉实时坐标更新。订单状态这个枚举看起来简单实际是踩坑重灾区。上门服务不比外卖技师到店后的状态需要人工确认。我常用这样一组状态待支付、待派单、已派单、技师已接单、技师已出发、服务中、待评价、已完成、已取消、退款中、已退款。这里有个容易忽略的点已派单和技师已接单是两个状态派单是系统指派完成接单是技师点击确认接收。如果合在一起超时未接单的自动流转就不好处理。// 订单状态流转核心代码简化版 // 状态机只允许合法跳转非法操作直接拒绝 public class OrderStatusMachine { // 合法状态迁移表当前状态 - 允许的下一步状态集合 private static final MapString, SetString TRANSITIONS new HashMap(); static { TRANSITIONS.put(待支付, new HashSet(Arrays.asList(待派单, 已取消))); TRANSITIONS.put(待派单, new HashSet(Arrays.asList(已派单, 已取消))); TRANSITIONS.put(已派单, new HashSet(Arrays.asList(技师已接单, 已取消))); TRANSITIONS.put(技师已接单, new HashSet(Arrays.asList(技师已出发, 已取消))); TRANSITIONS.put(技师已出发, new HashSet(Arrays.asList(服务中))); TRANSITIONS.put(服务中, new HashSet(Arrays.asList(待评价))); } public static boolean canChange(String from, String to) { SetString allowed TRANSITIONS.get(from); return allowed ! null allowed.contains(to); } }这段代码的核心是把状态流转规则收敛到一处而不是散落在各种业务方法里。这样定时任务查超时订单时可以直接判断哪些状态允许自动取消不会出现状态被改到中间态的问题。参数说明状态机用不可变集合初始化线程安全如果后续加退款状态只需要在这个表里加一条迁移规则。3.2 派单策略抢单还是指派派单是这类系统的灵魂。我见过两种派单模式各有适用场景。抢单模式适合供给侧充足的城市技师在线多用户下单后系统广播给附近技师先点先得。这种模式对系统压力小但技师体验容易崩——订单少的时候大家都抢订单多的时候距离远的技师也抢用户等待体验不稳定。指派模式是运营后台根据距离、评分、服务次数、当前负载自动分配最优技师。初期商家自有技师数量少指派模式更可控。我采用折中做法默认先走智能指派给排序第一的技师 30 秒接单窗口超时未接自动顺延给下一位。这样既有指派的可控性又有抢单的时效性。优先级排序的规则设置要可配置权重参数放在后台运营配置表里不需要改代码。常见的权重维度是这样配的距离权重 70%、评分权重 15%、忙闲系数 15%。忙闲系数是指当前待服务订单数越少的技师得分越高。如果用户在下单时指定了某个技师就直接跳过派单算法进入技师接单确认流程。# 派单算法核心逻辑Python 伪代码 def assign_technician(order, candidates): 根据距离、评分、忙闲系数计算综合得分 candidates: [{tech_id, lat, lng, rating, busy_count, service_cnt}] results [] for tech in candidates: # 距离得分越近分越高按公里计算超过5公里直接淘汰 distance haversine(order[lat], order[lng], tech[lat], tech[lng]) if distance 5.0: continue distance_score max(0, 100 - distance * 20) # 每公里扣20分 # 评分得分评分低于4.2的技师优先级降低 rating_score (tech[rating] - 4.0) * 100 # 4.0分时0分5.0分时100分 if tech[rating] 4.2: rating_score * 0.5 # 低评分技师的惩罚系数 # 忙闲得分当前在途订单越多分越低 busy_score max(0, 100 - tech[busy_count] * 30) # 综合得分权重可后台配置 total distance_score * 0.7 rating_score * 0.15 busy_score * 0.15 results.append((tech[tech_id], total)) results.sort(keylambda x: x[1], reverseTrue) return results我在演示版和实际项目里都用这个逻辑骨架。参数说明距离上限 5 公里、权重系数等是经验值纯一线验证。不同城市要调整一线城市用户密度高3 公里内就该有技师下沉市场覆盖范围得放到 8 公里。所以这套权重要做成运营后台可动态配置而不是写死在代码里。3.3 技师端接单与状态上报技师端 APP 的核心功能要克制常规做法是围绕订单状态流转来设计新订单提醒、接单/拒单按钮、开始服务、完成服务。不需要做复杂社交功能不需要积分商城。我见过有人把技师端做成了精美的营销页面结果功能够用但没有技师愿意装因为真正的核心诉求根本没被满足——清晰地告诉我去哪里、服务谁、赚多少钱。新订单推送到技师端后要展示的关键信息是服务项目、服务地址、距离预估、预计收入需要展示扣除平台抽成后技师实际拿到的钱。这一点是很多团队忽视的。技师接单的核心驱动力就是收入预期模糊不清就容易拒单拒单率高起来派单算法就会失灵。技师位置上报用定时上报加位置变更触发上报。定时频率设为 15 秒一次并在每次接到订单消息后主动上报一次实时坐标。这样做是为了保证派单时看到的技师位置足够新又不至于频繁请求导致耗电。这里有个优化点判断技师移动超过 100 米才上报省流量也省电。4. LBS 定位、支付回调与订阅消息三件套的配置和雷区4.1 腾讯位置服务的坐标体系和距离计算这部分涉及的第三方服务我尽量用通用说法不推具体厂商市面上也就那几家可选。距离计算必须清楚坐标体系小程序端拿到的坐标是国测局坐标也就是火星坐标系后端如果直接拿它和高德地图的数据做匹配会有几十到几百米偏差。市面上主流地图 SDK 都封装了坐标转换直接调用就行但如果自己写距离计算函数要先确认所有坐标已经统一到同一坐标系再算。距离计算用高德或腾讯的 Web API 也可以但业务量上来后接口调用量和费用都得考虑。我一般把距离计算放到后端自己做用球面距离公式快且免费。定位精度问题无法回避用户在室内下单GPS 信号弱定位会飘到隔壁楼。应对方案是允许用户在下单后手动修改位置或者在地址详情页提供地图选点功能这个必须做不做的话取消率会飙升。// 球面距离计算返回米 public static double calculateDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 Math.toRadians(lat1); double radLat2 Math.toRadians(lat2); double a radLat1 - radLat2; double b Math.toRadians(lng1) - Math.toRadians(lng2); double s 2 * Math.asin(Math.sqrt( Math.pow(Math.sin(a / 2), 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2) )); return s * 6378137; // 地球半径单位米 }这段代码是派单模块最底层的工具函数。参数说明6378137 米是赤道半径适用于中小范围距离计算跨城市距离计算直接调 API 更准确这个公式在近距离场景误差在可接受范围派单场景够用。4.2 微信支付回调的幂等处理预约服务往往是预付模式用户先付钱服务完技师端确认核销。这就涉及支付回调的可靠处理。支付回调最大的坑是重复通知。微信支付官方文档说明了回调可能多次推送如果后端不做幂等处理同一笔订单可能被加两次余额财务对账时直接对不上。我的做法是回调处理函数入口先查一遍订单当前状态已经标记为已支付的直接返回成功不再重复处理。同时把支付回调的日志和订单状态变更写入同一张流水表方便事后排查。支付金额以回调通知里的金额为准不信任前端传递的金额参数这是支付接口的基本安全底线。同一笔订单如果用户取消了再重新支付要生成新的订单号不能用同一个订单号去调支付接口。微信支付限制同一个商户订单号只能发起一次支付复用订单号会导致二次支付直接失败。4.3 订阅消息模板与触达策略上门服务的时间敏感性决定了消息触达要做分层。用户在用户端预约成功后需要收到服务提醒内容包括服务时间、服务地址、技师信息和项目信息。服务开始前 30 分钟再发一次提醒降低放鸽子率。技师端新订单推送则不能用订阅消息技师端用 APP 的话直接走厂商推送通道。用户端小程序的订阅消息一个用户只能主动授权接收有限次数的模板消息推送。所以每次推送都要珍惜额度只发重要节点消息支付成功、技师接单、技师出发、服务完成。次要是营销类消息不能占用订阅消息额度要用订阅消息里的长期模板或者短信通道去触达。这里有一个实战细节订阅消息的模板 ID 申请后每次下发要传用户端的页面路径最好直接定位到订单详情页。用户点击消息进入小程序后如果落到首页还得自己找订单跳出率会高很多。选用订阅消息模板时优先选带「订单状态变更提醒」类语义的模板这个字段才匹配预约场景。5. 运营版功能实地做厚分账结算、优惠券和 BI 看板5.1 分账结算平台抽成与技师提现运营版和演示版最大的区别在钱这块。演示版通常只做支付流程打通运营版必须处理分账、提现、对账三件事。平台和技师的结算模式我见过几种比例抽成模式最常见每笔订单平台抽取固定比例比如 15% 到 25%会员费模式适合高端 SPA 项目信息服务费模式常用于低频高客单。实操层面我建议用比例抽成配置灵活可按服务分类单独设费率。提现这块要克制。初期不建议做实时提现全部走 T1 结算。原因是技师提现涉及银行卡打款接口的调用每笔转账都有成本小额高频提现实在不划算。设置单笔最低提现金额 100 元单日最多提现一次降低打款手续费损耗。-- 技师日结算汇总 SQL用于后台定时任务 -- 每天凌晨计算昨日所有已完成订单的分成数据 SELECT t.technician_id, t.real_name, SUM(o.order_amount) AS total_amount, SUM(o.platform_fee) AS platform_income, SUM(o.technician_income) AS tech_income, COUNT(o.order_id) AS order_count FROM order o LEFT JOIN technician t ON o.technician_id t.technician_id WHERE o.status 已完成 AND o.completed_at DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND o.completed_at CURDATE() GROUP BY t.technician_id HAVING tech_income 0;这里我直接写 SQL因为结算这类批处理逻辑放在数据库层聚合比逐行算效率高。注意平台费率和技师实收金额要冗余到订单表里因为结算汇总必须用下单当时的费率快照不能用当前费率重算。如果改了分成比例历史订单用新费率结算财务就成糊涂账了。5.2 优惠券与首单立减拉新和控损的平衡运营版不能没有营销能力。上门预约类目的拉新核心动作就是首单立减和新客券。设计优惠券要控制的一个点是券的核销成本和订单收入能不能算清楚。很多模拟项目里优惠券只是个展示字段没有真正参与结算计算这在实际运营里行不通。优惠券的设计我会坚持以下原则优惠金额不能超过服务项目最低价的 50%否则技师到手金额被摊薄接单意愿下降。优惠券发放渠道要精确记录后续做 ROI 分析时需要知道哪个渠道带来多少核销率。核销时写清楚每一笔订单的明细商品金额、优惠券抵扣、平台抽成基数这些字段在对账时一一对上运营版才算合格。5.3 BI 数据看板的最小可用集不要一上来就做大屏可视化那对业务决策没实际帮助。需要的是运营每天要看到的核心指标。我用三张报表解决订单日趋势表按小时统计单量、完单率、取消率用来调整技师排班技师效率表统计每个技师接单量、平均服务时长、用户评价分数用来优化派单权重区域热力图用简单列表替代按小区统计订单密度用来做投放和排班参考。这类数据看板实现方式就是定时任务每天跑离线统计写入宽表。查询时直接查宽表不实时聚合。上线初期订单量有限实时聚合性能没问题但运营看历史趋势时聚合大表慢宽表一次到位后面不用返工。6. 避坑指南仿东郊到家模式最容易翻车的五个环节6.1 地图组件在部分机型上白屏我参与某跨平台系统开发时多次遇到这种情况用户端小程序正常技师端 APP 在部分低端安卓机型上地图区域白屏直接看不到位置信息。排查过程很折腾后来逐步定位发现是地图 SDK 和跨端框架的渲染层级冲突地图是原生控件嵌入 Web 容器时被遮罩层盖住。解决办法在跨端框架的配置里打开地图组件的原生渲染模式支持引入地图前做系统版本判断低版本系统回退到静态地址文本展示。后续重写技师端时我会先确认目标机型覆盖业务开发排在后面。6.2 订单自动取消导致客诉我一开始做超时未支付订单取消的设计时直接把超时定为 15 分钟。用户下单后去忙别的事回来发现订单没了只能重新下单体验很差。后来运营那边反馈取消率高的原因有一半是用户支付流程走到一半中断以为下单成功实际没有。解决在下单页显著提示订单有效期和支付时限用户进入支付流程但未完成时延长订单保留时间到 30 分钟超过期限推送一条提醒消息告知订单即将失效。这样既控制了无效订单堆积又照顾了正常用户。6.3 技师端接单后找不到用户地址从用户下单到技师出发位置信息冗余快照确实有了但技师实际要导航时用的是用户填写的详细地址文本。有些用户填地址时偷懒写了「小区门口」这种模糊信息。技师到了小区门口发现几期几栋都不清楚用户电话又打不通整个订单就僵住了。解决下单页的地址填写用地图选点代替手动输入选点后回填结构化地址包括小区名、楼栋号、门牌号技师接单后订单详情页一键调起导航地址直接传给导航应用。如果用户填写的地址是模糊关键词系统自动提示补充楼栋和门牌不补齐不让提交。6.4 技师同时接到了多个订单开放了抢单模式的系统最容易出现这个问题。技师手快同时抢了两单时间撞在一起只能鸽掉一个。用户端显示「技师已接单」实际被放鸽子客诉直接升级到平台。解决技师接单前系统检查技师当前待服务订单数量超过上限 1 单的直接不展示抢单按钮。这个是纯后端校验前端隐藏不可靠。新订单派给技师时同时校验当前在途订单的时间段是否冲突冲突则自动跳过。这个逻辑放到派单算法候选过滤阶段不额外增加接口调用。6.5 提现申请审核与打款状态不同步做提现功能时容易忽略的一个问题是后台审核通过后调用打款接口失败订单卡在「已审核待打款」状态。财务不知道要不要补打技师这边又显示提现中两边扯皮。解决打款流水表记录每一次调用的请求参数和返回码审核通过不等于打款成功打款结果要异步回调确认列表页对异常状态高亮提醒财务优先处理。这个模块宁可做得笨一点每一步状态变更留痕也不要让流程自动跑完就不管了。钱的事出一次错就够影响平台信誉。7. 秒级定位到派单调度高频场景的性能优化技巧单量上来之前这套系统的性能瓶颈不在数据库而在两个高频操作技师位置上报的写入频率和派单候选列表的实时计算。位置上报如果按 15 秒一次算100 个技师在线每秒产生接近 7 次写入这个量级对单库压力不大但要看上报日志表膨胀速度。教训是位置上报数据只在派单发生时有用过了 10 分钟就是垃圾数据季度级冷数据尽早归档。我习惯的做法是位置上报接口只写 Redis用过期时间自动清理。比如 key 设为tech:loc:{techId}过期时间 60 秒。派单时需要候补技师位置批量从 Redis 拉取比查 MySQL 快两个数量级。这样可以避免位置表无限膨胀连带着数据库备份也轻很多。# 技师位置缓存写入Python 伪代码 # 使用 Redis Hash 存储在线技师坐标单 key 过期 # ttl 设为 60 秒超过时间未上报位置自动视为离线 import redis r redis.Redis(hostlocalhost, port6379, db0) tech_id 10032 lat 39.9042 lng 116.4074 # 写入坐标同时设置过期时间 r.geoadd(tech_locations, lng, lat, tech_id) r.expire(tech_locations, 60)参数说明Redis geoadd 本身支持空间计算但更适合查询附近技师派单时如果并发量很大直接 geo 查询 权重排序计算放一起做要控制候选集数量控制在 20 个以内就够。再多算法耗时就上来了精度的提升已经不划算了。派单性能的另一个优化点是候选技师的过滤条件尽量前置。技术方式上是这样先过滤掉离线技师和忙闲超限的技师再算距离。如果在计算距离之后才过滤离线浪费的计算时间会随着在线技师数量线性增长。我见过一个翻车案例某个内部项目在 5000 个技师在线时一次派单计算耗时接近 1 秒原因就是过滤顺序反了。把条件前置后降到 30 毫秒派单体验完全不一样。最后提一个容易被忽略的排查技巧派单延迟时可以区分是算法慢还是推送慢。算法慢看函数耗时日志推送慢看推送服务的回执回调。很多情况是算法已经算好了消息推送到技师端的过程中出了问题。定位到具体瓶颈再优化而不是盲目买服务器升配置。这套系统的逻辑不复杂复杂度全在边界和各种异常分支把异常控制和状态流转做好系统就成功了大半。希望帮到你。本文还有配套的精品资源点击获取