企业官网建设流程全解析

简介：面向同城上门服务赛道的开发者和商家，这份运营版预约小程序源码提供一套基于PHP后端与uniapp前端的全开源解决方案，覆盖公众号、H5、小程序及APP四端，一套代码可多端复用。功能围绕预约下单与技师派单展开，可灵活适配美容美发、家政保洁、足浴推拿、SPA理疗、维修安装等上门服务场景，也可延伸至私教家教、瑜伽健身、月嫂保姆、钟点工等预约领域，适合快速搭建仿东郊到家的本地生活服务平台。压缩包共288个文件，其中前端页面组件168个、逻辑脚本65个、配置文件15个，另辅以样式表、说明文档、图标素材等，整体仅764KB，轻量且结构清晰，便于二次开发。从文件构成看，前端页面、交互逻辑与配置相互分离，源码全开源无加密，可直接参考派单流程、前后端分离架构以及uniapp的多端适配写法。目前已有2691人浏览学习该资源，对希望以较低成本进入上门服务领域的开发者而言，具有明确的借鉴与复用价值。

1. 仿东郊到家这盘棋：运营版上门预约到底在解决什么问题

“仿东郊到家”这类标题下的源码，看着是小程序加APP，实际交付的是一套同城上门服务的调度系统。用户在小程序里选美容、家政、足浴、SPA，按时间和距离下单；技师在APP上抢单、上门、结算；运营方在后台把订单精准派到技师手里，同时处理分佣、对账、评价和风控。这套系统和外卖商城最大的区别是，服务不能库存，技师就是库存，每个订单都要完成一次“人、时间、地点”的匹配。

适合做这个方向的人有两类：一是手里有本地商家资源，想复制多城市连锁的团队；二是准备买源码轻成本试错的个人创业者。不适合只想要展示官网、把订单落在微信聊天记录里的项目。运营版的真正门槛不在界面能否上架，而在派单调度、多店抽佣、技师结算和合规审核这几块硬骨头。下面按“业务模型、最小链路、派单引擎、踩坑实录、迭代调优”的顺序展开，新手可以照步骤走，熟手可以直接跳到第4章看派单算法参数。

2. 三端闭环与订单状态机：看懂仿东郊到家的最小完整版

先立业务模型。仿东郊到家在业务上是“用户端小程序 + 技师端APP + 管理后台”三个终端跑一个订单生命周期。用户端负责浏览服务、选技师、下单支付；技师端负责抢单、履约、申请提现；管理后台负责城市门店管理、上下架技师、配置派单规则和结算对账。任何一套标着“仿东郊到家源码”的项目，如果缺这三端之一，本质上就是残版。实际接手源码时，第一步不是跑起来看界面，而是打开数据库看表，确认业务闭环是否完整。

2.1 最小完整版：三端一起跑至少要这些表

常见的源码模板会把会员、商品、库存、优惠券全搬进来做外卖商城那套。上门服务不该照抄，因为服务不可库存、没有SKU，一个订单对应一个技师和一段时间。我整理过一套能支撑全流程的最小表结构，核心实体只有四个：服务类目、技师、订单、派单日志。

-- 上门预约核心表：只保留能支撑派单闭环的实体 CREATE TABLE service_category ( id INT PRIMARY KEY AUTO_INCREMENT, city_id INT NOT NULL COMMENT '归属城市', name VARCHAR(32) NOT NULL COMMENT '服务名：美容/家政/足浴/SPA', status TINYINT DEFAULT 1 COMMENT '1上架 0下架', sort_weight INT DEFAULT 0 COMMENT '列表排序权重' ); CREATE TABLE technician ( id BIGINT PRIMARY KEY AUTO_INCREMENT, city_id INT NOT NULL, name VARCHAR(64) NOT NULL, level TINYINT DEFAULT 1 COMMENT '技师等级，影响派单优先级', lat DECIMAL(10,6) NOT NULL, lng DECIMAL(10,6) NOT NULL, rating DECIMAL(2,1) DEFAULT 5.0 COMMENT '评分', accept_rate DECIMAL(3,2) DEFAULT 1.00 COMMENT '近30天接单率', order_count INT DEFAULT 0, status TINYINT DEFAULT 0 COMMENT '0离线 1空闲 2服务中' ); CREATE TABLE service_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) UNIQUE NOT NULL, user_id BIGINT NOT NULL, city_id INT NOT NULL, technician_id BIGINT NULL COMMENT '派单成功后写入', service_time DATETIME NOT NULL COMMENT '预约上门时间', address VARCHAR(255) NOT NULL, lat DECIMAL(10,6) NOT NULL, lng DECIMAL(10,6) NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL COMMENT '见下方状态机', dispatch_type TINYINT DEFAULT 0 COMMENT '0抢单 1指定派单 2自动派单' ); CREATE TABLE dispatch_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, technician_id BIGINT NOT NULL, distance_km DECIMAL(5,2) NOT NULL, action VARCHAR(16) NOT NULL COMMENT 'PUSH/ACCEPT/REJECT/TIMEOUT', created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

