基于SpringBoot的会所产后护理系统设计与实现——三端业务闭环解析-北京尧图网络

我做区域管理这块有一段时间了接触过不少类似的预约服务类系统今天来聊聊一个很适合毕业设计的选题——基于SpringBoot的会所产后护理系统。这个系统做的是月子会所、产后康复中心的业务线上化覆盖三类使用者会所管理人员、护理人员、入住的宝妈客户。三端共用一套SpringBoot后端接口管理端做资源与订单管理护理端做护理执行记录客户端做预约、查看报告和账单。业务链路完整角色权限清晰做出来既有演示效果又能覆盖面试常问的后端知识点。如果你正打算做这个方向或者已经拿着差不多的要求在苦恼从哪下手这篇应该能帮你把整体思路理顺。1. 为什么产后护理系统是毕设的好选题1.1 这个行业到底缺什么系统先说行业背景。现在越来越多的月子会所、产后护理中心在扩张但很多门店的管理方式还停留在微信群里沟通 Excel 表格排班纸质记录单的阶段。护理师交接班靠口头说客户问一句我家宝宝今天喂了几次奶护士要去翻记录本才能答上来。管理者想知道今天哪些房间空着、哪个护理师手里活多、这月套餐卖出多少得靠人工去汇总。这些问题落到底层就是一个典型的CRUD加业务流程管理系统客户资料管理、护理记录管理、订单与套餐管理、房间与排程管理、统计报表。它不像电商系统那样要扛高并发也不像算法项目那样需要数学功底但它把软件开发里最常用的东西都覆盖了——需求分析、表结构设计、REST接口、权限控制、前端页面交互。这正是毕业设计最需要的完整度。1.2 三端设计带来的答辩优势三端是这个系统最大的亮点这也是标题里特意点出来的原因。管理端、护理端、客户端分别对应三种完全不同的使用场景管理端会所店长、运营人员使用功能最全包括员工管理、套餐管理、房间管理、订单审批、数据统计护理端护理师使用功能聚焦在日常任务比如查看负责的客户列表、提交护理记录、查看交接班提醒客户端宝妈或者家属使用功能是服务视角的比如在线预约、查看护理报告、账单明细、套餐余次。三个端业务上共享同一套后端数据但UI和权限完全隔离。这就让系统的复杂度刚好卡在能体现工作量、又不至于收不住的位置上。答辩的时候你能很清楚地讲出我是怎么通过角色去划分菜单和接口权限的数据是如何在不同端之间流转的。这一串讲下来比单纯说我做了一个管理系统要有说服力得多。1.3 课题的扩展空间这个题目的扩展性也值得说。基础版是传统Web管理后台加小程序端如果你学有余力可以往上加带时间戳的健康趋势图表、护理项目预约的排期冲突校验、套餐剩余次数自动扣减逻辑。这些扩展点不需要换技术栈都是在现有框架上往深了做属于低风险加分项。我们后面聊核心模块时会把其中几个具体展开。2. 技术选型的取舍为什么是SpringBoot组合拳2.1 后端骨架SpringBoot是这类项目的默认答案但选它不只是因为大家都在用。它的自动配置特性让开发阶段能省掉大量XML配置内嵌Tomcat让部署变成打一个jar包扔服务器就能跑这对毕设来说是非常友好的。我建议具体版本选SpringBoot 2.7.x稳定资料多和Spring Security、MyBatis-Plus的兼容性都经过大量项目验证比追到3.x去踩模块迁移的坑划算得多。持久层我用的是MyBatis-Plus而不是原生MyBatis。理由很实际单表CRUD、分页查询、逻辑删除、自动填充这些是毕设里用到最多的功能MyBatis-Plus一个BaseMapper全部搞定。你可以把精力省下来去处理真正复杂的部分——比如护理计划的状态流转、预约时间段的冲突校验。如果哪天真需要多表复杂查询写XML也一样支持它不限制你的发挥。2.2 三端前端怎么做前端是三端但不需要三套完全独立的前端工程那样工作量太大了。我的建议是分两种路线管理端用Vue加Element UI组件库做一个独立的后台管理项目。护理端和客户端合并思路走小程序路线用微信小程序开发或uni-app。为什么这样设计管理端使用场景是PC电脑需要表格、弹窗、树形控件这类重交互组件护理端和客户端的实际使用场景是手机小程序扫码即用、免安装对会所场景来说比原生App现实得多。如果你不想同时维护Vue和小程序两套语言也可以三个端全用uni-app——一套代码编译出H5和小程序管理端用H5跑在浏览器里。这样前后端交集更少但要注意uni-app在复杂表格上的表现力确实不如Element UI顺手。我的个人习惯是管理端独立、两端合一折中方案工作量可控且演示效果好。2.3 认证与权限JWT加拦截器已经够用很多同学看到三端就慌了觉得权限会很难。其实这套系统权限模型是标准的RBAC用户表、角色表、菜单表、用户角色关系表、角色菜单关系表。用户登录后返回JWT令牌前端每次请求放header里后端写一个拦截器解析令牌并加载用户权限。完全不需要上Spring Security全套过滤器链甚至可以说对于这个体量的系统用Spring Security反而增加学习成本。手写一个拦截器配合注解或路径前缀做权限判断代码量不大逻辑你自己完全掌握答辩时老师问起来你能把每一步都说清楚这比用了框架但讲不明白要加分。当然如果你熟悉Spring Security也完全可以上我只是建议以能讲清楚为前提。3. 核心业务模块拆解一套流程走通预约到离所3.1 客户档案与入住评估这个系统的业务起点是客户预约。客户在小程序端提交预约申请选择心仪的服务套餐、预计入住时间填写分娩医院和预产期。管理端收到预约后做审核审核通过则分配房间和对应护理师。这里有一个细节需要提前设计好房间的状态。房间不是简单的空闲/占用二态。因为产后护理有明确的周期通常会所按28天或42天接待房间会在空闲、已预订、在住、打扫中这几种状态之间切换。我建议加一个房间状态变更流水表每次分配或释放房间都记录一条流水管理端首页展示的当前可售房间数就是通过统计流水表实时计算出来的。这既避免了并发操作下状态覆盖的问题又给统计报表补充了数据源。入住当天护理师或管理端会录入客户的身体评估信息——包括产妇的伤口恢复情况、恶露情况、情绪状态以及宝宝的体重、黄疸值、喂养方式等。这些内容要支持记录历史版本因为护理评估是动态变化的护理师每次查房都要更新而客户端看到的应该是趋势中的变化。所以评估表建议拆成基础档案表历次评估表前者记录过敏史、分娩方式等不变信息后者记录每次评估结果。3.2 护理计划与护理执行记录护理计划是护理端的核心。系统需要内置护理套餐对应的标准计划模板比如产后康复套餐包含子宫复旧护理、乳腺疏通、中药洗头等项目新生儿照护套餐包含洗澡、抚触、脐带护理、黄疸监测等。模板化的好处是护理师给客户制定计划时可以直接引用模板再微调生成这个客户专属的护理计划单。执行记录是另一个重点。护理师每完成一项护理要提交一条执行记录包含执行人、执行时间、客户反馈、异常标记。异常标记尤其重要——比如护理时发现产妇体温偏高记录里要有一个字段把它标成异常后端收到异常标记后自动在管理端生成待处理提醒。这一小段逻辑看似简单但它把业务数据和管理动作联系起来了是代码讲解里很好的一个点。这套执行记录的实时性也是三端数据联动的保证护理端一提交客户端马上能看到今天的护理报告管理端则能看到各护理师今日已完成任务数。不用刷新靠的是前端轮询或者接入WebSocket推送。毕设里用轮询足够每30秒拉一次当前在住客户的最新执行记录性能上完全没问题实现也更简单。3.3 套餐购买、预约排期与账单套餐订单属于交易核心表设计上要特别注意金额精度和状态一致性。我建议订单固定用decimal类型存金额不允许用double或float。套餐购买时生成主订单同时生成子订单明细——比如一个28天经典套餐里包含了30次月子餐、20次伤口护理、不限次的宝宝喂养记录。子订单明细要记录总次数、已用次数、剩余次数客户端展示剩余次数就是从这查的。预约排期用来处理护理项目的时间冲突。比如产后瑜伽室一天只有几个时段两个客户不能同时预约同一个时段。实现时单独建一张预约表字段包括客户ID、护理项目ID、预约日期、时间段、状态。新增预约时先查该日期时间段内是否有已生效的预约记录有就提示冲突。这套检查用一条带条件的count查询就能完成但注意要把已取消状态的记录排除掉否则会出现取消后不能重新预约的老大难问题。账单部分平时不太显眼但最容易在答辩时被追问。我的做法是订单产生的应缴金额和客户每次的缴费记录分开存每次缴费生成一张流水关联到订单。客户端的账单页展示的是订单金额、已缴金额、剩余待缴管理端的财务视图则按流水汇总每日营收。这样的设计把总额流水和明细证据都保留住了逻辑清晰也方便后续做数据核对。4. 数据库设计关键表结构与踩过坑的设计点4.1 核心表清单一套可运行的产后护理系统下面这些表是骨架。基于我实际开发时的设计给你一份可以直接参照的表清单模块表名关键字段说明用户与权限sys_user、sys_role、sys_menuuser表加type字段区分管理/护理/客户角色客户档案customer_info姓名、预产期、分娩医院、过敏史、客户状态评估记录customer_assessment关联客户ID记录评估类型、评估项JSON、是否异常房间管理room_info、room_status_log房间号、楼层、套餐类型、状态、状态变更流水套餐与订单package_info、service_order、order_item订单表存总金额子表存分项次数与已用次数护理计划nursing_plan、nursing_plan_item计划头与计划明细分离明细关联护理项目护理执行nursing_record执行人、客户ID、项目ID、执行结果、异常标记预约排期appointment客户ID、项目ID、日期、时间段、状态缴费流水payment_record关联订单ID、金额、支付方式、操作人这些表看起来多但彼此关系并不复杂。核心一条线是客户入住后生成护理计划护理计划下产生执行记录同时房间状态和订单状态随之更新。建议画一张简单的ER图放进设计文档里图表永远比文字好讲。4.2 三个容易被忽略的字段设计细节第一个是逻辑删除字段。所有业务表统一加deleted字段默认0删除置1数据库查询统一带deleted0条件MyBatis-Plus提供TableLogic注解可以自动完成。为什么毕业设计也建议做逻辑删除因为实际演示时你很可能要误删一条测试数据如果硬删除关联的护理记录会变成孤儿数据演示中途数据对不上就很尴尬。第二个是状态字段用tinyint而非varchar。待审核、审核通过、入住中、已离所这类状态我建议统一存数字0、1、2、3代码里用枚举或常量类去映射。好处是数据库更紧凑、查询更快而且避免不同端写入时的中英文状态不统一。要展示中文时由后端转成前端需要的文本不要让数据库存文案。第三个是时间字段的统一。预约时间、护理时间、缴费时间建议全部用datetime类型并且由后端代码统一填充不要依赖数据库的now()。这样写单元测试时可以手动指定时间方便构造场景。给数据库加自动填充的坑是如果你要批量导入演示数据时间字段会变成当前时刻演示本周营收统计时数据就串了。数据导入时用固定时间区间统计图表才好看。4.3 一个推荐的自定义SQL场景普通列表查询用MyBatis-Plus的Wrapper就很顺手了但管理端首页的统计需要一点SQL技巧。比如今日护理任务完成率这个指标涉及两张表我的实现思路是统计昨天到今天的护理记录数量除以当日应执行护理项目数量应执行数量来自护理计划明细要求状态是待执行或已完成。这用两条查询在Service层里汇总就行不需要在数据库层面做复杂关联。但如果要按周展示每个护理师的工作量趋势我建议直接用一条GROUP BY的SQL按date(execution_time)和nurse_id分组统计查询效率高SQL逻辑也容易讲清楚。5. 三端联调的关键实现细节5.1 接口设计规范与统一返回结构三端共用后端接口规范必须一开始就定好否则后面联调会反复返工。我强烈建议所有接口统一返回一个结构体包含状态码、消息、数据三个字段比如{ code: 200, message: success, data: {} }后端用泛型类定义好所有Controller方法都返回这个类型。前端三个端分别封装自己的请求库统一取data字段渲染页面遇到code ! 200时统一弹出错误提示。这样做最大的好处是后端改接口异常处理逻辑时三个端不用跟着改。我在一个项目里就因为一开始没有统一返回结构导致改了五六处前端判断逻辑后面专门花时间重构成了这个规范。接口路径上建议按模块加前缀区分来源比如管理端接口统一/admin/**护理端接口统一/nurse/**客户端接口统一/api/**。这样权限拦截器做路径匹配时非常省事——只要判断请求路径前缀对应哪种角色即可不用每个接口单独配置权限注解。5.2 状态流转的代码写法业务里最容易被问到的就是状态流转设计。以客户状态为例待入住、在住、已离所。我建议不要在Service里散落一堆if判断而是统一封装一个状态流转方法。举个例子办理入住时的核心检查逻辑public void checkIn(Long customerId, Long roomId) { Customer customer customerMapper.selectById(customerId); // 只有待入住状态才能办理入住 if (customer.getStatus() ! CustomerStatus.PENDING_CHECK_IN) { throw new BusinessException(当前客户状态不允许办理入住); } // 房间必须处于空闲或已预订状态 Room room roomMapper.selectById(roomId); if (room.getStatus() ! RoomStatus.FREE room.getStatus() ! RoomStatus.RESERVED) { throw new BusinessException(该房间当前不可入住); } customer.setStatus(CustomerStatus.IN_HOUSE); room.setStatus(RoomStatus.OCCUPIED); // 更新客户入住房间写房间状态变更流水 customer.setRoomId(roomId); customerMapper.updateById(customer); roomMapper.updateById(room); roomStatusLogMapper.insert(new RoomStatusLog(roomId, RoomStatus.OCCUPIED)); }这个方法的巧妙之处在于每次状态变更都是检查前置状态更新目标状态记录变更流水三步走。不管后端从哪个接口触发状态都不会跳变。答辩时你可以顺着这个方法讲清楚为什么客户没有在住就不允许提交离所申请为什么离所后房间会自动变为打扫中。5.3 客户端数据可见范围的控制三端共用一个客户表时最容易出安全问题的是数据越界——护理端不该看到全所所有客户客户端更不能看到别人的预约记录。我的建议是在Mapper查询时强制带上数据范围的过滤条件。举例说明护理端查询我的今日任务SQL条件必须包含nurse_id 当前登录用户ID而不是前端传什么就查什么。客户端查询我的订单同理登录后从token里解析出user_id后端直接据此拼接查询条件不需要前端传客户ID。这个叫服务端数据隔离是保证三端数据安全的基础。有同学喜欢在前端做菜单隐藏来实现权限这是绝对不行的——前端隐藏只是一层UI控制恶意用户直接调接口就能越权。所有人的接口权限、数据范围都必须在后端强制校验前端隐藏只是更好的用户体验而已。答辩时老师大概率会问你怎么保证护理师看不到别的客户的记录能回答出后端强制按用户ID过滤这道题就稳了。5.4 管理端的统计展示思路管理端需要展示的核心指标大致有当前在住客户数、今日新增预约数、房间入住率、本周营收、各护理师今日执行任务数。这些指标的数据来源分别是客户表、预约表、房间表、缴费流水表、护理记录表。我建议写一个专门的总览Service用一个聚合方法分别调用各Mapper的统计查询返回一个Map或VO对象给前端。既然管理端用了Element UI图表可以直接用ECharts。不需要做多复杂的配置柱状图展示最近一周营收趋势饼图展示套餐分布占比折线图展示每日护理记录数趋势三张图基本就能覆盖答辩亮点。前端从统计接口拿数据后简单加工即可重点是后端SQL里的时间分组逻辑要提前准备好演示数据最好生成30天的模拟数据图表看起来才有说服力。6. 毕设文档、代码讲解与一条龙交付经验6.1 文档怎么写得像回事毕设文档一般分需求分析、系统设计、数据库设计、系统实现、测试五部分。最容易被忽视的是需求分析里的用例描述很多人的用例表就是用户登录用户注册两行字太敷衍了。建议至少写六个核心用例客户预约、管理端审核、护理计划制定、护理执行记录、订单查看、数据统计。每个用例写清楚参与者、前置条件、基本流程、异常流程。数据库设计文档里把第4节的核心表清单整理成表格并对每一张表注释关键字段。不需要把每个字段都罗列一遍但主键、外键、状态字段、金额字段一定要标注清楚。设计文档里放上ER图和两三张系统架构图说明三端如何通过后端交互这就足够撑起设计合理、文档完整的评价了。6.2 代码讲解怎么讲才不冷场代码讲解环节千万不要照着类文件一行行念老师会睡着。建议按业务链路讲从客户在小程序端提交预约开始讲到管理端审核、分配房间再到护理师执行护理并提交记录最后到客户端查看报告、管理端看报表。每一步链路涉及哪些表、哪个Controller、哪个Service方法、关键判断是什么都串在这条链路上讲。方法上可以先抛一个问题再讲你的解决方案。比如问护理师提交异常记录后管理端怎么收到提醒你就带大家走一遍异常标记字段从nursing_record表写入到管理端查询待处理列表的过程。这种问题-方案式的讲解比平铺直叙生动得多。还有一个小技巧提前准备两个账号切好页面一个护理师视角、一个管理视角讲到异常提醒时当场演示切换现场效果会明显好过纯PPT展示。6.3 预览版演示环境和演示数据的准备最后说说演示容易翻车的几个地方这都是实际踩过才长记性的。第一演示前一天一定要把后端服务重启一遍用干净的数据库初始化脚本重新生成数据避免调试过程中残留的脏数据在答辩时被老师一眼看穿。第二预约演示时准备一套剧本数据预置两个在住客户、三个待审核预约、近七天每天若干条护理记录和缴费记录。这样每个页面打开都有内容图表不会因为数据太少显得空。第三服务器环境别在答辩前夜临时升级软件包。哪怕你知道有个新版本修了Bug也请忍住。演示系统的第一原则是能跑就行第二原则才是跑得漂亮。我见过有人答辩前升级框架版本结果接口路径变动导致整个系统白屏那天场面相当尴尬。保持你熟悉的环境准备好应急方案比如手机热点共享、预打包一个可用jar包这些都比临时折腾新东西靠谱。7. 定制化扩展方向拿着这套系统还能往哪里走如果你做完基础版还有时间我建议优先考虑以下三个扩展方向它们的投入产出比都挺高。第一个是消息推送。护理端提交异常记录后除了管理端列表能看到还可以给管理端用户发一条小程序订阅消息或邮件提醒。SpringBoot里集成邮件发送很简单JavaMailSender几十行代码就能跑通属于实现成本低、演示效果明显的加分功能。第二个是微信小程序端的支付对接。把客户端的套餐购买流程接入微信支付当然这需要商户号个人主体不一定有但你可以做一个模拟支付流程——点击支付后弹一个模拟确认框后端走支付成功逻辑。这样既展示了订单-支付-会员次数生效的完整闭环又规避了支付资质问题。第三个是护理数据的可视化报告。客户端以PDF或H5报告形式展示客户入住期间的护理总结报告按周汇总产妇恢复趋势、宝宝生长发育曲线。这个功能在技术层面是把各次护理评估记录聚合展示不算复杂但视觉效果很好而且答辩时可以很自然地说这个功能对提升客户体验有直接帮助契合系统选题的业务价值。我个人在实际操作中的体会是这个系统想做出彩不在于技术栈多新而在于业务流程能不能经得起追问。预约、入住、护理、结算这条链路上每经过一个环节数据怎么流转、状态怎么变化、三端各自看到什么你能一气呵成讲清楚整套设计就立住了。把骨架搭稳再按自己的时间余量选一个扩展点去做就已经是一份相当完整的毕业设计了。

基于SpringBoot的会所产后护理系统设计与实现——三端业务闭环解析

相关推荐

AI Agent基础设施的范式收敛：状态机、工具协议与可观测性统一设计

Linux环境自建EMQ X MQTT Broker：安装配置与生产运维实战指南

93K testflow校准条件全解：换板、移位与低良排查一次讲清

更多资讯

JVM垃圾回收核心概念详解：从可达性分析到STW与安全点

Django自习室管理系统开发与优化实践

foobar2000 界面美化实战：3 分钟换装 foobox-cn 上手指南

大华报警主机SDK集成实战：从环境适配到协议解析

Tekton Trigger 实战指南：事件驱动流水线从原理到避坑

PushDeer 推送服务 gorush 的 HTTP API 测试指南：用 bat 与 test.json 验证多平台消息推送

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？