SpringBoot+Vue敬老院管理系统：从需求到部署的全栈实践

这个项目我前后见过不少次，很多打算做毕设或者练手Java全栈的同学都会把目光放在SpringBoot+Vue这个组合上，而敬老院管理系统又恰好是一个典型的管理系统类题目：业务清晰、模块适中、既有CRUD又有统计报表，工作量不至于小到撑不起一篇论文，也不会大到一个人几个月做不完。如果你正在为选什么题目发愁，或者已经拿到这类源码但不知道怎么讲清楚它、怎么把它变成自己的东西，那这篇内容应该对你有用。

下面我会从项目的整体设计思路、技术选型的理由、前后端核心实现细节、数据库表设计和实际部署流程这几个方面完整拆一遍，把我自己在开发调试这类系统时积累的经验和认为值得注意的地方一并写出来。无论你是准备直接用它做毕设，还是想拿它练习SpringBoot和Vue的整合能力，都可以把这篇文章当作一份操作手册来看。

1. 项目整体设计思路与功能模块拆解

1.1 需求边界怎么划：既不能太空也不能太杂

敬老院管理系统这类题目，最核心的业务场景其实就是“院方工作人员每天要管哪些事”。当你去构思一个敬老院管理系统的时候，先不要急着堆功能，而是把角色和日常流程列出来：管理员需要掌握全院老人的基本信息、床位分配情况和费用缴纳情况；护工需要记录每天的护理工作，比如喂药、洗澡、巡房；财务人员需要登记和统计每个老人的各项费用；老人家属可能希望查看老人的健康状况和在院状态。

把这些流程梳理清楚之后，系统边界自然就出来了。一个合格的敬老院管理系统，至少要覆盖老人档案、住宿资源、日常照护、收费管理、健康记录和系统权限这几个方向。

这里想特别提醒一下：毕设项目的需求设计，最怕的就是“什么功能都想加”。我见过一个同学给自己设计的敬老院系统里塞了线上商城、聊天室、送餐机器人调度模拟，结果答辩时连核心的老人入住流程都没讲明白。作为毕设或课设，合理的做法是把主体业务做扎实，再挑一两个亮点功能做深入，而不是把摊子铺得很大。

1.2 核心业务模块梳理

下面这张表就是我建议你在设计和讲解项目时可以采用的模块结构，它对应了三类使用角色，也对应了你项目将来要展示给老师看的功能列表：

每个模块之间不是孤立的。比如老人档案里的“当前床位”字段是从床位模块分配过来的，费用模块每个月生成的账单又是根据老人的入住时间、护理等级计算出来的。这其实就是你在设计数据库时需要考虑的外键关系和业务联动，后面我会详细说。

1.3 角色与权限设计

系统中有三类核心角色，分别是管理员、护工和财务。如果要扩展，也可以给家属做一个只读账号，让家属能登录系统查看老人近期的健康记录和护理记录，这会成为答辩时的一个亮点功能。

权限这块，我建议使用RBAC（基于角色的访问控制）模型，用户表关联角色，角色关联菜单权限再关联接口权限。但考虑到毕设的特性，实现到“登录后根据角色显示不同菜单”和“后端接口通过拦截器校验角色”这两层，其实已经足够了。再深就要引入Spring Security或Shiro，工作量会明显增加，性价比不高。

2. 技术选型解析：为什么这套组合是毕设经典配置

2.1 后端：SpringBoot + MyBatis-Plus + MySQL

选SpringBoot的原因很直接：它内置了Tomcat，简化了Spring的配置，开发起来非常快，毕业设计里你不需要像SSH那样写一堆XML配置文件。一个@RestController就能暴露接口，一个@MapperScan就能让数据访问层跑起来。

MyBatis-Plus则是大部分毕设项目的“最佳拍档”。你不需要写基本的CRUD SQL，继承一个BaseMapper就能获得增删改查方法，再配合它的分页插件，10分钟就能把一张表的接口写完。对于单体管理系统的开发效率来说，这确实比原生的MyBatis省事很多。如果你熟悉JPA，用Spring Data JPA也可以，但网上的毕设代码大多用MyBatis-Plus，你遇到问题时搜索解决方案更快。

数据库选MySQL，这是Java方向最稳妥的选择，社区资源多，图形化工具也多，导入导出都很方便。

2.2 前端：Vue 2 + Element UI 还是 Vue 3 + Element Plus

这里有一个常见的选择纠结。我的建议是：如果你在自己做，优先选你更熟悉的那一套；如果项目源码已经确定，就跟着源码走，不要临时换技术栈。