逻辑说明：这不是教科书设计，而是把“谁在什么时间、去哪家、做什么”压缩成最小集合。technician 表把经纬度直接放主表，因为上门服务的推荐列表和派单都要按距离过滤，单独抽一张位置表会让每次派单多一次 join，高并发场景下没必要。dispatch_log 是派单复盘的关键，运营后台看“为什么这个订单没人接”全靠它，买源码时优先检查这张表是否存在。

参数说明：service_time 用 DATETIME 存预约时间，城市多了以后按城市时区做隔离；如果只做国内同城，统一用 Asia/Shanghai 没问题。status 用 TINYINT 是因为订单流转分支有限，后期加状态直接加枚举值即可，不建议一开始上重量级工作流引擎，小团队维护不起。

2.2 订单状态机：七次流转防漏单

上门预约和外卖最大的区别是服务时长不可压缩。外卖骑手可以早到等餐，技师早到了用户可能不在家，因此每个状态流转都要有超时兜底。常见做法是下面这张状态表。

实际操作里，我用 TINYINT 存状态，在代码层用一个常量类管理，不在数据库里做外键约束。状态机最核心的一句话是：只有配了超时动作的状态，才可能在真实环境里稳定跑。很多人把订单状态只做成前端展示，后台没有定时任务，结果用户付了款订单一直停在待派单，这是运营版最常见的埋雷点。实现上，用一个每30秒扫一次的定时任务处理所有超时状态即可，单量大了再换延迟队列。

判断一套源码是不是真运营版，第一件事翻代码查三样：有没有状态机定时任务，有没有派单日志表，有没有技师结算流水表。缺一样，上线后都要返工。

2.3 城市与门店隔离是运营版的底线

运营版要复制多城市，第一个要处理的就是数据隔离。按 city_id 隔离订单、技师和服务项目，是最粗暴也最有效的做法。如果业务有门店，再加一个 shop_id 字段，技师归属于门店，订单落到具体城市后按门店半径派单。价格体系要挂在 service_category 上，不同城市同一服务不同定价，不能写死在前端。这一层没做，后面加城市、调抽佣比例都会大面积改业务代码，改完还容易出数据串城的事故。

多城市还会带出抽佣规则的问题。常见做法是后台配置每个城市的平台抽佣比例，按订单金额乘比例计算出平台收入和技师收入。抽佣逻辑不能塞在支付回调里，因为退款、取消、投诉都会影响最终结算。正规的做法是单独建 settlement 流水表，订单完成后写入一条待结算记录，T+1 或手动确认后再进入技师可提现余额。

3. 前后端同构：打通用户下单与技师接单的最小链路

标题里“小程序APP开发”意味着双端都要上。最常见的做法是用 uni-app 一套代码编译到微信小程序和安卓/iOS，技师端再做独立壳；也有团队小程序用原生、APP用 Flutter，但这样双端要维护两套页面。多数买源码的人最后会后悔一件事：小程序和APP用户体系只靠手机号，没有做统一账号和版本收敛，结果运营数据一分为二，促销活动两边不同步。

3.1 uni-app 还是 Flutter：按团队沉淀选

