企业官网建设流程全解析

简介：面向同城上门服务行业的运营级预约源码，聚焦美容家政、足浴水疗、技师派单等场景，适合具备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 Map<String, Set<String>> 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) { Set<String> 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(key=lambda x: x[1], reverse=True) 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 项目；信息服务费模式常用于低频高客单。实操层面我建议用比例抽成，配置灵活，可按服务分类单独设费率。

提现这块要克制。初期不建议做实时提现，全部走 T+1 结算。原因是技师提现涉及银行卡打款接口的调用，每笔转账都有成本，小额高频提现实在不划算。设置单笔最低提现金额 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(host='localhost', port=6379, db=0) 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 毫秒，派单体验完全不一样。

最后提一个容易被忽略的排查技巧：派单延迟时可以区分是算法慢还是推送慢。算法慢看函数耗时日志，推送慢看推送服务的回执回调。很多情况是算法已经算好了，消息推送到技师端的过程中出了问题。定位到具体瓶颈再优化，而不是盲目买服务器升配置。这套系统的逻辑不复杂，复杂度全在边界和各种异常分支，把异常控制和状态流转做好，系统就成功了大半。希望帮到你。

本文还有配套的精品资源，点击获取