从稳定性角度来说，Vue 2 + Element UI的生态非常成熟，网上现成的后台管理模板多到数不清，很多免费bootstrap模板也兼容Vue2。而Vue 3 + Element Plus更符合当前前端趋势，组合式API写起来更舒服，如果你对这个体系有一定基础，完全可以选它。但要注意Element Plus的组件用法和Element UI有些细微差异，遇到问题时要区分清楚。

前端配套的还有Axios负责HTTP请求，ECharts负责做统计图表，vue-router负责页面路由，vuex或者Pinia负责前端状态管理。这些属于后台管理系统开发里的标配，能自己动手配置一遍，对理解前端工程化也很有帮助。

2.3 开发环境与版本搭配

根据我实际的调试经验，推荐下面这套环境组合，遇到坑的概率最小：

• JDK 8或JDK 11
• Maven 3.6+
• MySQL 5.7或8.0
• Node.js 14左右（Vue2项目）
• IDEA或Eclipse开发后端，VS Code或WebStorm开发前端

这里提一句，Java版本不要盲目用最新版。JDK 21虽然新，但一些老项目的依赖或者MyBatis-Plus的某些版本可能会出现兼容性报警，解决问题的时间可能比写代码还长。毕设的稳定性永远优先于技术先进性。

3. 前后端核心功能实现细节：从登录到统计报表

3.1 登录认证是怎么做的：JWT与拦截器

几乎所有管理系统的首个功能都是登录。这里我只讲一种很常见也比较好讲的方案：JWT配合后端拦截器。

用户输入用户名和密码之后，后端调用用户Mapper查出用户信息，比对密码。密码建议用MD5加盐处理，或者直接用BCrypt加密。比对成功之后，用JWT工具类生成一个token，token里可以包含用户ID、用户名和角色代号，然后把这个token返回给前端。前端拿到token后存在localStorage里，每次Axios请求都通过请求拦截器自动加在请求头的Authorization字段上。

后端这边，SpringBoot配置一个拦截器，拦截所有以 /api/ 开头的请求，只有登录接口和少数几个公共接口放行。拦截器里会做两件事：第一，从请求头里取token并校验签名和过期时间，如果无效直接返回401；第二，如果接口方法上标注了某个角色注解，比如@PreAuthorize，再检查token里的角色是否匹配。

这套流程说白了就是“登录发证，访问验证”。它既不用引入Spring Security那套繁琐的过滤链，又能清楚地展示出你对认证授权原理的理解。答辩时如果老师问“为什么不用Spring Security”，你可以诚实回答：在不引入额外复杂度的前提下实现了核心的权限控制，同时说明了JWT本身的机制，这就是一个很好的回答思路。

3.2 老人档案管理：典型的CRUD结构

老人档案列表是前端的基础页面。页面左边可以放一个搜索区域，支持按姓名、入住状态、护理等级等条件查询；中间是表格，展示老人的基本信息；顶部按钮是新增、编辑和删除。这在Element UI里是非常标准的写法。

后端的话，每个接口对应一个Controller方法。分页接口接收current和size两个参数，再附带几个条件查询字段，MyBatis-Plus的LambdaQueryWrapper可以直接用来拼接条件。

java复制// 后端分页查询示例
public Result<Page<Elder>> page(int current, int size, String name, Integer status) {
    Page<Elder> page = new Page<>(current, size);
    LambdaQueryWrapper<Elder> wrapper = new LambdaQueryWrapper<>();
    wrapper.like(StringUtils.isNotBlank(name), Elder::getName, name)
           .eq(status != null, Elder::getStatus, status)
           .orderByDesc(Elder::getCreateTime);
    elderService.page(page, wrapper);
    return Result.success(page);
}

有一个细节容易被忽略：删除老人档案之前，一定要检查这个老人是否还存在未完结的护理记录或费用记录。如果直接用物理删除把老人信息删掉，后续查历史账目的时候就会出现数据断裂。所以更好的做法是在表里加一个deleted字段做逻辑删除，查询时只查deleted=0的数据。这样业务数据保持完整，代码也不难写。

3.3 床位管理：带有状态的资源分配

床位管理比老人档案稍微复杂一点，因为它要处理一个“分配”的动作。

数据库里的床位表一般包含：id、房间号、床位号、所在楼层、床位类型、当前的入住状态（0为空闲，1为已入住）。当管理员给老人办理入住院时，系统要做的事情是：把老人表的status改成“在院”、把老人表的bedId字段设置为某个床位ID、把床位表的状态改成“已入住”。这三步操作需要放到同一个事务里，防止出现老人已经写入了床位号，但床位状态还是空闲的矛盾情况。

退住的时候则反过来操作。这里我在实际开发中被坑过一次：只改了几张表的状态，却忘了把老人的bedId置空，导致后来统计“空闲床位”时出现逻辑错误。所以你写这部分代码的时候要养成一个好习惯：任何涉及多张表状态的修改，先画一个状态流转图，再把每一步都写进事务方法里。

