每年毕设季找我咨询最多的就是类似“springboot基于Java的家政服务平台”这种题目。我太熟悉这种标题了它后面经常还带着一个编号比如11775其实就是题目库给项目做的唯一标识。很多同学第一反应是这有什么难的不就是用户、服务项目、订单三个表拼一个CRUD吗真上手之后才发现家政平台真正难的不是登录注册而是“从预约到完工结算”这一段业务链怎么设计得滴水不漏。这篇文章我按自己做这类项目的完整思路走一遍把家政平台的业务分析、技术选型、数据模型、订单状态机、权限安全、部署上线的关键点全部过一遍。准备拿它做毕设的同学、刚学完Spring Boot想找真实项目练手的同学应该都能从中拿走点能直接用的东西。1. 家政平台难的不是CRUD是订单履约的业务闭环很多同学拿到“家政服务平台”这个题目第一件事就是打开数据库工具建表user表、order表、service表然后就开始写增删改查。等到写了一半发现登录注册和列表展示都做完了但平台真正核心的“找阿姨—下单—上门—完工—结算”这一整条链根本串不起来。这不是个例我带过的项目里至少有三分之一是这种状态。1.1 先站在三种角色的角度想清楚需求家政平台至少有三类用户普通雇主、家政服务人员保洁、月嫂、育儿嫂、家电清洗师傅等、平台管理员。如果题目要求更复杂一点还可以加一个“门店/家政公司”的角色也就是机构入驻。角色想不清楚功能菜单就是乱堆的。雇主关心什么附近有哪些服务、价格透明不透明、阿姨靠不靠谱、预约时间能不能改、服务完怎么投诉。家政阿姨关心什么单子多不多、客户地址在哪、服务时间是否和其他单冲突、完工后能不能及时结算。管理员关心什么阿姨入驻审核、订单状态有没有异常、用户投诉怎么处理、平台每天成交多少单。这三种诉求合起来基本就是系统的功能模块清单。1.2 一条家政订单从产生到结算经历的环节一个正常订单的完整链路是这样的用户浏览服务项目 → 选服务、选时间、填地址 → 提交订单并完成支付或者先下单后支付→ 平台派单或阿姨接单 → 阿姨上门服务 → 用户验收/确认完工 → 平台结算给阿姨 → 用户评价。每一步都应该对应后端的一个独立接口和状态变更而不是简单往订单表插一条记录。我帮人review过代码发现对方只做了“提交订单”和“订单列表”两个接口中间接单、开工、完工、评价全都没有一问才知道他把家政平台做成了“信息发布站加留言板”相当于只完成了题目一半的内容。面试或答辩时老师最喜欢问的就是用户下单之后你怎么保证有阿姨接单用户取消了怎么办服务完成后钱怎么结算这三个问题答不上来前面堆再多功能也白搭。1.3 最容易翻车的地方把平台做成“信息展示站”还有一个常见误区是贪多求全。导航菜单恨不得堆十几个会员等级、积分商城、拼团砍价、社区帖子唯独订单流程没闭环。这类系统演示的时候看着热闹一进到核心业务就露馅。我自己惯用的方法是把功能拆成必做清单和选做清单。必做清单是用户端服务分类、服务列表、服务详情、预约下单、订单中心、取消订单、评价阿姨端接单中心、我的排期、我的收入管理端阿姨审核、服务项目管理、订单管理、投诉处理。选做清单再往上加收藏、优惠券、推荐排序、统计报表。如果题目描述里没有明确要求先把必做清单跑通最后有时间再补选做内容。业务闭环优先这是这类项目能不能讲清楚的核心。2. 技术选型Spring Boot这套组合为什么是稳妥答案2.1 版本与搭配先给结论如果你只想稳稳当当把项目跑通Spring Boot 2.7.x JDK 1.8 MyBatis Plus MySQL Redis 是最容易上手的组合如果你想让技术栈看起来更新一些用 Spring Boot 3.x JDK 17。前两年我还会犹豫要不要推 3.x现在 Spring Boot 3 已经足够稳定只是很多旧跑教程还停留在 2.x照着抄容易踩到 javax 和 jakarta 包名变化的问题。为什么选 Spring Boot 而不是 Spring MVC SSM因为Spring Boot的自动配置把大量繁琐的XML配置收敛了你可以把精力放在业务代码上。MyBatis Plus则解决了我最不想写的单表CRUDBaseMapper里自带的selectById、updateById已经覆盖大部分场景复杂查询再手写XML或注解SQL。网上很多教程让你用JSP但家政平台这类偏演示的系统做成前后端分离会更舒服后端只出JSON接口前端用Vue或者微信小程序演示时业务边界清楚答辩也更好讲。2.2 中间件分工整个项目需要的中间件其实很少MySQL、Redis最多加一个对象存储。MySQL存用户、订单、服务项目这些核心数据。Redis主要做三件事第一存登录Token让服务端能随时把某个登录态踢掉第二存验证码天然支持过期时间第三做抢单场景的分布式锁后面讲派单逻辑时会详细说。文件方面日常开发时把头像、服务实拍图、资质图片直接丢在本地磁盘就行部署到服务器也是同一套方案。但如果项目描述里写了“对象存储”想加点新意我会把存储逻辑抽象成一个接口本地磁盘和MinIO各写一个实现配置切换。不要一上来就引入Nacos、Sentinel、OpenFeign那套微服务全家桶单机项目引入微服务除了拖慢启动速度外没有任何业务收益。真要写亮点分布式锁、延迟处理、状态机这些反而更实在也更容易在答辩时讲明白。2.3 工程结构与分包很多同学的代码全堆在Controller里一个方法写几百行能跑但完全没法维护。工程结构本身不产生功能但它决定了你排查问题、加功能的速度。我习惯的项目结构是com.example.housekeeping ├── common // 统一返回体、统一异常、常量 ├── config // 配置类Redis、MyBatis Plus、跨域等 ├── controller // 接口层 ├── service // 业务层 ├── mapper // 数据访问层 ├── entity // 数据库对应实体 ├── dto // 接口入参/出参 └── util // 工具类Controller只做参数接收和结果包装Service层写业务规则Mapper层只写SQL。如果订单和支付逻辑特别重把Service层继续拆成订单主流程、状态机服务、结算服务都行但课设阶段拆到Service一层已经足够。实际写代码时我一般把下单、取消、派单这类会改变订单状态的操作独立成方法不让它们散落在不同的Controller里。2.4 想拿Spring Boot当亮点先把自动装配讲明白聊天时经常有人问“Spring Boot自动装配原理是什么”。这块其实不难核心是EnableAutoConfiguration注解。Spring Boot启动时会扫描AutoConfiguration.imports文件里注册的配置类再根据ConditionalOnClass、ConditionalOnMissingBean这类条件注解决定是否装配某个Bean。你平时几乎不用new RedisTemplate、DataSourc就是这个机制在背后工作。如果简历上写了“熟悉Spring Boot”我建议至少能把这个流程说清楚。别只回答“因为用了Spring Boot所以方便”否则面试官一个追问就露馅。家政平台里的数据源、Redis、参数校验、Jackson这些基础能力都是靠自动装配准备出来的理解之后你排错时也会更有方向。3. 数据模型设计这些表和字段不能省3.1 用户与权限模型用户表不要为了省事把雇主和阿姨塞进同一张表然后留一堆空字段。我建议把公共信息放user表比如id、手机号、密码、昵称、头像、状态、创建时间。角色用user_role关联阿姨的详细档案单建一张表。这样同一个账号既是雇主又是阿姨也能支持得住现实里确实有人是自己用过服务后入驻平台的。简单项目用role字段也能跑但这种设计一旦遇到多角色就非常尴尬。最稳的模型是用户-角色-权限三层再加关联表。对课设来说用户-角色关联已经够了权限如果只想用Spring Security注解直接给角色字符串就行不用把权限表建得很重。关键是别把角色数组塞进一个varchar字段查询和维护都是灾难。3.2 服务项目与规格服务项目表相当于平台上的“商品”字段包括服务分类、服务名称、服务简介、单价、计价单位、服务时长、主图、上下架状态、排序。价格字段建议用decimal(10,2)不要在数据库里存“100元/次”这种带单位的字符串统计和比价都会出问题。如果服务包含可选项比如保洁项目可以加“擦玻璃”“深度除螨”这种增值项我会再建一张服务加项表或规格表。下单时选了几个加项对应生成订单子项。课设阶段做单服务字段也能跑但答题时你说得出“为什么用子表而不是逗号拼接”这道数据模型题就给你加分了。3.3 阿姨档案阿姨/服务人员表是家政平台最不能省的一张表。字段建议包括真实姓名、手机号、身份证号、从业年限、技能标签、服务区域、期望薪资、工作状态、入驻时间、审核状态、审核人、审核时间。为什么一定要有审核状态因为家政服务涉及人身和财产安全阿姨入驻必须先过管理员审核审核通过才能收到预约单。这个字段既是业务要求也直接关联权限待审核的阿姨在阿姨端看不到抢单池。技能标签尽量别用逗号拼成一个字段虽然简单项目这样也能应付但按标签搜索服务人员时会非常痛苦。我一般会建一张技能标签表再建一张阿姨技能关联表如果不想加表用JSON数组存也行但至少要能支持按标签模糊搜索。身份证号属于敏感信息入库前用加密算法处理展示时打码。3.4 订单主表与金额快照订单主表是整条业务链的载体。基础字段要有订单号、用户id、服务人员id、服务项目id、服务开始时间、服务时长、服务地址、联系人、联系电话、总金额、优惠金额、实付金额、支付状态、支付流水号、订单状态、取消原因、完成时间、评价状态。订单号不要用数据库自增主键直接展示给用户建议生成一个“日期随机数”格式的业务订单号客户和客服沟通时好报单。金额快照也很关键订单表里要冗余一份服务名称、价格、时长避免服务项目以后改价影响历史订单。如果一次预约包含多个服务可以拆order主表和order_item子表主表存用户、服务人员、总金额、状态子表存每一项明细。课设阶段允许简单点但能讲出拆单思路是比闷头写CRUD更高级的设计。3.5 索引、事务与“拆单”思维订单表的查询维度主要来自用户、服务人员、状态和时间。索引至少覆盖user_id、worker_id、status、create_time。联合索引要把最频繁的筛选条件放前面比如“查询某个阿姨时间段的待接单列表”建(worker_id, service_time)联合索引就很实用。事务方面下单时要做的事情不止一条Insert可能要扣减阿姨的可接时间段、生成订单、处理支付流水这些必须包在一个Transactional里。但特别提醒不要在事务里发短信、调外部HTTP接口否则事务回滚了短信却发出去了用户很快会找上门。我见过不少真实项目踩过这个坑把异步通知、短信这些都写在事务中间其实完全属于考虑不周。4. 订单状态机与派单逻辑整条业务链的神经中枢4.1 状态定义与转换表订单状态我一般设计成一组枚举待支付、待接单、已接单、服务中、待验收、已完成、已取消、退款中、已退款。不要用0、1、2这种魔法数字硬编码在业务代码里写个OrderStatusEnum字段含义一目了然switch也写得更放心。状态不能随便跳每次都校验当前状态是否允许变成目标状态。整理成表格大概是这样当前状态允许的动作目标状态待支付支付待接单待支付取消已取消待接单平台派单 / 阿姨抢单已接单待接单超时系统取消已取消已接单阿姨开始服务服务中服务中用户确认完工待验收待验收用户验收通过已完成已完成发起售后退款中退款中退款完成已退款把这个表画清楚Service层的if/else就已经成功一半了。很多项目出现“已取消的订单还能变成已完成”这种离谱状态就是因为没有状态机约束。4.2 管理员派单、抢单、自动派单市面上家政平台的派单方式大致三类。第一类是管理员派单后台把订单手动指派给某个阿姨实现最简单课设足够。第二类是阿姨抢单把订单发布到阿姨端大家点“我要抢单”。第三类是自动派单按距离、评分、接单量排序把订单推给TopN的阿姨更接近真实商业场景。抢单场景有个经典并发问题两个阿姨同时抢同一单不能两个人都“抢到”。解决思路是两层配合先拿Redis分布式锁key可以是order:accept:{orderId}拿到锁的人再去更新数据库更新语句同时带状态条件UPDATE order SET status 已接单, worker_id #{workerId} WHERE id #{orderId} AND status 待接单 AND worker_id IS NULL如果影响行数为0说明订单已经被别人抢走释放锁后返回“手慢了”。这套组合既能防止两个人同时查到待接单状态也能避免超发。答辩时能把这个并发场景讲明白比空谈“并发安全”有力得多。4.3 取消、超时与退款取消订单要分角色。用户未支付前可以随时取消支付后、阿姨接单前取消可能要扣违约金阿姨接单后如果临时取消要记录取消次数取消率太高的阿姨后台应限制抢单。这些规则写在后端不能只靠前端按钮挡。超时未接单是另一个高频场景。提交订单后如果10分钟没人接单系统要自动取消并退款。最简单的可靠方案是写一个定时任务每分钟扫一次“待接单且超过超时时间”的订单批量更新状态并触发退款流程。再高级一点可以用延迟队列但对课设来说定时任务已经足够稳定而且老师说“这是一个近实时扫描的兜底方案”反而显得你考虑得实际。4.4 阿姨时间冲突校验与并发控制阿姨同一时间段只能服务一单。最基础的做法是接单时校验查阿姨已有的订单中有没有服务时间重叠的记录。为了更稳可以在数据库层给(worker_id, service_time)建联合唯一约束但前提是service_time能表示到分钟级或小时级的时间段。如果项目要求并发度高一点Redis分布式锁加数据库唯一约束一起上如果只是课设在业务代码里查一次重再插入也能防住大部分场景。我一般建议用“乐观锁版本号状态条件更新”这个思路而不是把整个表锁住。关键不是代码多复杂而是你知不知道这里会发生并发问题以及用什么手段去兜底。5. 认证授权与接口安全多角色系统不能裸奔5.1 密码、登录态与验证码密码绝对不能用MD5直接存。用BCryptPasswordEncoder这类自适应哈希算法同样的密码每次加密的结果都不一样数据库泄露也不容易被反查。登录成功之后签发JWT再把token存一份到Redis过期周期设为7天。用户改密码、被管理员封号时把Redis里的token删掉就能强制下线这就是用Redis管理登录态的好处。登录接口还要做验证码和频率限制。家政平台有手机号登录、短信验证码登录不做频控会被刷短信话费直接烧掉。短信平台的密钥不能明文写死在代码里配置到yaml或环境变量中。这些看起来都是小事但真实线上项目第一步安全审查就是看这些东西。5.2 多角色权限的拦截策略Spring Security加JWT过滤器是标配。在SecurityConfig里配置免登录路径比如首页、服务项目列表、阿姨公开页其余接口必须带有效token。方法级别用PreAuthorize(hasRole(ADMIN))这类注解来控制更细的权限审核阿姨、后台派单只能管理员接单只能是阿姨角色评价只能是下单用户。越权漏洞大多出在“完全信任前端传参”上。用户想查询自己的订单详情接口入参给了orderId后端不要直接拿orderId查出来返回而应该先从token解析出当前登录用户id再在SQL里加AND user_id #{当前用户}校验不通过就拒绝。前端菜单隐藏不是权限控制别人直接拿接口工具调一下就把你打穿了。5.3 数据脱敏、金额与文件上传手机号在列表页返回时脱敏成139****1234完整号码只在有权限的详情接口里返回。金额字段一律用BigDecimal前端展示时toString后端计算用BigDecimal运算。Java浮点数做过金额计算的人都知道double算完会出现“0.10.2不等于0.3”这种尴尬问题。文件上传方面家政平台经常要传身份证照片、资质证明和合同PDF。至少做三件事限制后缀名、限制文件大小、用UUID重命名文件名防止有人上传jsp或php脚本拿下WebShell。文件类型不能只信Content-Type头服务端还要用Magic Number做二次校验也就是读文件头几个字节判断真实类型。热词里专门有人问“上传PDF文件时XSS攻击”怎么处理其实就是文件名和内容校验没做好。5.4 越权家政平台里最容易忽略的漏洞横向越权是我每次讲安全都要提的话题。A用户能改B用户地址、能看B用户订单这不是功能问题是接口设计缺陷。通用套路是凡是操作对象属于某个用户的接口后端都要做属主校验凡是列表查询都要带Owner条件。比如“修改预约时间”这个接口除了校验订单状态是否允许修改还要校验订单属于当前登录用户。写完接口自己拿两个测试账号交叉请求一遍A账号能否操作B账号的数据这是成本最低的渗透测试。我见过很多项目功能齐全却在答辩时被老师现场用两个账号发现越权场面非常尴尬。6. 前后端联调与微信小程序从接口约定到微信生态6.1 统一返回体前后端对接最怕接口风格混乱。我一般定一个Result 返回体结构是code、message、data。成功时code200失败时使用业务码比如400参数错误、401未登录、403无权限、500系统异常。Controller全部返回Result全局异常处理器把异常转成统一结构避免系统默认的一长串报错直接抛给前端。分页用单独的PageResult 包含list、total、pageNum、pageSize。前端拿到这套结构后封装一个请求工具几乎不需要每个接口单独判断字段。统一返回体看似不起眼但它直接决定联调效率。6.2 后端参数校验后端入参必须校验不能依赖前端。NotBlank、Email、Pattern、Min、Max这些校验注解放在DTO的字段上Controller方法加Validated一个注解就搞定。前端校验是体验优化后端校验是数据底线。我见过不少项目前端做了完整校验后端连if(phone null)都懒得写结果绕过前端直接POST乱数据数据库里全是脏数据。订单地址字段如果超长后面打印服务单据都会出问题。参数校验是开发成本最低的质量防线别省。6.3 文件上传与对象存储抽象家政平台需要上传的图片不少用户头像、服务实拍、阿姨资质证明。开发环境直接存本地磁盘配置一个ResourceHandler把/upload/**映射到本地目录部署到服务器也是同一套思路。如果想写“对象存储”这个亮点我会把文件存储封装成FileStorageService接口本地磁盘实现一个MinIO再实现一个通过配置项切换。这样不会卡在搭建MinIO的环境上还能体现你理解“存储抽象”而不是写死某个路径。文件名统一用UUID重命名目录按日期分一下避免一个目录下塞几万个文件后面管理非常痛苦。6.4 小程序登录与模拟支付家政平台如果要做小程序端登录流程是wx.login拿到code后端拿code调用jscode2session换取openid再绑定手机号创建账号。真实微信支付需要商户号、证书、回调验签个人开发者很难快速搞定。课程设计阶段我建议做成“模拟支付”用户点击支付后弹窗确认后端把支付状态置为已支付并在支付流水表里记录一笔mock流水。业务闭环不要断但要在答辩时明确说这是模拟支付。如果真想接真实微信支付回调验签一定要写对回调处理一定要幂等否则微信重复回调几次就可能把订单状态改错。支付是敏感环节规则上不能绕过微信支付监管就按照官方文档一步步来。6.5 消息通知怎么做才不扰民订单状态变化可以给用户推送微信订阅消息。订阅消息必须用户主动授权授权次数有限所以不要什么都推。我见过项目把取消、退款也做成订阅消息用户点了一堆授权消息下发率反而很低。最后只保留两个关键节点阿姨已接单、服务完成提醒。阿姨端可以在小程序里做订阅消息也可以在服务里做站内信。家政场景的阿姨不一定时刻看小程序所以短信或电话通知更可靠但成本高课设阶段用站内信加“轮询我的待接单”就够了。把消息通知想成一个低频但关键触达手段别当广播用。7. 构建、部署与演示前准备一台2核4G服务器怎么稳住全场7.1 单机部署拓扑一套足够稳定的部署方案是Nginx Spring Boot jar MySQL Redis全部装在一台2核4G服务器上。前端打包成静态文件放进Nginx的html目录Nginx把/api/路径反向代理到localhost:8080再开启gzip压缩。这样一个域名同时承载前端和后端结构清晰以后想加负载均衡也方便。部署顺序是先安装MySQL和Redis再启动后端jar包最后配置Nginx。很多项目用前后端分离却把前端静态文件也扔进后端静态资源目录里虽然能跑但边界不清晰。按上面的方式部署排查问题时会舒服很多。7.2 打包与启动参数后端打包命令很简单mvn clean package -DskipTests生产环境启动建议这样java -jar -Xms512m -Xmx512m \ -Djava.security.egdfile:/dev/./urandom \ housekeeping-server.jar \ --spring.profiles.activeprod为什么加-Djava.security.egdfile:/dev/./urandomLinux上JVM的随机数种子初始化有时会很慢加上这个参数能明显缩短启动时间。JVM堆内存给512M到1G就够2核4G的机器别贪多剩余内存要留给MySQL和操作系统。配置上使用application-prod.yml里面连正式数据库和Redis日志输出路径别写在项目根目录统一放到/var/log/app下方便排查。7.3 启动失败排查常见的启动失败原因排行MySQL连不上、Redis连接超时、端口被占用、时区不对导致时间差8小时。看启动日志时直接看最下面一行“Caused by”不要从头贴几百行让人猜。很多问题其实就是数据库密码填错了。时区问题很隐蔽。JDBC连接串要加serverTimezoneAsia/Shanghai否则存进去的时间比实际少8小时。Redis连接池超时时间设短一点比如2秒避免某个服务不可用时整个接口卡上一分钟。服务器上遇到启动失败先确认三条命令端口是否占用、MySQL能否连通、Redis能否ping通。7.4 数据库查询优化与缓存更新课设项目不要一上来就做性能优化先把明显慢的SQL解决掉。订单列表按创建时间倒序给create_time建索引服务列表按分类查询建分类和上下架状态的联合索引统计报表这种聚合查询用一个汇总表或定时统计表不要每次实时count所有订单。缓存优先缓存“服务项目列表”“首页Banner”这种读多写少的数据。Redis缓存后要处理更新策略后台改价格或上下架时主动删除缓存等下次请求再回填。不然就会出现“前台价格改了但缓存还是旧数据”的尴尬情况。如果用了本地缓存还要考虑多实例时数据不一致的问题不过单机部署基本不用操心。高并发接口可以先用JMeter做个简单压测但别乱打。测试前先理清楚哪些是高频接口比如首页列表、搜索服务、订单详情低频接口压测的意义不大。响应时间突然飙升时先查慢SQL日志和Redis连接数不要直觉性地加服务器大概率是查询没走索引。7.5 演示前的验收清单上线演示前至少做三件事。第一MySQL每天凌晨用crontab备份一次mysqldump导出的文件保留最近7天。第二把配置文件里的密码改成环境变量方式不要裸写在yaml里提交。第三完整自测一遍核心链路注册登录、浏览服务、下单、管理员审核阿姨、阿姨接单、用户确认完成、评价全流程走通。现场演示最容易翻车的不是功能缺失而是演示账号权限不对、测试数据太丑、订单状态空荡荡。我一般会准备一个专用演示账号里面预置几条不同状态的订单待支付一条、待接单一条、已完成一条、退款中一条让老师一眼就能看到状态流转。另外提前把局域网或公网地址准备好现场临时连数据库调试会非常狼狈。最后说点我的个人体会。做这类“Spring Boot Java XX平台”的项目代码量不是关键业务闭环才是。你能把订单状态机、并发抢单、多角色权限、事务与数据一致性这几个点讲清楚比多写三个无用的模块有用得多。答辩时老师问“你为什么这么做”你答“因为用户可能会同时抢单所以用了Redis锁加数据库状态条件更新”比你答“教程上就是这么写的”好一万倍。如果时间实在紧张优先把订单主流程的每一步都做成可演示状态再补边角功能。项目可以没有花哨界面但不能没有清楚的业务逻辑。