我一般建议按团队技术栈选型：团队原本写 Vue，直接上 uni-app；团队偏原生、对性能要求高，APP端用 Flutter，小程序单独写。目标如果是“一套代码两处上架”，uni-app 依然是成本最低的解决方案。一套 Vue 语法同时编译到微信小程序和 App，订单、技师、派单三个核心页面的代码复用率能到八成以上。Flutter 在复杂页面动画上有优势，但上门预约这类业务地图、列表、表单居多，动画需求很少，为一个转场特效承担双端维护成本不划算。更现实的点是，微信小程序的支付、订阅消息、定位 SDK 对 uni-app 的适配比 Flutter 成熟，踩坑资料也更多。

外包行情也要说一下，开发一个 app 并上架大概要多少钱，这是常被问到的。一套带派单、技师端、后台、支付的上门预约系统，常规外包报价通常在20万到50万；买源码二开成本低一些，但后续要自己养后端。钱不是最大成本，三端联调和状态机排障才是。

3.2 下单与接单的三段核心接口

跨端项目最怕把业务写在页面里。正确做法是后端API统一，小程序和APP只负责渲染。我见过一个跑得稳定的精简接口设计，三个接口撑起主链路。

# 接口1：按距离找可用技师 @app.get("/v1/technicians") def list_technicians(city_id: int, lat: float, lng: float, category_id: int): rows = db.query( f""" SELECT id, name, rating, order_count, ROUND(6371.0088 * ACOS( LEAST(1.0, SIN({lat}) * SIN(lat) + COS({lat}) * COS(lat) * COS(lng - {lng})) ), 2) AS distance_km FROM technician WHERE city_id = {city_id} AND status = 1 AND category_skills LIKE '%{category_id}%' HAVING distance_km <= 5 ORDER BY distance_km, rating DESC LIMIT 20 """ ).fetchall() return {"items": rows}

逻辑说明：距离计算直接在 SQL 里用 Haversine 公式完成，避免把全城技师拉到内存再算一次。这里用了 MySQL 三角函数，数据量在几千技师时性能没问题；到了上万技师且高并发时，应该改成 MySQL 空间索引或使用 PostGIS。HAVING distance_km <= 5 表示只取5公里内空闲技师，这个半径建议做成后台可配置参数，不同城市密度差异很大。

# 接口2：用户提交订单 @app.post("/v1/orders") def create_order(payload: OrderPayload): order_no = gen_order_no(payload.user_id) # 幂等：同一用户同一时间只能有一个待支付订单 db.execute( "INSERT INTO service_order " "(order_no, user_id, city_id, category_id, service_time, lat, lng, amount, status) " "VALUES (%s, %s, %s, %s, %s, %s, %s, %s, 10)", (order_no, payload.user_id, payload.city_id, payload.category_id, payload.service_time, payload.lat, payload.lng, payload.amount) ) return {"order_no": order_no, "pay_params": wx_jsapi_params(order_no, payload.amount)}

逻辑说明：创建订单只置状态10，支付成功回调后才变20进入派单池。gen_order_no 里拼上用户ID和时间戳，防止同一用户快速重复下单生成多笔待支付订单，这是幂等设计最便宜的实现。

# 接口3：技师接单，防止并发重复接 @app.post("/v1/dispatch/accept") def accept(order_id: int, technician_id: int): rowcount = db.execute( "UPDATE service_order SET technician_id=%s, status=40 " "WHERE id=%s AND status=20 AND technician_id IS NULL", (technician_id, order_id) ).rowcount if rowcount != 1: raise HTTPException(409, detail="订单已被其他技师接走或状态已变化") return {"result": "ok"}

逻辑说明：接单不先查再更新，而是直接执行带状态条件的 UPDATE，通过影响行数判断是否抢到。两个技师同时点接单时，数据库行锁保证只有一个人 update 成功。这就是最基础的乐观锁，不需要引入 Redis 分布式锁。

3.3 接单消息：轮询、WebSocket与订阅消息

抢单功能要实时，但实时性要分端处理。最便宜的方案是小程序端每5秒拉一次待抢单列表，用定时器实现；缺点是慢、耗电，还有致命问题：微信小程序切到后台后定时器会挂，回到前台才能恢复。更可靠的是 WebSocket 长连接，服务端有订单直接推送，前端只需要维护心跳重连。但 WebSocket 在微信小程序里有连接数限制，也需要处理断线重连。