3.4 护理记录与健康监测：一对多关联业务

护理记录和健康记录都是围绕老人展开的多条记录。前端页面可以选择一个老人，然后以时间线的方式展示该老人本周甚至本月的所有记录。这种交互方式比较直观，也容易在答辩时演示。

后端接口设计时，提供一个“按老人ID查询护理记录列表”的接口，再提供一个“新增护理记录”的接口即可。为了避免前端一次性拿太多数据，可以根据日期范围做条件筛选。

健康监测这部分最大的亮点在于图表。前端用ECharts，后端提供一个统计接口，返回老人最近一个月的血压、血糖、心率数据，前端用折线图展示。老师看到这里会认为你的系统不仅仅是数据的存取，还有一定的数据分析和展示能力，这是毕设加分项。

3.5 统计报表：SQL聚合的应用

统计报表是很多同学写到最后才想起来加的功能，其实它在系统里占据的位置很重要。比如首页要显示“在院老人数、空余床位数、本月收入、本月新增入院人数”这四个汇总指标，这四条SQL用count和sum聚合就能写出来。

再如月度费用统计：按月份对费用表进行分组求和，然后用一个柱状图展示最近6个月的收入趋势。SQL大概是下面这样：

sql复制SELECT DATE_FORMAT(pay_time, '%Y-%m') AS month, SUM(amount) AS total
FROM fee_record
WHERE pay_status = 1
GROUP BY DATE_FORMAT(pay_time, '%Y-%m')
ORDER BY month

这类报表不需要过多设计，关键是SQL要写对。如果页面上图标没有数据，优先去调试SQL，而不是调前端代码。

4. 数据库设计：表结构、字段与业务约束

4.1 核心表清单

一个标准的敬老院管理系统，数据库里至少应该包含下面这些表：

• 用户表 sys_user
• 角色表 sys_role（也可以做成固定枚举不建表，但建表更规范）
• 老人信息表 elder_info
• 床位表 bed_info
• 入住记录表 check_in_record
• 护理记录表 care_record
• 健康记录表 health_record
• 费用记录表 fee_record
• 探访记录表 visit_record
• 菜单权限表 sys_menu（如果是普通权限项目可以省略）

其中“入住记录表”是我建议你额外加上的，它记录老人每一次入住和退住的时间、操作人。有了这张表，以后做入住率统计会非常方便。

4.2 老人信息表和床位表的字段设计

新建一个老人信息表，我会这样设计核心字段：

床位表的字段要抓住“房间-床位-状态”三个关键信息：

业务约束上需要注意几点。第一，老人表里的bed_id和床位表状态要保持一致；第二，一个老人的身份证号不应该重复，给id_card加唯一索引；第三，费用表里金额字段用decimal而不是float，因为float在精度上有已知问题。

4.3 时间字段、逻辑删除与索引

在大多数管理系统里，逻辑删除字段一定不要省。比如老人被删除之后，历史护理记录还要显示老人的姓名，如果物理删除了老人表，护理记录就关联不到人了。加上deleted字段之后，历史数据仍然完整，权限和统计也更准确。

时间字段统一用datetime类型。这里提一个编码上的小坑：后端Java实体类的LocalDateTime和Mysql的datetime类型在MyBatis-Plus中可以直接互相映射，但要注意mysql-connector-java的时区参数。如果连接串上没有设置serverTimezone=Asia/Shanghai，在有些环境下查询时间会相差8小时。写连接配置时养成习惯直接带上这个参数。

索引方面，重点给查询频繁的字段加索引。护理记录表按老人ID和时间来查询，就给(elder_id, care_time)加联合索引；费用记录按月份汇总，会给pay_time加索引。

5. 从零到一：本地部署与联调实操指南

5.1 拿到源码后第一步：看README和SQL脚本

很多同学拿到一份源码之后不知道先干什么。我的建议是先把项目的README认真看一遍，确认这里面写了数据库导入方式、默认账号密码和启动顺序。然后找项目里的.sql文件，在数据库客户端里新建一个数据库，名字最好跟application.yml里的配置一致，比如elder_system，然后直接执行SQL脚本。

执行完之后别急着启动后端，先打开表看一遍数据是否正常，确认有默认管理员账号。常见的问题是没有执行脚本，或者执行了一半报错导致表缺失，启动自然就会失败。

5.2 后端启动配置

用IDEA打开后端项目后，等待Maven把依赖下载完成。检查这些位置：

• application.yml里的数据源配置、端口号
• 是否配置了MyBatis-Plus的日志输出
• MapperScan扫描的包路径是否和Mapper接口所在包一致

