我做区域管理这块有一段时间了，接触过不少类似的预约服务类系统，今天来聊聊一个很适合毕业设计的选题——基于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_menu | user表加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），数据库查询统一带deleted=0条件，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报告形式展示客户入住期间的护理总结报告，按周汇总产妇恢复趋势、宝宝生长发育曲线。这个功能在技术层面是把各次护理评估记录聚合展示，不算复杂，但视觉效果很好，而且答辩时可以很自然地说"这个功能对提升客户体验有直接帮助"，契合系统选题的业务价值。
我个人在实际操作中的体会是，这个系统想做出彩，不在于技术栈多新，而在于业务流程能不能经得起追问。预约、入住、护理、结算这条链路上，每经过一个环节，数据怎么流转、状态怎么变化、三端各自看到什么，你能一气呵成讲清楚，整套设计就立住了。把骨架搭稳，再按自己的时间余量选一个扩展点去做，就已经是一份相当完整的毕业设计了。