推荐的做法是混合方案：APP端用 WebSocket，小程序端用“进入页面拉一次 + 微信订阅消息”提醒用户有新的派单，用户点开小程序后再拉列表。订阅消息是一次性的，用户每次接收都要授权，所以服务端只在用户打开接单工作台时请求授权，收到派单时才发微信通知。这是投入产出比最高的组合，不要为了技术炫技全上WebSocket。

4. 技师派单引擎实战：抢单池、指定派单与自动调度

派单引擎是这套系统最值钱的部分，也是区分“演示版源码”和“运营版源码”的核心。演示版通常只是列表页加个下单按钮，派单逻辑写死。运营版至少要支持三种派单模式：抢单池、指定派单、自动派单，并且三种模式能在后台按城市、业务线切换。

4.1 技师工作台与抢单池

技师端APP打开后的默认页是工作台，展示三块：今日待服务、抢单池、我的钱包。抢单池的实现不复杂，就是按 city_id 查状态为20、dispatch_type 为0的订单，按预约时间排序展示。关键在两点：一个是订单进入抢单池时给符合距离条件的技师各发一条推送，另一个是同一订单在多个技师工作台上同时出现，谁先点接单谁赢。

-- 拉取当前城市抢单池订单 SELECT o.id, o.service_time, o.address, o.lat, o.lng, o.amount, c.name AS category_name FROM service_order o JOIN service_category c ON o.category_id = c.id WHERE o.city_id = %(city_id)s AND o.status = 20 AND o.dispatch_type = 0 AND o.service_time BETWEEN NOW() AND NOW() + INTERVAL 3 DAY ORDER BY o.service_time ASC LIMIT 20;

逻辑说明：抢单池只展示未来3天内的订单，历史订单出现只会让技师困惑。amount 直接展示，让技师判断值不值得接。这里不查距离，因为抢单模式下技师自己心里有数，他会看地址决定接不接。距离过滤只用于“推荐”排序，不做硬限制。参数说明：LIMIT 20 防止订单多时一次拉太多，客户端可以做上拉加载。

抢单模式有一个运营上的坑：抢单率低的时候订单会一直挂在池子里，用户体验很差。解决方案是给每个抢单订单设置超时时间，比如进入抢单池120秒后没人接，系统自动转为自动派单模式。

4.2 自动派单算法：距离加权与积分权重

自动派单是降低人工成本的关键。常见做法不复杂，按距离、评分、接单率三个维度打分，每项配一个权重，最后取最高分技师。下面这段伪代码可以直接翻译成 Python 或 Go。

def auto_dispatch(order, candidates): """按距离、评分、接单率加权选出最优技师""" best = None best_score = -1.0 for tech in candidates: if tech.status != 1: # 不处于空闲状态直接跳过 continue distance = haversine( order.lat, order.lng, tech.lat, tech.lng ) if distance > max_radius: # 超过派单半径直接跳过 continue score = ( 0.5 * (1 - distance / max_radius) + # 距离越近分越高 0.3 * (tech.rating / 5.0) + # 评分归一化 0.2 * tech.accept_rate # 接单率 ) if score > best_score: best_score = score best = tech if best is None: return None return best

加权参数表：

这个权重不是拍脑袋写的，上线后要按城市调。一线城市用户要求响应快，距离权重要高；低密度城市技师数量少，接单率权重可以降一点，避免永远派给同一个人导致过度疲劳。权重参数建议全部配置在后台，不要写死在代码里。我见过几个项目把权重硬编码，运营想调参数只能等发版，非常痛苦。

4.3 并发下的重复派单

自动派单有个常见并发问题：同一时间有两个订单进来，扫描技师池时技师A都是空闲，结果把A同时派给了两个订单。解决方式是在派单执行时加状态条件更新，跟接单接口一样，用 WHERE status = 1 来抢技师占用状态。

# 占用技师并绑定订单，一次SQL完成 rowcount = db.execute( "UPDATE technician SET status = 2 " "WHERE id = %s AND status = 1", (technician_id,) ) if rowcount != 1: # 技师已被别人占用，重新选 return auto_dispatch(order, candidates_without(technician_id))

