Eleny君君从零做一个Spring Boot养老院管理系统，我把自己踩过的坑都写在这了
每年毕业季，总能看到一批又一批的Java毕设选题里躺着“养老院管理系统”这个名字。说实话，这个题目能火这么多年不是没道理的——业务边界清晰、角色划分明确、功能有层次感，既不会简单到没有工作量，也不会复杂到脱离本科生的能力半径。我前前后后帮人看过、改过、远程调过好几个版本的养老院系统，自己也完整落地过一版基于Spring Boot的，这里面值得说道的东西其实比很多人想象的多得多。
这篇就把我从需求分析、表结构设计、核心业务实现到部署调试的完整过程捋一遍，重点说清楚那些常规教程里不会明讲的坑，比如为什么床位管理跟费用挂钩之后逻辑会复杂一倍，又比如JPA和MyBatis-Plus在动态查询场景下的真实差距，还有远程调试时最容易翻车的端口和参数问题。
1. 项目概述与整体设计思路
1.1 这个系统到底在解决什么问题
养老院管理系统的本质，是一个典型的信息管理系统（MIS），但它在业务复杂度上比普通的图书管理、学生管理要高出不少。核心原因在于它涉及多角色的协同，而且业务状态之间存在联动。
我接触过的需求方，无论是真实的养老机构还是毕设指导老师，通常都会要求覆盖以下角色和场景：
- 管理员：院内的最高权限角色，需要看全院床位、入住、收费、员工排班的总览；
- 护工/员工：负责老人的日常照护记录、健康状态登记、请假与换班；
- 老人家属：需要能查看老人的基本信息、缴费账单、健康动态；
- 老人信息管理：从入院登记、床位分配到退院结算的全生命周期；
- 床位管理：床位状态要跟入住申请联动，避免出现“床位已分配但老人信息还没建档”的中间状态；
- 费用管理：床位费、护理费、餐饮费，不同护理等级对应不同单价，月底一键生成账单。
如果你做的是一个只有增删改查的“假系统”，那确实三天就能写完，但毕业设计要想拿高分、答辩时经得起问，业务闭环一定要打通。让老人从入院到退院的数据串成一条线，让费用从生成到收讫形成闭环，这才叫“设计与实现”。
1.2 为什么这个选题适合做毕业设计
抛开业务本身，从毕设评审的角度看，这个题目有几个天然优势：
第一，技术栈覆盖全面。Spring Boot + MyBatis-Plus/JPA + MySQL + Vue/Thymeleaf + Maven，这一套下来，从后端分层到前端交互再到位部署，全部覆盖到位，评委问哪个环节你都有东西可讲。
第二，数据库设计有东西可挖。角色表、用户表、老人信息表、床位表、入住记录表、收费表、护理记录表，关联关系复杂但清晰，ER图画出来非常漂亮，这在论文里是加分项。
第三，业务逻辑可以做出深度。比如费用结算时的日期计算（按天折算还是按月整算）、床位分配时的状态校验、退院时未缴费用的拦截，这些都是可量化的业务规则，体现的是“设计能力”而非“CRUD能力”。
1.3 技术选型背后的考量
技术选型这件事，我的建议很直接：优先选择你答辩时能讲清楚、遇到问题你能自己排查的东西。
- 后端框架：Spring Boot 2.7.x。没必要追新上Spring Boot 3。3.x是基于Jakarta EE的，很多老教程、老依赖对不上号，出问题了你百度都百度不到答案，而2.7.x生态成熟、资料齐全，对毕设来说完全够了。
- 持久层：MyBatis-Plus。理由很简单：自带分页插件、条件构造器、逻辑删除和自动填充，能省掉大量手写SQL的时间，而且灵活度远高于JPA。JPA在复杂连表查询时返回字段难以控制，动态SQL生成也晦涩，不是说它不好，而是在毕设这种时间有限的场景里，MyBatis-Plus的“性价比”更高。
- 前端：如果时间充裕就选Vue2 + Element UI做前后端分离；如果精力不足或者前端基础薄弱，直接用Thymeleaf模板引擎做服务端渲染也行，工作量少三分之一，还能把更多时间花在后端业务上。
- 数据库：MySQL 8.0。字符集选utf8mb4，别问为什么，等你存了生僻字或者表情符号就知道痛了。
我见过不少同学在技术选型上犯了“为了新技术而新技术”的毛病，非要用Spring Cloud Alibaba微服务，结果一个毕设做了六个月，网关、注册中心、熔断全上了，最后答辩的时候基础问题一问三不知。毕设不是生产级项目，评委要看到的是你对知识的掌握程度和解决问题的能力，不是技术名词堆砌。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能模块与数据库设计
2.1 功能模块边界划分
我个人在做这类管理系统时，习惯遵循“单模块最小闭环”原则——每个业务模块都能独立跑通，然后通过服务层串联形成完整链路。
养老院管理系统我拆成了六个核心模块：
- 系统管理：用户管理、角色权限、菜单管理，基于RBAC模型；
- 老人档案管理：入院登记、健康档案、家属信息、退院登记；
- 床位管理：床位类型、床位状态、床位分配与释放；
- 护理管理：护理任务分配、护理记录、健康巡检；
- 收费管理：收费标准配置、月账单生成、缴费登记、欠费预警；
- 统计报表：入住率、收费汇总、老人年龄段分布。
其中最容易做砸的是床位管理和收费管理，也是最值得花时间打磨的地方。
2.2 数据库表结构设计的核心细节
先放一张我在实际项目里的核心表清单，表名和字段名都是可以直接照抄的级别：
| 表名 | 核心字段 | 说明 |
|---|---|---|
| sys_user | id, username, password, role_id, status | 系统用户表，与老人表分开 |
| elder_info | id, name, id_card, gender, birthday, health_level, room_id, bed_id, status | 老人档案表 |
| room_info | id, room_no, room_type, floor, bed_count | 房间表 |
| bed_info | id, room_id, bed_no, bed_status, elder_id | 床位表，elder_id作为外键冗余 |
| check_in_record | id, elder_id, bed_id, check_in_date, expected_discharge_date | 入住记录 |
| check_out_record | id, elder_id, discharge_date, reason | 退院记录 |
| care_level | id, level_name, price, description | 护理等级与单价 |
| care_record | id, elder_id, caregiver_id, care_content, record_time | 护理记录表 |
| fee_record | id, elder_id, item_type, amount, month, status | 月度费用 |