木-Star去年有个做家政创业的朋友找我，说想做一个“同城上门做饭”的小程序，用户点一下就能约阿姨上门，后端问我用什么技术栈。我几乎没有犹豫就定了Java——不是因为它最时髦，而是因为这个场景对稳定性、团队上手成本、后续扩展的要求，Java生态都是成熟答案。这个项目从零到上线，踩了不少坑，也总结出很多经验，这篇文章就把整个思路和落地过程完整拆给大家。
如果你想用Java做一个同城上门服务平台，或者正在面试Java后端、想找一个能写在简历上的实战项目，这篇文章应该能给你不少启发。我会从业务分析、技术选型、表结构设计、核心接口实现，到抢单、支付、排障，把我们实际遇到的坑和解决办法都摊开讲。
1. 先别急着写代码，把“做饭家政”这个业务想透
很多开发者的习惯是拿到需求就建工程、写接口，但同城上门服务这种业务，如果不在前期把业务模型理清，后面改起来非常痛苦。做饭家政跟普通电商有本质区别，它卖的是“非标服务 + 人的履约时间”，而不是一件标准品。
1.1 它和外卖、打车有什么本质区别
外卖的核心是“货”和“配送”，货是标准化商品，骑手只负责搬运。打车是“车”和“路线”，司机和乘客的位置都是动态的。而同城做饭家政业务更复杂：服务的载体是“人”，同一个保洁阿姨，今天来你家做两小时保洁，明天去别人家做三小时收纳，服务质量高度依赖个人能力和临场状态。
这种业务对平台系统的要求是：时间撮合 + 地点撮合 + 服务能力撮合。用户选一个时间段，系统要找到那个时间段有空、距离合适、技能匹配的服务人员。所以一开始我们就把整个系统拆成三大块：用户端、服务端（阿姨/师傅端）、运营管理后台。
1.2 平台角色：撮合、履约还是全托管
初期最容易犯的错是把平台想成“全托管”，觉得自己要管培训、管排班、管服务质量。后来我们想清楚了：MVP阶段平台只做撮合 + 交易保障，服务人员可以自注册，平台做资质审核，订单完成后用户线上支付，平台抽佣，服务人员提现。
这个定位直接决定了系统边界。如果是全托管，你需要做排班系统、培训资料系统、服务 SLA 监控，复杂度直接翻倍；而撮合模式只需要围绕“人找服务、服务找人”打造闭环，也就是：
- 用户创建预约订单
- 系统分配或服务人员抢单
- 服务人员上门签到、开始服务、结束服务
- 用户支付、评价
- 平台结算、提现
1.3 最小可行版的范围控制
我们的MVP功能清单是：用户注册登录、服务项目展示（做饭/保洁/收纳）、地址管理、一键下单、订单状态流转、服务人员端接单/开始/结束、支付回调、简单评价。砍掉了优惠券、拼团、会员卡、复杂派单算法、实时定位追踪，这些等核心闭环跑通后再补。
砍需求的时候一定要果断。经常有产品经理想把砍掉的每个功能都说成“必须有”，但技术侧的判断标准很简单：没有它，用户能不能完成一次付费服务？ 如果能，就先不做。这也是Java后端项目能快速上线的原因，单体应用加一套成熟框架，比一上来就拆微服务靠谱得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 后端技术选型：Java生态这套组合拳怎么打
技术选型要结合团队能力、业务阶段、部署成本。我们团队对Java最熟，所以整个后端基于Java生态，工具链选择也尽量“主流且保守”。
2.1 Spring Boot版本与JDK版本怎么选
Spring Boot 3.0之后强制要求JDK 17，Spring Boot 2.7.x支持JDK 8/11/17。我们最终选了 Spring Boot 2.7.14 + JDK 11，没有直接上JDK 17和Spring Boot 3。
原因很实在：第一，很多老牌的支付SDK、短信SDK、OSS SDK虽然已经兼容JDK 17，但总有例外，升级JDK可能会因为模块化限制碰到反射访问异常的坑；第二，团队部分同事对Spring Boot 3的Jakarta EE命名空间不熟，出问题排查成本高。如果你是新项目、团队水平也够，直接用Spring Boot 3和JDK 17完全没问题，但生产环境求稳的话，2.7.x依然是性价比很高的选择。
2.2 MySQL、Redis、Elasticsearch的边界
数据存储我们用了三个，各自分工清晰：
- MySQL：核心业务数据，包括用户、订单、服务人员、结算记