简介一款面向上门服务行业的运营版预约小程序源码包后端基于PHP开发前端采用uniapp完成前后端分离可一键打包发布到公众号、H5、小程序及APP。资源覆盖美容美发、家政保洁、足浴推拿、私教健身、维修安装等预约场景核心逻辑仿照东郊到家模式含技师派单、订单管理、会员营销等模块适合想快速搭建本地生活服务平台的开发者或创业者二次学习使用。包内共288个文件以168个vue组件页面、65个JavaScript逻辑文件为主辅以JSON配置、WXSS样式及说明文档整体压缩后约764KB结构紧凑便于按模块拆解研究。目前已有2688人学习下载既能用于理解完整前后端交互流程也可作为同城预约类小程序从0到上线的项目参考。 很多第一次接触“运营版上门预约小程序源码”的人都会误以为它只是一套“用户下单 技师接单”的商城模板。真上手一周就会发现同城美容、家政、足浴、SPA 这类上门服务平台的复杂度几乎全藏在页面下面派单规则、状态流转、结算分账、地图定位每一块都能把人折腾到怀疑人生。这类号称“仿东郊到家源码”的项目本质上是一套同城 LBS 派单 O2O 上门服务的完整解决方案不是简单几张页面就能撑起来的。这篇内容我结合自己实际做类似系统交付的经验把从产品模型到源码落地的完整链路拆一遍重点讲那些“源码里看得到但没人给你解释”的设计逻辑。想自建平台做同城轻资产生意的人或者要给客户交付这类系统的开发团队都可以拿它当落地参考。1. 产品模型拆解平台到底在撮合什么上门预约平台看起来是“卖服务”但从系统设计的角度看它其实是在做三件事让用户找到确定性让技师拿到效率和收入让运营者拥有调度和风控能力。把这三件事想清楚后面所有功能设计和表结构才有依据。1.1 用户端要的不是“下单”而是“确定性”用户打开小程序诉求非常具体现在或者某个明确时间在自己所在的位置能约到需要的服务。这个“确定性”决定了前端不能只做一个漂亮的技师列表。比如一个足浴技师今晚排班已经满了首页就不该继续推荐她一位美容师只服务女性用户男性用户点进来就应该看到她被过滤掉技师当前不在服务范围内详情页就不该展示“立即预约”按钮。我建议预约流程按这个顺序设计浏览服务分类 → 选择服务项目 → 查看可约技师列表按距离、评分、价格排序→ 选择上门时间段与地址 → 在线支付 → 等待系统派单/技师接单 → 技师上门 → 服务完成 → 评价。每一步都要围绕“可约”来做约束。服务项目还必须和技师技能做关联绑定否则就会出现用户看到的技师什么项目都接真到了现场却说不会做的尴尬情况。用户在预约前看不到技师是否是“空闲状态”也是差评的重灾区所以用户端技师列表要实时反映“在线可约”状态这种状态数据要靠技师端的上线/下线开关来驱动。1.2 技师端关心的是接单效率与收入透明技师端很多时候就是一个单独的小程序但它的重要性一点不比用户端低。技师最在意三件事今天几点在哪一单、这一单能挣多少、钱什么时候能提现。所以技师端的功能基本围绕日程、接单和钱包来做服务状态开关上线/下线、今日日程列表、新订单通知、接单/拒单、开始服务/完成服务、收入明细、提现申请。这里有一个容易被忽略的点接单时的“价格快照”。技师接到订单那一刻界面必须明确展示这单的服务项目、时长、预计收入别让技师接了单再回头问客服“这单怎么才这么多钱”。收入明细要能对得上每一单显示用户实付、平台佣金、技师到手这样技师才会信任平台。结算和提现模块可以做在技师端最显眼的位置因为对技师来说“挣多少钱”就是这款产品最重要的价值。1.3 运营端真正要做的是调度、审核与风控运营后台才是整条业务线的中枢。常规功能包括门店/商家管理、技师入驻审核身份证、健康证、技能资质、服务类目与价格配置、城市与商圈划分、订单监控与人工干预、优惠券和会员体系、投诉处理、财务结算。风控在运营后台里尤其不能省。日常最容易出现的问题就是技师绕过平台私下接单所以后台要对订单完成后的沟通行为保留记录对线下交易投诉做出处理。还有一类问题是恶意差评和骚扰投诉后台需要给用户提供“一键投诉技师”的入口同时给技师提供申诉通道。运营后台的权限也要分角色财务、客服、运营、超管各管一摊避免一个账号看到全部数据。2. 技术架构与表结构多端复用的实现路径2.1 主流源码技术组合我接触到的运营版上门预约源码大多数是这么搭的后端用 PHP 系框架ThinkPHP、Laravel 比较常见用户端和技师端用 uni-app 做跨端一套代码同时编译微信小程序、H5、Android/iOS APP运营后台独立做一个 Vue 或 Layui 管理界面。这个组合不算“高级”但胜在成本可控PHP 部署门槛低一套源码交付给客户以后客户随便找个外包都能维护。如果预算允许后端上 Java 或 Go 会更稳但对同城平台早期的业务量来说PHP 完全够用。uni-app 的代价是涉及到原生能力的地方比如地图定位、音视频通话、推送还是要做条件编译和原生插件。我的建议是如果平台定位是“小程序优先”可以坚持 uni-app如果后续确定重点做 APP反而可以把 APP 端用原生或 Flutter 单独做因为上门服务里技师和用户之间的位置共享、即时通讯体验在原生端明显优于跨端壳。但大多数刚起步的团队还是先跑通 uni-app 更实际。2.2 用户端和技师端必须拆开用户端小程序和技师端小程序绝不能合在一个项目里这一点要单独强调。合在一起会带来三个问题一是微信审核过不了容易被判断为“多角色混合”而要求说明还可能面临类目问题二是用户路径混乱小程序主体定位不明确平台要让用户看服务要让技师看订单一个小程序根本装不下两套完全不同的信息架构三是从业务隔离角度技师端一旦出错会直接影响用户端发版进度。所以哪怕代码可以复用发布时也一定要分成两个小程序主体、两个 APP 包后台角色和数据权限再分别控制。2.3 核心表结构参考源码拿到手之后先看表结构比先看页面更重要。一张能支撑运营的订单表至少要有这些字段订单号、用户 ID、技师 ID、门店 ID、服务项目 ID、服务开始时间、服务地址经纬度和文本、预约状态、支付状态、订单金额、优惠金额、实付金额、技师佣金、平台佣金、下单时间、支付时间、完成时间、取消原因。如果一张 orders 表里连经纬度都没有说明它只是个纯商城下单系统不是完整的同城派单系统。下面是一个简化版订单表结构可以直接对照你手里的源码来判断功能完整性CREATE TABLE order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, user_id int NOT NULL COMMENT 用户ID, technician_id int DEFAULT NULL COMMENT 技师ID, store_id int DEFAULT NULL COMMENT 门店ID, service_id int NOT NULL COMMENT 服务项目ID, service_time datetime NOT NULL COMMENT 预约上门时间, address varchar(255) NOT NULL COMMENT 服务地址, lng decimal(10,6) NOT NULL COMMENT 经度(GCJ-02), lat decimal(10,6) NOT NULL COMMENT 纬度(GCJ-02), status tinyint NOT NULL DEFAULT 0 COMMENT 订单状态, pay_status tinyint NOT NULL DEFAULT 0 COMMENT 支付状态, total_amount decimal(10,2) NOT NULL COMMENT 原价, coupon_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, commission decimal(10,2) DEFAULT 0.00 COMMENT 平台佣金, settle_amount decimal(10,2) DEFAULT 0.00 COMMENT 技师结算金额, create_time datetime NOT NULL, pay_time datetime DEFAULT NULL, finish_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_technician_time (technician_id,service_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;看到这种字段基本说明这个源码的设计者考虑过 LBS 派单之后的完整链路可以往下继续看派单逻辑。3. 同城派单引擎LBS匹配与防并发调度3.1 技师可达范围的圈选逻辑同城派单的核心不是“全城抢单”而是先按地理位置圈一个候选集合。做法通常是用户下单时拿到服务地址的经纬度服务端以这个点为中心、按一定半径比如 5 公里筛选技师。半径圈选可以用 MySQL 的 Haversine 公式直接算也可以先按经纬度做矩形粗筛再精确计算距离减少计算量。SELECT * FROM technician WHERE lat BETWEEN ?-0.05 AND ?0.05 AND lng BETWEEN ?-0.05 AND ?0.05 AND status 1业务规模上去之后再接 Redis GEO 或 Elasticsearch 也不迟。这里有个细节值得注意不同地图的坐标系不一样。微信小程序里用腾讯位置服务拿到的是 GCJ-02火星坐标如果服务端存的坐标来自高德或百度不能直接拿来算距离需要统一转换。否则就会出现“系统判定技师在 2 公里内实际距离 5 公里”这种问题。圈选技师时除了距离还要叠加几个过滤条件技师在线状态、服务项目匹配、预约时间是否与技师已有订单冲突、服务地址是否在技师的服务范围部分技师只接固定区域、评分和拒单率权重。这些条件搞清楚了派单引擎才算有了骨架。3.2 抢单、派单、值班三种模式的取舍模式适合阶段优点缺点抢单技师多、供给充足平台省心技师积极性高单量波动时没人抢热门单抢不到派单/自动匹配平台强控制、口碑期分配合理体验可控对调度算法要求高值班/排班固定门店、固定时段服务时间稳定临时需求响应慢实际运营中很少只用一种模式。常见组合是普通订单走自动匹配优先派给距离近、评分高、拒单率低的技师同时给技师几秒确认时间不接就自动流转到下一位部分高价值订单或体验单走手动派单由运营人员指定指定技师忙时开放抢单闲时走派单。源码里如果只有“抢单”没有“派单”运营成本会很高。3.3 并发冲突与超时无人接单的兜底抢单场景最容易出现两个技师同一时间点了同一个订单。处理方式是状态机加乐观锁接单接口用一条带条件的 UPDATE 把订单状态从“待接单假设 status1”改成“已接单status2”影响行数为 0 就说明被别人抢了返回“手慢了”。UPDATE order SET technician_id ?, status 2, accept_time NOW() WHERE id ? AND status 1这种写法比先查再更新更稳妥也不会给数据库加锁造成性能问题。同时要做好超时兜底用户支付后如果 60 秒内没有技师接单系统自动扩大匹配半径再超时就通知运营人工干预或者给用户发送“暂无人接单可取消全额退款”的提醒。千万别让订单无限期挂在那儿用户等太久就会流失。4. 订单状态机与结算资金流设计4.1 一套能兜住所有异常的状态流转上门预约订单不是简单的“下单到完成”中间有很多分支。推荐的状态集合是这样的状态含义触发方待支付用户已提交但没付款用户待接单已支付等待技师确认系统已接单技师已接单准备上门技师服务中技师已开始服务技师待评价服务完成等待评价技师已完成用户已评价或超过评价期系统已取消未支付自动取消/用户取消用户/系统已退款取消后资金已原路退回系统/财务每次状态变化都要留操作日志。这里特别容易踩坑退款状态和订单状态不联动。比如用户发起了退款财务在后台点击“同意退款”订单状态却还是“服务中”技师照常上门最后的体验肯定一团糟。所以我的建议是状态变更逻辑写成服务层统一方法任何入口改状态都必须经过同一套校验不要出现前端改造了一个状态、服务端逻辑没跟上的情况。4.2 金额拆分与技师结算逻辑订单金额模型建议这样用户实付 服务项目原价 − 优惠券金额 上门费技师结算 用户实付 ×1 − 平台佣金比例再扣除可能的平台技术服务费。举例一个 SPA 项目原价 199 元用户有 20 元优惠券实付 179 元平台佣金 20%那么技师到手就是 179 × 0.8 143.2 元平台收入 35.8 元。这个账必须在订单完成那一刻就生成结算快照存入结算表而不是等提现时再算。结算时机一般是 T1 生成可提现余额。也就是说当天完成的订单第二天凌晨结算到技师钱包的“可提现余额”技师发起提现后进入“提现中”财务审核打款后变为“已提现”。每一笔钱都有迹可循。源码里如果技师余额只写在技师主表的一个字段里没有独立的资金流水表后期对账会非常痛苦建议尽早补上。4.3 退款与售后场景的状态联动退款不是把“已支付”改回“未支付”就完事背后要处理三件事三方支付渠道退款、订单状态回退、技师结算金额扣回。如果技师已经完成这单并且已经结算用户再申请售后系统需要生成一条负数结算记录从技师可提现余额里扣除而不是直接改历史流水。这些联动逻辑是判断一套源码是否“运营级”的试金石。我见过最典型的 bug 是用户取消订单后原路退款成功了但订单表里没有标记“已退款”导致技师端仍然显示该订单可接单或者技师完成订单后订单进入“待评价”但结算流水没有生成提现时少了一笔。这些都不是功能复杂度的问题而是状态机和资金流没有形成闭环。拿到源码第一件事就是把“状态流转”和“金额变化”两张图先对着代码在脑子里走一遍能走通后面运营才省心。5. 源码落地最容易翻车的几处细节5.1 定位坐标系与小程序合法域名上门预约系统绕不开定位。小程序端使用地图相关能力需要在腾讯位置服务申请 key不同端小程序、Android、iOSkey 要分开申请别混用。发布之前还要在微信公众平台把 request 合法域名、uploadFile 合法域名都配好否则真机调试时接口全被拦截。我第一次交付时就吃过这个亏本地工具一切正常手机一扫码全部请求失败最后排查了一个小时发现只是合法域名没配。坐标系问题同样恼人。服务端如果用的是高德或百度的坐标前端用腾讯地图展示中间不做坐标转换技师导航会偏。统一规则是前端展示用 GCJ-02服务端存储也用 GCJ-02所有第三方坐标都转到火星坐标之后再入库。建议源码里单独放一个坐标转换工具类不要在业务代码里到处写转换逻辑。5.2 支付资质与类目过审上线不是只把代码跑起来还有一大堆资质问题。微信支付商户号的主体必须和小程序主体一致如果不一致联调时经常碰到“商户号与 AppID 不匹配”的错误。上门服务这类平台在微信小程序类目审核上也有要求涉及美容、健康类服务部分类目需要营业执照和特定资质有的还可能需要门店环境照片。我的经验是先把类目、商户号、支付回调地址全部确定下来再动联调不然代码写得再完整也发布不出去。关于“仿东郊到家源码”这种命名它只是说明业务模式参考了同城上门预约产品交付给客户时一定要让对方留意当地对生活服务平台的监管要求确保平台里上线的服务项目合法合规。5.3 部署环境、权限隔离与数据备份部署环节看起来不复杂但容易在环境版本上翻车。PHP 项目要注意 PHP 版本和扩展比如 Redis 扩展、fileinfo 扩展、MySQL 版本、伪静态配置小程序后端要求 HTTPSSSL 证书要提前准备。运营后台一定要做角色权限至少拆成超管、运营、财务、客服四级财务只能看结算和提现客服只能看订单和用户信息避免一个账号权限过大。数据备份不是可选项。数据库至少每天自动备份一次提现表、订单表、结算表要重点保护。我建议上线第一周每天都检查一次备份是否成功很多备份任务配置了但没执行等数据丢失时才发现就晚了。隐私合规方面用户手机号授权、位置定位、个人信息收集都需要在隐私协议里写清楚微信小程序也要求在后台配置“用户隐私保护指引”这些动作要在提审前完成。我个人做了几个类似项目之后最深的感受是上门预约平台的开发难点从来不在 UI而在所有“看不见的逻辑”是否闭环。派单、状态、结算、LBS任何一个环节偷懒最后都是运营端和客服来背锅。写这篇内容也是一个提醒源码只是起点把状态流转和账目算清楚系统才算真正“运营级”。如果你正在评估一套类似的源码建议先拿这篇里的表结构和状态清单去对照能对上的越多后面交付越省心。如果有实际项目里遇到的问题也欢迎在评论区交流踩过的坑本身就是最好的经验。本文还有配套的精品资源点击获取
上门预约小程序源码拆解：LBS派单、订单状态机与结算逻辑
简介一款面向上门服务行业的运营版预约小程序源码包后端基于PHP开发前端采用uniapp完成前后端分离可一键打包发布到公众号、H5、小程序及APP。资源覆盖美容美发、家政保洁、足浴推拿、私教健身、维修安装等预约场景核心逻辑仿照东郊到家模式含技师派单、订单管理、会员营销等模块适合想快速搭建本地生活服务平台的开发者或创业者二次学习使用。包内共288个文件以168个vue组件页面、65个JavaScript逻辑文件为主辅以JSON配置、WXSS样式及说明文档整体压缩后约764KB结构紧凑便于按模块拆解研究。目前已有2688人学习下载既能用于理解完整前后端交互流程也可作为同城预约类小程序从0到上线的项目参考。 很多第一次接触“运营版上门预约小程序源码”的人都会误以为它只是一套“用户下单 技师接单”的商城模板。真上手一周就会发现同城美容、家政、足浴、SPA 这类上门服务平台的复杂度几乎全藏在页面下面派单规则、状态流转、结算分账、地图定位每一块都能把人折腾到怀疑人生。这类号称“仿东郊到家源码”的项目本质上是一套同城 LBS 派单 O2O 上门服务的完整解决方案不是简单几张页面就能撑起来的。这篇内容我结合自己实际做类似系统交付的经验把从产品模型到源码落地的完整链路拆一遍重点讲那些“源码里看得到但没人给你解释”的设计逻辑。想自建平台做同城轻资产生意的人或者要给客户交付这类系统的开发团队都可以拿它当落地参考。1. 产品模型拆解平台到底在撮合什么上门预约平台看起来是“卖服务”但从系统设计的角度看它其实是在做三件事让用户找到确定性让技师拿到效率和收入让运营者拥有调度和风控能力。把这三件事想清楚后面所有功能设计和表结构才有依据。1.1 用户端要的不是“下单”而是“确定性”用户打开小程序诉求非常具体现在或者某个明确时间在自己所在的位置能约到需要的服务。这个“确定性”决定了前端不能只做一个漂亮的技师列表。比如一个足浴技师今晚排班已经满了首页就不该继续推荐她一位美容师只服务女性用户男性用户点进来就应该看到她被过滤掉技师当前不在服务范围内详情页就不该展示“立即预约”按钮。我建议预约流程按这个顺序设计浏览服务分类 → 选择服务项目 → 查看可约技师列表按距离、评分、价格排序→ 选择上门时间段与地址 → 在线支付 → 等待系统派单/技师接单 → 技师上门 → 服务完成 → 评价。每一步都要围绕“可约”来做约束。服务项目还必须和技师技能做关联绑定否则就会出现用户看到的技师什么项目都接真到了现场却说不会做的尴尬情况。用户在预约前看不到技师是否是“空闲状态”也是差评的重灾区所以用户端技师列表要实时反映“在线可约”状态这种状态数据要靠技师端的上线/下线开关来驱动。1.2 技师端关心的是接单效率与收入透明技师端很多时候就是一个单独的小程序但它的重要性一点不比用户端低。技师最在意三件事今天几点在哪一单、这一单能挣多少、钱什么时候能提现。所以技师端的功能基本围绕日程、接单和钱包来做服务状态开关上线/下线、今日日程列表、新订单通知、接单/拒单、开始服务/完成服务、收入明细、提现申请。这里有一个容易被忽略的点接单时的“价格快照”。技师接到订单那一刻界面必须明确展示这单的服务项目、时长、预计收入别让技师接了单再回头问客服“这单怎么才这么多钱”。收入明细要能对得上每一单显示用户实付、平台佣金、技师到手这样技师才会信任平台。结算和提现模块可以做在技师端最显眼的位置因为对技师来说“挣多少钱”就是这款产品最重要的价值。1.3 运营端真正要做的是调度、审核与风控运营后台才是整条业务线的中枢。常规功能包括门店/商家管理、技师入驻审核身份证、健康证、技能资质、服务类目与价格配置、城市与商圈划分、订单监控与人工干预、优惠券和会员体系、投诉处理、财务结算。风控在运营后台里尤其不能省。日常最容易出现的问题就是技师绕过平台私下接单所以后台要对订单完成后的沟通行为保留记录对线下交易投诉做出处理。还有一类问题是恶意差评和骚扰投诉后台需要给用户提供“一键投诉技师”的入口同时给技师提供申诉通道。运营后台的权限也要分角色财务、客服、运营、超管各管一摊避免一个账号看到全部数据。2. 技术架构与表结构多端复用的实现路径2.1 主流源码技术组合我接触到的运营版上门预约源码大多数是这么搭的后端用 PHP 系框架ThinkPHP、Laravel 比较常见用户端和技师端用 uni-app 做跨端一套代码同时编译微信小程序、H5、Android/iOS APP运营后台独立做一个 Vue 或 Layui 管理界面。这个组合不算“高级”但胜在成本可控PHP 部署门槛低一套源码交付给客户以后客户随便找个外包都能维护。如果预算允许后端上 Java 或 Go 会更稳但对同城平台早期的业务量来说PHP 完全够用。uni-app 的代价是涉及到原生能力的地方比如地图定位、音视频通话、推送还是要做条件编译和原生插件。我的建议是如果平台定位是“小程序优先”可以坚持 uni-app如果后续确定重点做 APP反而可以把 APP 端用原生或 Flutter 单独做因为上门服务里技师和用户之间的位置共享、即时通讯体验在原生端明显优于跨端壳。但大多数刚起步的团队还是先跑通 uni-app 更实际。2.2 用户端和技师端必须拆开用户端小程序和技师端小程序绝不能合在一个项目里这一点要单独强调。合在一起会带来三个问题一是微信审核过不了容易被判断为“多角色混合”而要求说明还可能面临类目问题二是用户路径混乱小程序主体定位不明确平台要让用户看服务要让技师看订单一个小程序根本装不下两套完全不同的信息架构三是从业务隔离角度技师端一旦出错会直接影响用户端发版进度。所以哪怕代码可以复用发布时也一定要分成两个小程序主体、两个 APP 包后台角色和数据权限再分别控制。2.3 核心表结构参考源码拿到手之后先看表结构比先看页面更重要。一张能支撑运营的订单表至少要有这些字段订单号、用户 ID、技师 ID、门店 ID、服务项目 ID、服务开始时间、服务地址经纬度和文本、预约状态、支付状态、订单金额、优惠金额、实付金额、技师佣金、平台佣金、下单时间、支付时间、完成时间、取消原因。如果一张 orders 表里连经纬度都没有说明它只是个纯商城下单系统不是完整的同城派单系统。下面是一个简化版订单表结构可以直接对照你手里的源码来判断功能完整性CREATE TABLE order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, user_id int NOT NULL COMMENT 用户ID, technician_id int DEFAULT NULL COMMENT 技师ID, store_id int DEFAULT NULL COMMENT 门店ID, service_id int NOT NULL COMMENT 服务项目ID, service_time datetime NOT NULL COMMENT 预约上门时间, address varchar(255) NOT NULL COMMENT 服务地址, lng decimal(10,6) NOT NULL COMMENT 经度(GCJ-02), lat decimal(10,6) NOT NULL COMMENT 纬度(GCJ-02), status tinyint NOT NULL DEFAULT 0 COMMENT 订单状态, pay_status tinyint NOT NULL DEFAULT 0 COMMENT 支付状态, total_amount decimal(10,2) NOT NULL COMMENT 原价, coupon_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, commission decimal(10,2) DEFAULT 0.00 COMMENT 平台佣金, settle_amount decimal(10,2) DEFAULT 0.00 COMMENT 技师结算金额, create_time datetime NOT NULL, pay_time datetime DEFAULT NULL, finish_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_technician_time (technician_id,service_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;看到这种字段基本说明这个源码的设计者考虑过 LBS 派单之后的完整链路可以往下继续看派单逻辑。3. 同城派单引擎LBS匹配与防并发调度3.1 技师可达范围的圈选逻辑同城派单的核心不是“全城抢单”而是先按地理位置圈一个候选集合。做法通常是用户下单时拿到服务地址的经纬度服务端以这个点为中心、按一定半径比如 5 公里筛选技师。半径圈选可以用 MySQL 的 Haversine 公式直接算也可以先按经纬度做矩形粗筛再精确计算距离减少计算量。SELECT * FROM technician WHERE lat BETWEEN ?-0.05 AND ?0.05 AND lng BETWEEN ?-0.05 AND ?0.05 AND status 1业务规模上去之后再接 Redis GEO 或 Elasticsearch 也不迟。这里有个细节值得注意不同地图的坐标系不一样。微信小程序里用腾讯位置服务拿到的是 GCJ-02火星坐标如果服务端存的坐标来自高德或百度不能直接拿来算距离需要统一转换。否则就会出现“系统判定技师在 2 公里内实际距离 5 公里”这种问题。圈选技师时除了距离还要叠加几个过滤条件技师在线状态、服务项目匹配、预约时间是否与技师已有订单冲突、服务地址是否在技师的服务范围部分技师只接固定区域、评分和拒单率权重。这些条件搞清楚了派单引擎才算有了骨架。3.2 抢单、派单、值班三种模式的取舍模式适合阶段优点缺点抢单技师多、供给充足平台省心技师积极性高单量波动时没人抢热门单抢不到派单/自动匹配平台强控制、口碑期分配合理体验可控对调度算法要求高值班/排班固定门店、固定时段服务时间稳定临时需求响应慢实际运营中很少只用一种模式。常见组合是普通订单走自动匹配优先派给距离近、评分高、拒单率低的技师同时给技师几秒确认时间不接就自动流转到下一位部分高价值订单或体验单走手动派单由运营人员指定指定技师忙时开放抢单闲时走派单。源码里如果只有“抢单”没有“派单”运营成本会很高。3.3 并发冲突与超时无人接单的兜底抢单场景最容易出现两个技师同一时间点了同一个订单。处理方式是状态机加乐观锁接单接口用一条带条件的 UPDATE 把订单状态从“待接单假设 status1”改成“已接单status2”影响行数为 0 就说明被别人抢了返回“手慢了”。UPDATE order SET technician_id ?, status 2, accept_time NOW() WHERE id ? AND status 1这种写法比先查再更新更稳妥也不会给数据库加锁造成性能问题。同时要做好超时兜底用户支付后如果 60 秒内没有技师接单系统自动扩大匹配半径再超时就通知运营人工干预或者给用户发送“暂无人接单可取消全额退款”的提醒。千万别让订单无限期挂在那儿用户等太久就会流失。4. 订单状态机与结算资金流设计4.1 一套能兜住所有异常的状态流转上门预约订单不是简单的“下单到完成”中间有很多分支。推荐的状态集合是这样的状态含义触发方待支付用户已提交但没付款用户待接单已支付等待技师确认系统已接单技师已接单准备上门技师服务中技师已开始服务技师待评价服务完成等待评价技师已完成用户已评价或超过评价期系统已取消未支付自动取消/用户取消用户/系统已退款取消后资金已原路退回系统/财务每次状态变化都要留操作日志。这里特别容易踩坑退款状态和订单状态不联动。比如用户发起了退款财务在后台点击“同意退款”订单状态却还是“服务中”技师照常上门最后的体验肯定一团糟。所以我的建议是状态变更逻辑写成服务层统一方法任何入口改状态都必须经过同一套校验不要出现前端改造了一个状态、服务端逻辑没跟上的情况。4.2 金额拆分与技师结算逻辑订单金额模型建议这样用户实付 服务项目原价 − 优惠券金额 上门费技师结算 用户实付 ×1 − 平台佣金比例再扣除可能的平台技术服务费。举例一个 SPA 项目原价 199 元用户有 20 元优惠券实付 179 元平台佣金 20%那么技师到手就是 179 × 0.8 143.2 元平台收入 35.8 元。这个账必须在订单完成那一刻就生成结算快照存入结算表而不是等提现时再算。结算时机一般是 T1 生成可提现余额。也就是说当天完成的订单第二天凌晨结算到技师钱包的“可提现余额”技师发起提现后进入“提现中”财务审核打款后变为“已提现”。每一笔钱都有迹可循。源码里如果技师余额只写在技师主表的一个字段里没有独立的资金流水表后期对账会非常痛苦建议尽早补上。4.3 退款与售后场景的状态联动退款不是把“已支付”改回“未支付”就完事背后要处理三件事三方支付渠道退款、订单状态回退、技师结算金额扣回。如果技师已经完成这单并且已经结算用户再申请售后系统需要生成一条负数结算记录从技师可提现余额里扣除而不是直接改历史流水。这些联动逻辑是判断一套源码是否“运营级”的试金石。我见过最典型的 bug 是用户取消订单后原路退款成功了但订单表里没有标记“已退款”导致技师端仍然显示该订单可接单或者技师完成订单后订单进入“待评价”但结算流水没有生成提现时少了一笔。这些都不是功能复杂度的问题而是状态机和资金流没有形成闭环。拿到源码第一件事就是把“状态流转”和“金额变化”两张图先对着代码在脑子里走一遍能走通后面运营才省心。5. 源码落地最容易翻车的几处细节5.1 定位坐标系与小程序合法域名上门预约系统绕不开定位。小程序端使用地图相关能力需要在腾讯位置服务申请 key不同端小程序、Android、iOSkey 要分开申请别混用。发布之前还要在微信公众平台把 request 合法域名、uploadFile 合法域名都配好否则真机调试时接口全被拦截。我第一次交付时就吃过这个亏本地工具一切正常手机一扫码全部请求失败最后排查了一个小时发现只是合法域名没配。坐标系问题同样恼人。服务端如果用的是高德或百度的坐标前端用腾讯地图展示中间不做坐标转换技师导航会偏。统一规则是前端展示用 GCJ-02服务端存储也用 GCJ-02所有第三方坐标都转到火星坐标之后再入库。建议源码里单独放一个坐标转换工具类不要在业务代码里到处写转换逻辑。5.2 支付资质与类目过审上线不是只把代码跑起来还有一大堆资质问题。微信支付商户号的主体必须和小程序主体一致如果不一致联调时经常碰到“商户号与 AppID 不匹配”的错误。上门服务这类平台在微信小程序类目审核上也有要求涉及美容、健康类服务部分类目需要营业执照和特定资质有的还可能需要门店环境照片。我的经验是先把类目、商户号、支付回调地址全部确定下来再动联调不然代码写得再完整也发布不出去。关于“仿东郊到家源码”这种命名它只是说明业务模式参考了同城上门预约产品交付给客户时一定要让对方留意当地对生活服务平台的监管要求确保平台里上线的服务项目合法合规。5.3 部署环境、权限隔离与数据备份部署环节看起来不复杂但容易在环境版本上翻车。PHP 项目要注意 PHP 版本和扩展比如 Redis 扩展、fileinfo 扩展、MySQL 版本、伪静态配置小程序后端要求 HTTPSSSL 证书要提前准备。运营后台一定要做角色权限至少拆成超管、运营、财务、客服四级财务只能看结算和提现客服只能看订单和用户信息避免一个账号权限过大。数据备份不是可选项。数据库至少每天自动备份一次提现表、订单表、结算表要重点保护。我建议上线第一周每天都检查一次备份是否成功很多备份任务配置了但没执行等数据丢失时才发现就晚了。隐私合规方面用户手机号授权、位置定位、个人信息收集都需要在隐私协议里写清楚微信小程序也要求在后台配置“用户隐私保护指引”这些动作要在提审前完成。我个人做了几个类似项目之后最深的感受是上门预约平台的开发难点从来不在 UI而在所有“看不见的逻辑”是否闭环。派单、状态、结算、LBS任何一个环节偷懒最后都是运营端和客服来背锅。写这篇内容也是一个提醒源码只是起点把状态流转和账目算清楚系统才算真正“运营级”。如果你正在评估一套类似的源码建议先拿这篇里的表结构和状态清单去对照能对上的越多后面交付越省心。如果有实际项目里遇到的问题也欢迎在评论区交流踩过的坑本身就是最好的经验。本文还有配套的精品资源点击获取