如果数据库密码不是root，记得把application.yml里对应的地方改成你自己的密码。用户名和密码不对是启动后接口报错最多的一类。

启动类上需要@SpringBootApplication注解，加上@MapperScan("com.xxx.mapper")，如果漏掉了这个注解，项目启动时MapperBean创建会报错。

推荐在IDEA里加上MyBatis-Plus打印SQL日志的配置，这样每执行一次查询都能在控制台看到实际SQL，排查问题时非常有帮助。

5.3 前端启动与跨域处理

前端项目结构一般是一个src目录加package.json。启动步骤很简单：

bash复制npm install
npm run serve

首次npm install如果比较慢，可以用国内镜像。有时候前后端联调接口会一直报请求失败，这个问题90%的可能是跨域导致的。最简单的解决办法是在vue.config.js里配置devServer的proxy，把前端的/api代理到后端的8090端口：

javascript复制devServer: {
    port: 3000,
    proxy: {
        '/api': {
            target: 'http://localhost:8090',
            changeOrigin: true
        }
    }
}

这样前端只在本地3000端口开发，所有把请求发给 /api 的接口都会自动转发到后端，代理模式下不会出现跨域。如果你不使用代理，直接让前端http://localhost:8090访问后端，那后端就得开启CORS全局配置，否则浏览器会拦截响应。

5.4 把项目打包部署起来

如果你想做一个完整的部署演示，可以用下面这条路径：

先在后端项目根目录执行

bash复制mvn clean package -DskipTests

构建产物会在target目录下生成一个.jar文件。把它放到服务器上（或者自己电脑直接跑），执行：

bash复制java -jar elder-system.jar

前端执行

bash复制npm run build

生成dist文件夹，然后在nginx中配置一个server块，把root指向dist目录，把/api请求转发到后端地址。这样整个项目就可以通过浏览器访问了。

在我的经验里，这一步不是必须的，但如果你能把打包部署的步骤跑通并拿到答辩现场演示，老师对项目完成度的认可度会明显不一样。

6. 常见问题排查与毕设答辩避坑实录

6.1 最常见的几个问题速查表

6.2 一个容易被忽视的坑：不打印SQL很难发现问题

SpringBoot项目里没有把MyBatis-Plus的SQL日志打开，是很多人调试效率低的原因。配置非常容易，在application.yml里加上：

yaml复制mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样每次执行SQL都会打印出来。我用这个方式排查过好几次“查询结果为空但数据明明存在”的诡异问题，最后SQL打出来一看，是条件里的状态值写错了，功能逻辑本身并没有问题。

6.3 答辩时最容易被追问的四个问题

• 为什么选SpringBoot而不是别的框架？回答思路：SpringBoot简化了配置，自动化装配让开发效率更高，适合快速搭建单体管理系统。
• 你项目的权限是怎么控制的？回答思路：JWT生成令牌，拦截器校验令牌和角色，前后端配合完成资源访问控制。
• 如果同一时间多个护工提交护理记录，数据库会出问题吗？回答思路：单表单条插入，在数据库层面用事务和主键保证不会互相覆盖，即使有并发也只是排队执行。
• 你这个系统有什么可以改进的地方？这是个“送分题”，你要提前准备好：可以引入缓存提升老人查询速度，可以增加定时任务每天早上自动生成费用提醒，可以开发一个小程序端给家属使用。说出两个具体的点，老师就能看出你对项目的理解。

6.4 想让项目更完善，可以加什么功能

如果时间和能力允许，我建议在原有基础上扩展下面这几个功能之一：

• 自动生成月度账单：用SpringBoot的@Scheduled定时任务，每月1号自动为所有在院老人生成上月费用记录。
• 家属端小程序或H5：让老人家属通过手机查看老人在院记录和健康数据，这会让项目在“实用性”上上一个台阶。
• 数据导出功能：用EasyExcel把老人档案表或费用记录表导出成Excel。

这些功能在技术上难度不大，但增量效果非常明显，答辩展示时也更有话可讲。

开发这类管理系统，我自己最大的体会是：技术本身其实不复杂，真正的难点在于把业务流程和数据关系梳理清楚。可能你在开发过程中会被一些莫名其妙的报错卡住，比如分页插件失效、时间字段差8小时、前端跨域请求被拦截，这类问题现在搜索一下基本都能解决，但你理解了背后的原理，下次遇到就不会慌。

敬老院管理系统作为一个Java全栈项目，它最大的价值不是功能本身有多新颖，而是它能让你完整体验一条从需求分析、数据库设计、前后端开发到部署上线的完整链路。把这个链路走通一遍，你学到的东西绝对比只看教程多得多。真的花上一两周时间好好把它吃透，无论是拿去答辩还是写在简历里，它都会是一个拿得出手的作品。