逻辑说明：这里先在 technician 表上占用技师，再更新 order 表。先锁技师再锁订单，避免出现“订单已派给A但A又被B抢走”的不一致。如果占用失败，说明A已经被其他订单派走，直接排除A重新计算即可。派单链路里还有一个细节：派单成功要写 dispatch_log，推送消息给技师App，同时启动120秒超时计时器。

超时改派：如果技师在120秒内没点接单，订单状态保持20但把技师ID从 order 表清空，写一条 timeout 日志，重新执行 auto_dispatch。如果连续改派三轮都失败，订单转入抢单池并通知运营人员人工介入。这个兜底机制必须有，不然凌晨没技师接单，用户会一直等。

5. 运营版上门预约避坑实录：5个让项目翻车的边界问题

上门服务行业是线上流量和线下履约的结合，坑不在功能开发，而在资质、风控和现实世界的不确定性。下面这几条都是我见过或经历过的真实问题，每条按现象、原因、解决来写。

5.1 微信审核与APP上架类目

现象：小程序第一次提审就被拒，理由是服务类目涉及医疗健康，需要上传资质证明；APP在应用商店也被驳回，原因是“应用内存在未报备的陌生人社交元素”。

原因：审核机器对“按摩”“SPA”这类词极度敏感，类目选生活服务后，只要详情页出现“理疗”“治疗”“缓解疲劳”等表述，就会被误判为医疗健康类。另一个常见问题是用户和技师聊天功能没做内容过滤，被当成陌生人社交。

解决：服务命名改成“保健按摩”“美体SPA”，文案里彻底去掉治疗、诊断、疗效、缓解等词；类目选“生活服务 > 丽人/美业”。技师和用户的聊天只允许在订单进行中开通，订单完成或取消后立即关闭，避免被定性为即时通讯工具。APP上架前把隐私政策、软件著作权和ICP备案准备好，这三样缺一个都会被卡。

5.2 技师结算与支付风控

现象：上线第二个月，平台每天的营收都被支付通道风控冻结，需要提交大量材料解冻，技师提现也经常被卡。

原因：平台把所有用户付款先收进同一个商户号，再人工转给技师，这就是典型的资金归集，触发支付机构反洗钱风控。很多运营版源码默认就是这样，图省事不做分账。

解决：尽早申请微信支付/支付宝的分账能力，用户付款后按平台抽佣比例自动分账，平台只留佣金部分。如果资金量还没达到分账门槛，就退而求其次：用户付款进平台商户号，技师账户走“平台余额”，接单完成T+1后从余额提现，平台每天定时把款项结算给技师。给新技师的提现频率和最低金额做限制，比如满100元才能提、每周只能提两次，减少财务操作量。

5.3 地图配额一天被打满

现象：上线第三天，用户端发现所有技师都显示距离为0，派单也全部失效，后台日志一堆地图鉴权失败。

原因：免费地图key的日调用配额被列表页连续刷新打满。用户端首页进入就初始化地图，每次滑动列表都重新逆地理编码，一个用户一小时能消耗上百次配额，几百个用户就把一天的额度烧完了。

解决：地图只做两件事，一次定位和一次逆地理编码，取到城市和街道后立刻销毁地图实例。列表排序的距离全部用后端 Haversine 计算，不再调地图JS。地图组件的加载改成懒加载，只有进入订单详情页和技师详情页才初始化。后台还要加一个配额监控，用量到80%就告警。这个坑完全没有技术难度，纯粹是前端没管住地图实例。

5.4 “幽灵技师”与首单补贴陷阱

现象：发完首单立减券，订单量确实冲了一波，但三天后发现这些订单大多在服务前被取消，取消费用平台全额垫了，而且新注册的技师和下单用户集中在同一批IP和设备上。

原因：被兼职羊毛党盯上了。他们的玩法是同时注册用户和技师，用户下单、技师接单，上门根本不存在，到时间后双方取消或完成，把平台补贴洗出来。

