小程序源码项目看得多了但真正把同城上门家政这套业务做扎实的Java后端其实不算多。原因很简单家政服务不像电商那样纯标品保洁、维修、保姆三种业态的服务流程差异巨大又要涉及LBS派单、实时状态流转、资金结算稍不注意后端就变成了只包了一层CRUD的皮。这个标题里支持保洁/维修/保姆六个字背后是三套完全不同的业务模型。我结合自己开发同城家政小程序源码的实际过程把Java后端的架构设计、订单流转、支付清算和联调避坑完整梳理一遍给正在做类似项目的朋友一份可直接落地的参考。1. 同城家政小程序的核心业务拆解保洁、维修、保姆不是三个分类是三套流程很多人拿到需求第一反应是建一张服务类型表把保洁、维修、保姆塞进去然后订单表加个service_type字段就完事。这个做法在演示Demo里没问题真上线就会发现三种服务的计价方式、指派逻辑、完工标准、售后场景全都不一样硬塞进一套通用流程最终代码里全是if-else判断然后每个判断都有一堆边界情况没处理到。1.1 三类服务的业务特征对比我用一个表格把三者的核心差异先列出来这张表就是后续数据库设计和接口设计的依据对比维度保洁服务维修服务保姆服务计价方式按小时或按面积价格相对固定上门检测费维修报价非标定价按月/按天计薪周期结算服务时长单次2-4小时短平快30分钟检测维修时长不定连续多天、长期指派方式根据时间窗位置自动派单先派单上门检测报价后用户确认简历筛选面试预约签约完工标准用户验收可拍照确认维修完成用户确认费用每个服务周期考核/续约售后纠纷返工、漏项维修质量争议、二次故障考勤、工作质量、更换服务者资金流向在线支付实时分账定金尾款两段支付预收月费周期划拨从这里能看明白一件事同城家政小程序源码里保洁/维修/保姆真正的价值不在于服务分类而在于订单主流程的差异化设计。如果后端只做一张订单表通吃后面做报价确认、做周期结算的时候会非常难受。1.2 订单主流程的差异化设计我建议后端直接设计三种订单类型而不是一张大而全的订单表。三类订单在数据库层面可以共用一张订单主表但需要拆分扩展表和流程表保洁订单字段简单但需要记录房屋面积、时长为后续结算做校验同时要处理用户选了4小时服务者2.5小时就干完了这种超时/提前完成场景。维修订单必须增加检测费报价单二次确认节点。用户体验上维修订单天然分成两段先上门检测再报价施工。后端要处理最关键的场景——服务者报完价用户不确认这个单子怎么流转、时间怎么限制。实际上我在源码里设计了报价等待期超时自动取消并退还定金避免双方僵持。保姆订单走的是预约签约流程而非即约即用。用户需要先看简历、选人、约面试谈妥后生成长周期订单之后按周或月生成子账单进行周期结算。在订单主表上我特意留了几个公共扩展字段order_type订单类型、parent_order_id父订单用于保姆周期的子结算单关联、status状态机当前值。这三个字段是所有复杂流程的锚点。1.3 同城和上门两个关键词背后的设计压力同城意味着后端必须具备基于地理位置的能力——服务者在哪里、用户在哪里、谁能最快到达这直接决定派单效率。而上门则意味着地址管理不是简单的收货地址需要精确到楼栋单元门牌还要考虑小区门禁、车位、楼层等特殊说明否则服务者到现场打电话找路十分钟体验会非常差。这两点落在后端就是两个必须做扎实的模块地址本服务和LBS检索服务。地址本要支持常用地址增删改、定位自动填充、地址标签家/公司LBS检索则负责在用户下单时快速圈定附近可接单的服务者这个我放到下一节详细讲。总之标题里每个词都是需求约束别把它们当噱头。2. Java后端技术选型与关键模块设计为什么这套组合能撑起家政订单聊完了业务边界进入技术落地区。这个项目用到的核心技术栈是Spring Boot 2.7、MyBatis-Plus、MySQL 8.0、Redis 7、RabbitMQ可选、WebSocket通知推送前端配套微信小程序端原生或uni-app管理后台用Vue3。整体是单体应用模块化拆包没有一上来就上微服务——家政平台的初期业务量根本撑不起微服务的复杂度反而会把联调成本拉高。2.1 技术栈的选择逻辑与理由Spring Boot没有争议Java后端社区最成熟的基础框架生态全、招人容易、资料多。版本我建议用2.7而不是3.x原因很实在3.x要求JDK 17对很多外包团队和中小公司的服务器环境不友好而且大量第三方组件的兼容方案还在迭代期2.7配上JDK 8/11稳妥得多。MyBatis-Plus家政订单查询条件非常多——按时间、按服务者、按用户、按状态、按小区动态SQL是刚需。MyBatis-Plus的LambdaQueryWrapper能减少大量拼接SQL的代码分页插件也好用。MySQL RedisMySQL存核心业务数据Redis处理三件事验证码缓存、接口幂等键、高频读缓存如首页服务类目、热门服务者列表。抢单场景下Redis还可以做分布式锁的存储层避免并发指派同一个服务者。RabbitMQ如果订单量上来建议引入主要用三个场景——支付回调后异步更新订单状态、订单状态变更后发WebSocket通知、结算系统异步生成流水。量小的时候用线程池也能顶但MQ解耦会更干净。注意引入MQ的前提是你敢于处理消息丢失和重复消费。项目初期如果团队对MQ不熟宁可先用Spring事件的同步方式把订单状态变更发出来各模块监听处理。稳定比架构先进更重要。2.2 数据库模型的核心订单、服务者、地址、结算四条主链家政小程序源码的表结构我建议聚焦四条主链别急着扩充营销类表用户链user用户表、user_address地址表、user_coupon优惠券表。服务者链worker服务者表、worker_skill服务技能/类目关联表、worker_schedule服务时间安排表、worker_audit_record资质审核记录表保洁维修可轻量保姆必须厚。订单链orders订单主表、order_repairext维修订单扩展表、order_nannyext保姆订单扩展表、order_status_log状态变更日志表、order_settlement结算单表。资金链account用户/服务者资金账户表、cash_flow资金流水表、withdraw_apply提现申请表。这里特别说一下服务时间安排表的设计它是保证上门体验的隐形功臣。服务者要提前维护自己可接单的时间片比如周一上午繁忙、下午可接2单下单时后端在时间片碰撞检测里过滤掉不可用的人。没有这张表自动派单会把正在做A订单的服务者又派给B用户线下纠纷免不了。状态变更日志表也强烈建议加上。订单状态流转频繁用户投诉我的单到底怎么回事时管理后台能直接拉出完整时间线——谁在什么时间把订单从待指派改成了已指派比任何聊天记录都有说服力。2.3 LBS地域检索与自动派单的实现思路同城匹配的核心是找出用户附近3公里内、当前可接单、技能匹配的服务者。我用的方案是Redis GEO 内存过滤器地图API只做前端定位展示后端不直接依赖高德/腾讯的地图服务原因后面讲。具体流程是这样的服务者登录小程序/工作端后定时上报经纬度后端用Redis GEO的GEOADD命令存入key按城市分区如geo:worker:city:310100每个服务者一个GEO节点附带member为workerId。用户下单时先把用户的坐标用GEOSEARCH按半径默认3km可配置搜出候选workerId集合。对候选集合做内存过滤技能匹配前端传服务类目后端比对worker_skill表、排班匹配查询当天有没有开放时间片、忙碌状态过滤当前有没有未完成的订单查Redis的worker_busy键。过滤后的服务者列表按距离排序取前N个进入派单池。如果开启自动派单就用Redis分布式锁逐个尝试锁定服务者锁定成功即创建订单指派记录如果默认抢单模式就把候选单推送给他们先到先得。为什么不直接用MySQL空间索引因为MySQL的ST_Distance_Sphere在多条件过滤下性能不够稳定而且家政服务者数量达到万级以后每单都实时算距离压力比较大。Redis GEO的查询均摊成本很低配合内存过滤实测单次派单P99在80ms以内。还有一个小坑经纬度坐标系。微信小程序定位拿到的是GCJ-02坐标火星坐标而Redis GEO本身不关心坐标系我们只要保证所有坐标都用GCJ-02入库存取、前端展示一致映射回地图SDK即可。千万别混用WGS-84和GCJ-02同一个点在两种坐标系下可能差几百米派单半径稍微小一点就搜不到人了。3. 订单状态机与资金流程家政平台最容易出问题的两个深水区很多家政源码项目为什么一上线就乱问题集中在两个地方订单状态乱飞、资金账对不上。这两个问题本质上都是状态机设计不严谨。我在这套源码里花了最多精力设计的就是事件驱动型状态机资金流水兜底机制。3.1 三类订单的状态机设计状态机设计的原则是每个状态变更必须有一个明确的触发事件且只允许一条变更路径。不要在Controller里随意setStatus而是封装成OrderStateMachine统一接收事件保洁订单状态机PENDING_PAY(待支付)→支付成功→PENDING_ASSIGN(待指派)→自动/人工派单→ASSIGNED(已指派)→服务者开始服务→SERVING(服务中)→服务者提交完工/用户确认→FINISHED(待验收/已完成)→用户评价→EVALUATED(已评价)维修订单状态机在保洁基础上增加两段PENDING_ASSIGN→ASSIGNED→WORKER_ARRIVED(服务者已上门)→QUOTE_PENDING(待用户确认报价)→用户确认报价→REPAIRING(维修中)→FINISHED。此外还有QUOTE_EXPIRED(报价超时已取消)的状态。保姆订单状态机PENDING_INTERVIEW(预约面试)→INTERVIEWED(已面试)→PENDING_SIGN(待签约)→SERVING(服务期内)→按周期生成子订单结算→FINISHED(服务结束)。保姆订单会有多次子结算因此order_settlement表要有parent_order_id反查主订单。每次状态变更同时写一条order_status_log记录from_status、to_status、operator_type用户/服务者/系统/管理员、operator_id、remark。这个日志表不但用于纠纷定责还能在数据分析时还原用户完整行为链——比如用户在哪个环节流失最多对后期优化下单转化率非常重要。3.2 资金流程设计的五步闭环资金务设计上的核心目标是钱不乱、账能对。我落地为五步闭环下单锁额保洁和维修首段用户下单时先创建预支付单通过微信支付发起预支付接口锁定金额。支付回调确认微信支付回调通知到后端后端必须做四件事验签、验金额回调中的total_fee与订单应付金额比对、验订单号存在性、验订单状态防止重复回调把已支付订单改成其他状态。冻结与确认支付成功后用户侧资金进入已冻结状态服务者侧显示待结算。此时不要直接把钱打入服务者账户余额因为订单还没完工存在售后退款风险。完工结算订单确认完工后系统把订单金额从冻结状态划入服务者账户可用余额同时生成cash_flow流水每条流水必须有唯一的biz_id即订单号/退款单号。提现服务者发起提现后台审核后通过微信商家转账/银行卡打款更新账户余额并记提现流水。为什么完工结算这个环节值得强调大多数不成熟的家政项目把支付成功等同于服务者入账结果用户一投诉退款账上早没得退了。先冻结后结算退款时只需冲减冻结金额整套资金链路是干净的。我记得有个外部项目就是没做冻结上线一个月平台垫付了十几笔退款这个坑是真金白银换来的教训。3.3 退款与取消订单的兜底策略取消订单必须分场景设计待指派阶段取消全款原路退回无门槛。已指派未上门取消如果服务者已经出发需要允许服务者上报已出发以申请空驶补偿比如20元作为上门费由平台审核决定扣减比例。这块涉及平台运营规则后端只需预留补偿金额字段和审核记录别把业务规则写死在代码里。维修订单报价后取消用户在服务者上门检测后拒绝继续维修需要支付检测费或由平台优惠券抵扣这部分在报价单里提前明确。服务中取消按实际服务时长/比例扣费剩余部分原路退回。退款的核心技术点是幂等。微信退款接口要求商户订单号唯一后端每次退款操作必须以退款单号refund_no为唯一键如果退款回调因网络问题没收到调度系统重试时也必须传同一个refund_no否则会生成重复退款单。这里我用Redis SETNX做退款请求的幂等控制请求到达时先写幂等键再执行退款。4. Java后端与小程序联调的关键细节登录鉴权、实时通知、接口幂等小程序端源码和后端联调坑基本集中在三个点登录态、实时状态感知、接口防重。这几个问题不解决线上就会出现用户付了两次钱服务者接不到派单提醒订单状态刷新半天不对之类的严重投诉。4.1 登录鉴权jscode2session与手机号授权小程序端登录正规做法是wx.login获取code后端拿到code调用微信接口jscode2session换取openid和session_key。拿到openid后查user表没有就自动注册注意此时用户名等资料可能还不全建议引导用户补资料或直接引导手机号授权。然后后端自己签发一个业务token比如JWT失效时间建议设7天客户端存storage即可。手机号授权这里是另一个注意点wx.getPhoneNumber返回的encryptedData需要后端用session_key解密但session_key不在后端保持也没关系——前端在wx.login后立刻调手机号解密接口保证session_key没过期就行。很多人的坑在于先唤起手机号授权、再请求后端解密此时session_key可能已经不是最新导致解密失败。正确顺序是先wx.login拿最新code换session_key再解密手机号。业务上我建议保洁/维修用户手机号授权必做因为服务者上门需要电话联系但也可以提供微信授权直接进入的游客模式等下单时才强制绑定手机号转化率会好一些。4.2 订单状态推送WebSocket为主订阅消息兜底订单状态变了怎么让用户和服务者第一时间感知我采用WebSocket 微信订阅消息双通道WebSocket长连接用户和接单端都维护长连接。后端在订单状态机触发事件后通过WebSocket推送一条{orderId, fromStatus, toStatus, message}消息。注意不要直接把整张订单表塞给前端应该推一个事件壳前端收到后按需拉取订单详情接口避免重复推送导致的数据不一致。WebSocket断线重连小程序切后台超过一定时间WebSocket会被系统销毁。必须设计断线重连策略重连时带上userId和token服务端重连后主动推送当前未完成订单列表。订阅消息兜底用户没在线或WebSocket连不上时用微信订阅消息一次订阅一次下发推送关键节点——派单成功、服务者已到达、报价待确认、完工待验收。这块要提前规划好订阅模板每个模板都是一次性授权别在用户未订阅时群发会被判定违规。关于WebSocket的集群处理如果部署多实例建议通过Redis Pub/Sub或MQ广播订单事件所有后端实例都能收到并推送给各自连接的用户。千万不能只在单机实例内存里维护Session映射否则负载均衡会把通知推丢。4.3 接口设计中最容易忽略的幂等键、防重、参数校验家政小程序有个高频场景用户手快连点两次立即下单后端一不留神生成两个相同订单用户也付了两次钱。解决方式是接口幂等前端提交订单时生成一个uuid作为requestId后端在Redis里以requestId为key用SETNX加锁同一requestId重复请求直接返回第一次的结果。同时后端生成订单号时也确保同一用户同一维度的订单在极短时间内不重复创建。另一个高频坑是地址坐标参数被前端篡改。下单接口传的经纬度必须做合理性校验与用户最近的已知位置如最后一次上报IP定位做距离检查超过1公里直接抛业务异常。一句话后端不能信任前端传的坐标否则有人伪造坐标就能把跨城服务的单派给别人这是同城平台绕不开的安全点。参数校验方面MyBatis-Plus JSR 303就够用重点校验手机号格式、地址门牌号非空、预约时间不能早于当前时间且建议最早为2小时后否则服务者匹配难度大、维修描述长度限制最少10个字符防无效单。这类校验别省后端必须自己挡一道靠前端拦截是不靠谱的。5. 部署上线前的安全检查与性能优化清单最后这块内容是我每次交付家政小程序源码前必做的一轮检查。项目和普通CRUD后台不一样上线就要面对真实钱款和真实跑腿服务一旦出问题就是直接经济损失和口碑崩塌。5.1 支付与数据安全验签、防重放、脱敏支付回调验签必须用微信官方SDK不要手写XML签名比较。回调处理逻辑要天然幂等同一个订单的支付回调即便收到多次也只有第一次能改变状态。做法是先查订单状态已支付则直接返回success给微信不再执行后续逻辑。接口防重放除了幂等键建议对下单、支付、取消这类敏感接口做body签名校验可以用简单的sign MD5(params salt)方案防止报文被篡改重放。敏感信息脱敏用户手机号、服务者手机号在API返回前端时可用138****1234形式展示。服务者接单后、上门前再通过后端一次性换取完整联系方式同时设置60分钟有效避免用户长期保存服务者电话绕开平台私下交易。这是家政平台运营层面很关键的设计。文件上传安全用户的房屋照片、维修前/后照片、服务者资质证书会走文件上传。后端要限制文件扩展名白名单jpg、png、pdf等严禁开放php、jsp、exe等可执行后缀、大小限制图片建议不超过5MB、存储目录设置禁止脚本执行权限。特别是如果服务端用的Apache/Nginx默认配置不当容易被人上传恶意脚本这个必须提前堵死。5.2 数据库性能优化索引与慢查询场景家政订单模块最容易出现慢SQL的场景我来梳理几个真实案例和对应解法订单列表查询慢用户在我的订单按状态筛选服务者在我的接单按状态筛选。解决方案是给orders表加联合索引(user_id, status, create_time)和(worker_id, status, create_time)。不要单独建三个单列索引联合索引才能真正命中查询。按小区/商圈查订单量运营后台要看某小区订单量解决方案是加area_code冗余字段在订单创建时从地址本带出小区ID直接聚合避免每次JOIN地址表。LBS查询筛选顺带查库Redis GEO筛出候选服务者后不要再用IN查询MySQL的多张关联表而是把服务者ID列表先缓存到Redis如worker:base:{id}存技能和时间片内存过滤后再查MySQL补齐姓名头像。实际压测中这个优化把派单接口响应时间从350ms降到了90ms。另外开启MySQL慢查询日志long_query_time1上线后定期捞日志分析如果订单量日增十万以上order_status_log会涨得很快建议按月份做分区或者定期归档到历史表。5.3 部署与运维的基础配置一个稳定可用的家政后端部署拓扑我建议如下基础配置组件配置建议说明应用服务器4核8G起步2台至少两台做负载均衡避免单点故障MySQL4核8G主从同步业务初期单库够用但是备份必须到位Redis2核4G开启AOF存验证码、幂等键、GEO坐标、短缓存Nginx常规即可配置HTTPS证书、反向代理、上传文件限流定时任务xxl-job或Spring Schedule跑超时订单扫描、结算周期任务、退款重试有几点具体的运维指引HTTPS必须上微信小程序要求所有请求域名必须配置HTTPS并且要在小程序管理后台配置request合法域名、uploadFile合法域名和WebSocket合法域名这一项最容易漏。Nginx上传大小限制client_max_body_size 10m配合后端参数校验防止有人传超大文件打爆服务器。日志必须分级落盘至少保留access_log、error_log、业务日志三个文件线上排查问题没有日志等于瞎子摸象尤其是涉及支付回调、WebSocket推送这种异步链路日志里要带上traceId方便串联。程序发布前执行一遍自动化回归至少覆盖下单-支付-派单-完工-结算-提现整条主链路建议写Shell脚本调核心接口批量测试上线版本频繁的情况下这个成本必须付。写在最后家政源码项目里最容易被低估的四个模块如果要说我在开发过程中最想提醒后来者的就是这些容易被低估的模块报价流程、保姆简历审核、结算系统、服务者实时位置更新策略。技术难度都不高但业务上的坑一个比一个深。报价流程上维修单子从服务者报价到用户确认之间如果设计成等待时间无限长整个订单周期会被拖到无法接受。我最后做成了报价后30分钟内确认超时自动取消并退还定金虽然偶尔有用户抱怨来不及看报价但整体订单库存盘活了很多。保姆简历审核上要做的不是简历表草草存几个字段而是审核流——上传身份证、健康证、服务资质证书甚至可以有雇主评价引用。后期运营会发现保姆单的纠纷率远高于保洁维修厚审核流程是给自己留的防火墙。实时位置更新策略上不要让服务者的工作端每3秒上报一次定位电量和流量受不了。我最后用的是事件驱动节流结合默认每60秒上报一次但如果正处于前往用户家的途中状态把上报间隔动态调到15秒等到达后再恢复成60秒。这样既保证平台能看到关键行程位置又不至于把定位上报做成一笔负担。这些经验很多都是上线后用户教给我的。做同城上门家政Java后端代码难度真不算高高的是对业务每一个环节的敬畏心。希望这份梳理能让你在动手开发或者读源码时少走几步弯路。