解决：做两个硬校验。第一，用户下单定位和接单技师所在位置距离小于500米时，订单直接进人工审核列表，不可自动派单。第二，首单补贴改为订单完成且用户没有投诉后才结算，补贴不进余额，而是下次消费抵扣券，这样即使订单完成也算不出钱，还有复购效果。这两个规则配置到风控系统后，羊毛党会自己散掉。

5.5 定位漂移导致派单混乱

现象：技师明明在A小区，自动派单却把他派到了5公里外的B小区，用户投诉“技师离我太远”，后台看技师坐标确实在B。

原因：安卓端拿到的定位混用了GPS、基站和Wi-Fi数据，在室内时基站定位误差经常能到几百米；iOS端如果只开了“使用期间”定位，App切后台后位置就不更新，再次回到前台时上报的是旧坐标。多套定位SDK的返回值混在一起用，没有做可信度过滤。

解决：技师端位置上报不是每次都写入数据库，而是先在内存里做清洗。当新坐标与上一次上报坐标距离超过500米时，拉取最近一次有效定位做交叉验证，连续两次一致才更新数据库。同时把上报频率从每5秒一次降到每30秒一次，高频上报没有意义，低密度城市5秒一次不仅费电，还会放大漂移问题。位置上报看着像玄学，实际就是少了这层过滤。

6. 把派单调优当作日常迭代：从一轮压测开始

派单系统上线只是开始，真正要花时间的是根据数据调参数。最后这部分给出一套可以直接使用的默认参数、压测脚本和改派策略，照着做就能把系统稳下来。

6.1 先按这套参数跑起来

这套参数不是标准答案，但作为启动值足够。上线两周后拉一下后台数据，重点看两个指标：平均接单率低于60%说明自动派单的半径或权重有问题；平均改派次数大于1.5说明技师密度不够，得加大招聘或调整半径。

6.2 用并发脚本验证派单峰值

改参数之前先验系统能不能扛住峰值。下面这个脚本模拟50个用户同时下单，观察派单接口有没有报错、有没有出现同一技师被重复派单。

import threading import requests import random BASE_URL = "https://api.example.com" def create_order(user_id): payload = { "city_id": 1, "category_id": 5, "service_time": "2025-06-20 14:00:00", "lat": round(random.uniform(30.2, 30.3), 6), "lng": round(random.uniform(120.1, 120.2), 6), "amount": 298.00, } resp = requests.post(f"{BASE_URL}/v1/orders", json=payload, timeout=10) if resp.status_code != 200: print(f"user {user_id} create order failed: {resp.text}") threads = [] for i in range(50): t = threading.Thread(target=create_order, args=(i,)) threads.append(t) t.start() for t in threads: t.join() print("done: 50 orders created")

逻辑说明：脚本里随机生成经纬度，让50个订单分布在不同位置，避免全部挤在同一坐标导致派单结果失真。跑完脚本后去数据库查 dispatch_log，检查有没有同一订单派给多个技师、有没有技师被重复占用的记录。参数说明：timeout=10 设了请求超时，防止接口卡死导致脚本线程挂住；如果想测更高并发，把50改成500，看派单耗时曲线。

6.3 改派策略与值班表

自动派单改派逻辑建议做成循环：A技师超时 -> 排除A重新计算 -> B技师超时 -> 排除A、B重新计算 -> 第三轮还失败 -> 订单转入抢单池并标记紧急。同时给运营人员配一个值班告警页面，显示所有“待人工介入”的订单，超过30分钟没人处理就推送企业微信通知。值班表不需要24小时，但每天早上9点和晚上9点必须各看一次积压订单，这两个时段是上门服务下单高峰。

线上稳定后，我一直保持一个习惯：每周一上午看前一周的派单日志，专门查“改派超过2次”的订单，把这些订单的地址标在地图上。如果集中在某个小区，说明那里是服务空白区，需要招人；如果分布随机，说明技师数量不够，应该调高派单半径，而不是硬加人。一次翻车经历：上线第一周把自动派单半径调到10km，订单确实涨了，但差评率翻了倍，因为技师要跑20多分钟才到。后来改回5km，差评率立刻回落。调参这种事，每次只动一个变量，观察三天再动下一个，别拍脑袋一起改。这套上门预约系统不是一锤子买卖，上线只是开始，希望帮到你。

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