基于Springboot和Vue的敬老院管理系统设计与实现 简介这是一套面向计算机专业本科生的敬老院管理系统高分毕设源码专为毕业设计、课程设计及期末大作业打造兼顾业务实用性与技术规范性。系统采用前后端分离架构前端基于Vue.js实现响应式管理界面后端依托Spring Boot构建RESTful API涵盖老人信息管理、护理计划安排、健康档案维护、员工排班及系统权限控制等核心模块代码经导师指导并获98分高分评价已通过完整功能测试无已知Bug。压缩包共593个文件含195个Java后端逻辑类、67个Vue组件、67张JPG运营图、25个XML配置与Mapper文件、21个JS工具脚本以及启动脚本.bat、样式资源CSS/SCSS和基础配置YML/Properties总大小13.43MB结构清晰、注释完整开箱即用。目前已有106人学习下载配套包含可直接运行的全量源码、标准化项目目录与调试说明显著降低毕设部署与二次开发门槛。1. 项目概述与背景养老行业的数字化一直处在一种“看着热闹、落地不多”的状态。公立养老院、民办敬老院、社区养老服务中心大量机构还在用Excel甚至纸质台账管理人员信息、床位情况、护理记录和费用收缴。这套基于Springboot和Vue的敬老院管理系统就是针对这个真实痛点做的完整解决方案也是我前后花了几个月打磨出来的高分毕业设计项目。先说说这套系统具体能干什么。它覆盖了敬老院日常运营管理的核心链条老人档案管理、入住与退住流程、床位分配与调换、护理任务记录、健康巡检、费用收缴与统计、家属探访登记、员工排班管理、系统用户权限控制。前端采用Vue全家桶后端采用Springboot框架前后端通过RESTful API交互数据存储在MySQL中。整个项目从架构设计到业务实现走完了一个真实Web管理系统的标准全流程。这套代码最值得参考的地方在于它不是那种只有一个登录页和几个增删改查的“空壳毕设”而是把敬老院业务场景中的细节都考虑到了。比如老人的紧急联系人、既往病史、用药提醒、护理等级评估这些业务字段是根据实际养老机构的需求设计的不是拍脑袋想的。如果你正在做相关的毕业设计或者接了一个养老机构的软件开发需求这套系统的业务建模思路可以直接拿过去改。2. 技术方案选型为什么是Springboot Vue这对组合2.1 后端为什么选Springboot而不是SSH或SSM现在的Java Web开发Springboot几乎是事实标准。我刚接触这套技术栈的时候也犹豫过要不要用传统的SSM框架Spring SpringMVC MyBatis后来对比下来发现Springboot的优势非常明显。它内嵌了Tomcat容器不需要额外部署WAR包到外部服务器打包成JAR直接java -jar就能跑这在写毕设和给小型机构部署时节省了大量时间。配置方面Springboot用application.yml统一管理配置项不再需要那一大堆XML配置文件数据源、Redis、日志、MyBatis的配置都集中在一个文件里维护起来非常舒服。敬老院管理系统说实话并发量不会很高关键是要快——开发速度快、部署速度快、有问题排查速度快。Springboot的自动配置机制帮了大忙引入一个starter依赖就自动帮你配好了一大堆东西比如接入MyBatis-Plus只需要引入mybatis-plus-boot-starter数据源配置好就完事了。对于学生项目或者小型商业项目来说这种“开箱即用”的开发体验比微服务那套复杂架构实用得多。2.2 前端技术栈的演进从JSP到前后端分离再到Vue说到前端我早期写Java Web项目用的是JSP JSTL那时候前后端不分离一个JSP页面里Java代码和HTML混着写改样式都得小心翼翼。后来项目升级我才切换到了前后端分离的Vue方案。Vue的核心优势就是组件化开发页面上的每一个功能块——老人信息卡片、费用统计图表、护理任务表单——都能拆成独立的组件开发和维护完全模块化。Vue版本选择上我用的是Vue 2.6 Element UI的组合这套方案非常成熟稳定组件库完整坑也都被前人踩得差不多了。Vue 3虽然已经推出但Element Plus在早期还有不少细节不稳定对于毕设项目来说稳才是第一位的。如果你想用Vue 3 TypeScript Vite那套新生态语法更严谨但学习成本和踩坑概率也会高一些没有把握的话我建议踏实用Vue 2这套经典组合。2.3 前后端分离的通信与数据交互方案前后端分离就意味着两边通过接口通信这里选用RESTful风格API统一返回JSON格式数据。我在后端定义了一个Result类里面包含code、message、data三个字段所有接口都走这个统一返回模板。前端用axios做HTTP请求封装拦截器里统一处理token注入和错误提示这样每个页面的请求代码特别干净。// 统一返回结构 public class Result { private Integer code; // 200成功 500失败 private String message; // 提示信息 private Object data; // 业务数据 public static Result success(Object data) { ... } public static Result error(String message) { ... } }跨域问题的处理我在开发初期踩了不少坑。前端跑在8080端口后端跑在9090端口直接请求会触发浏览器的同源策略拦截。我的解决方案是在后端写了一个CorsConfig配置类添加WebMvcConfigurer的跨域映射放行所有来源和请求头同时在前端用Vue CLI的devServer.proxy配置了路径转发请求/api开头的接口自动代理到后端服务这样开发阶段完全不需要手动处理跨域。3. 系统核心模块拆解与数据库设计3.1 业务模块的功能边界划分敬老院管理系统不是简单罗列CRUD就能完事的我前期花了很多时间梳理业务流程和功能边界。老人管理模块是整个系统的数据核心包含基本信息、入住信息、健康档案、亲属信息四个子块新增老人时要走完整的入住登记流程自动分配床位和护理等级。床位管理模块独立出来做因为床位状态空置、已入住、预定、维修直接影响老人入住的流程逻辑。费用管理模块的业务逻辑稍微复杂一些每月的费用由床位费、护理费、餐费、医疗费四个部分组成系统根据老人的入住日期和护理等级自动计算月度账单支持手动增补额外项目。护理管理模块负责护理任务的创建、指派和状态跟踪每天护理员登录系统查看今日任务完成后在系统里确认数据记录留痕。系统管理模块是每个后台系统都会有的但真正做好也需要花心思。用户管理、角色管理、菜单权限三项配套使用实现不同角色登录看到不同的菜单和数据范围。管理员能看到所有数据护理员只能看到自己的任务财务只能进入费用模块这就是基于RBAC基于角色的访问控制模型的权限设计。3.2 数据库表结构与核心字段设计数据库表我建了12张核心表这里挑几张关键的说说设计的思路。老人信息表elder是最核心的一张表字段包含姓名、身份证号、性别、出生日期、联系电话、入住日期、护理等级、紧急联系人、病史记录。身份证号设置成了唯一索引避免重复录入。床位表bed的设计要体现床位的状态流转字段包括床位号、所在楼层、房间号、床位类型单人/双人、状态0空置/1入住/2维修、当前老人ID。老人和床位是一对一关系通过老人表里的bed_id字段关联。这样设计的好处是查询老人信息时一次关联就能拿到床位信息不用做多表复杂查询。费用表fee的设计我采用了月度账单模式月份字段老人ID做联合唯一索引每个人每个月只会生成一条总账单。明细部分用fee_item表存储费用明细说明费用是哪些项目构成的。护理表nursing_task记录每次护理任务的内容、执行人、执行时间、完成状态、备注字段上加了老人ID索引和护理员ID索引查询速度很快。3.3 表关系与业务状态流转设计整套系统的核心流程是老人的入院、在院、退院三阶段状态流转。老人表里有一个status字段0代表档案新增未入院1代表在院2代表已退住。老人入院时系统先检查床位表中符合条件同一房间类型、空置状态的床位分配床位后将床位状态改为已入住老人状态改为在院。退住时操作相反床位释放为空置老人状态改为退住并生成退住当月的结算账单。为了减少脏数据我在数据库层面做了几条外键逻辑约束比如费用表里的老人ID必须在老人表中存在床位表的当前老人ID在老人表存在这些约束在实际运行中帮了大忙——之前测试阶段出现过孤儿数据加了约束之后这类问题彻底消失。有些同学觉得外键性能不好不想加但毕设和中小型管理系统场景下数据库的一致性远比那一点点性能损耗重要。4. 后端Springboot实现的关键细节4.1 项目分层结构与核心依赖配置后端项目的分层结构我严格遵守了Controller-Service-Mapper的经典三层架构但做了一些现代化的调整。Controller层只接收参数和返回结果不写业务逻辑Service层定义接口实现类里写具体业务Mapper层用MyBatis-Plus的BaseMapper接口继承单表CRUD完全不需要手写SQL复杂查询用Wrapper条件构造器或者自定义注解SQL。依赖配置文件application.yml里我维护了数据源、MyBatis-Plus、日志级别和Tomcat端口。这里有几个小细节值得注意数据库连接池我用的是HikariCPSpringboot默认集成性能非常给力MyBatis-Plus的逻辑删除插件配置了全局标志位删除操作自动变成更新操作这样老人数据误删后还能恢复日志级别开发环境用DEBUG生产环境调到INFO输出到控制台和文件双通道。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/rest_home?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 hikari: maximum-pool-size: 10 minimum-idle: 5 mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 04.2 用户认证与权限控制的实现认证方案我选了JWTJSON Web Token 拦截器的方式没有引入Spring Security或者Shiro那套重框架因为对这类管理系统来说JWT轻量好懂核心逻辑自己写完全可控答辩时讲起来也更有底气。用户登录成功后后端生成一个有效期为24小时的token返回给前端前端存储在localStorage里每次请求在请求头里带上Authorization: Bearer token。后端写了一个token校验拦截器拿到token先做格式校验再解析JWT验证签名和过期时间从claim里拿到用户ID和角色信息存入ThreadLocalController层通过自定义注解RequirePermission(admin)来校验当前用户是否有权限访问指定接口。这一步是重点也是很多学生的盲区——权限不仅要控制菜单显示接口层面也要有防御否则别人绕过前端直接调接口就能看数据了。4.3 复杂业务逻辑的前端示例缴费记录接口实现在费用生成这块逻辑上有不少细节。老人入院时系统自动初始化当月费用记录项目包含床位费和护理费预收。收费规则是床位费按床位类型定价单人间600元/月双人间400元/月护理费按护理等级定价三级护理200元/月二级护理500元/月一级护理1000元/月。月度费用生成器在每月1号凌晨跑定时任务遍历所有在院老人自动批量生成账单。定价规则我放在了数据库配置表里这样以后调整价格不需要改代码改重启运营人员直接在系统设置里改配置就行。这个设计的灵感来源于我之前看过的几个商业项目把业务规则和代码逻辑分离灵活度提升非常多。定时任务用Spring Task注解实现没有引入Quartz那套重型框架一个Scheduled(cron 0 0 1 1 * ?)就搞定了月底账单生成。5. 前端Vue实现与页面交互5.1 Vue项目结构与路由设计前端项目基于Vue CLI脚手架创建src目录下分为api、assets、components、router、store、views、utils七大模块。api目录统一管理所有后端接口调用每个模块一个文件比如老人模块对应elder.js费用模块对应fee.js这种“接口集中式”的管理方式让代码维护变得非常清晰——后端改了接口路径在前端只需要改一个文件。utils里放axios封装和公共验证方法。路由设计采用了动态路由方案用户登录后根据角色权限从后端拿到可访问的菜单列表动态注册路由。普通用户看不到任何管理后台的路由路由守卫里做判断未登录跳转登录页无权限访问提示403页面。菜单和路由通过Vue Router的addRoutes方法动态添加实现权限控制的前端闭环。5.2 核心页面组件封装经验Element UI组件库虽然提供了大量基础组件但实际业务中还是有不少重复性的封装需求。比如分页表格几乎每个列表页都需要我把el-table和el-pagination封装成了一个PagedTable组件传入列配置和查询接口组件内部自动处理加载状态、分页逻辑、空数据展示。这个组件一次写好全项目复用页面代码量直接少了一半。弹窗表单提交的场景也做了一个ModalForm封装统一处理表单打开、数据回显、提交校验、关闭重置。还有图片上传组件用于老人照片和证件上传封装了前端压缩、预览、上传进度和回显逻辑。封装组件是提升开发效率的最佳手段但要把握好度过度抽象反而会影响维护我一般只在同一个组件使用超过三次的场景才会抽出来。5.3 前端与后端接口联调实录前后端联调是开发中最耗费时间的环节我是在后端接口开发完成80%后开始联调的。实际操作中发现两类高频问题一类是接口路径不对齐前端写的URL和后端RequestMapping不一致这类问题通过浏览器Network面板看请求状态码404就能定位另一类是JSON字段名不一致后端返回字段是createTime前端代码写的是create_time数据渲染不出来这类问题排查起来需要前后端对照检查。为了解决联调效率问题我在后端用了Swagger自动生成API文档配置好之后启动项目访问/swagger-ui.html就能看到所有接口的定义、参数、返回示例。前端对着Swagger文档调试不用重复找后端同学问接口格式。这个习惯在团队开发中价值巨大强烈建议所有项目都接上。// axios 封装的核心代码片段 // utils/request.js import axios from axios; const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }); service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }); service.interceptors.response.use(response { const res response.data; if (res.code 200) { return res; } if (res.code 401) { // token过期清空登录信息并跳转到登录页 } return Promise.reject(new Error(res.message || 请求失败)); });6. 系统部署运行与环境配置6.1 本地开发环境的搭建步骤开发环境搭建是很多初学者卡住的第一关我尽量把步骤拆细说一遍。首先JDK版本一定要用1.8Springboot 2.x对JDK 8支持最好装了JDK 11或17可能会遇到兼容性问题。数据库选MySQL 5.7或8.0都可以8.0注意驱动要换成com.mysql.cj.jdbc.Driver并且URL里加上serverTimezoneAsia/Shanghai。前端环境需要Node.js和npm我用的是Node 14Vue CLI脚手架创建项目后npm install安装依赖。创建数据库rest_home把项目里sql目录下的init.sql脚本导进去脚本里包含了建表语句和初始数据一个系统管理员账号admin/123456。后端项目用IDEA打开修改application.yml里的数据库账号密码为本地配置运行RestHomeApplication主类。前端项目用VSCode打开npm run serve启动开发服务器浏览器访问localhost:8080就能看到登录页面。6.2 基于Nginx的前后端分离部署关于部署我采用的是前后端分离部署的标准方案前端产物部署到Nginx静态目录后端JAR包运行在服务器上Nginx配置反向代理转发API请求。前端执行npm run build生成dist目录把dist目录里的文件上传到服务器的/usr/share/nginx/html/rest-home/目录。后端执行mvn clean package打JAR包用java -jar rest-home-system.jar启动。Nginx配置里两个关键点一是location / 指向前端静态文件目录配置try_files $uri $uri/ /index.html因为Vue Router使用history模式刷新页面时如果不配置这个会出现404二是location /api/ 反向代理到后端服务proxy_pass http://127.0.0.1:9090/这样浏览器请求的/api/manage/login会被转发到后端的/manage/login接口。server { listen 80; server_name rest-home.example.com; location / { root /usr/share/nginx/html/rest-home/; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:9090/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意用Nginx反向代理后前端baseURL要改成/api后端接口路径不要带/api前缀避免代理路径拼接出错。6.3 生产环境的常见坑与优化生产环境部署和本地开发有很多不同我在实际部署到Linux服务器上时遇到了几个问题。第一个坑是MySQL字符集问题服务器上MySQL默认字符集不是utf8mb4中文数据导入后出现乱码。解决方法是建库时指定字符集CREATE DATABASE rest_home DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci同时连接URL加上useUnicodetruecharacterEncodingutf8。第二个坑是端口占用问题服务器上可能已有其他服务占用80端口通过修改Nginx listen端口为8080解决。第三个坑是后端服务后台运行的方案直接用nohup java -jar xxx.jar 可以临时跑起来但服务器重启后就没了。后来我写了一个systemd服务文件设置开机自启错误日志通过journalctl查看解决了很多运维层面的问题。如果服务器内存足够还可以加上JVM参数-server -Xms512m -Xmx1024m调整堆内存大小。7. 常见问题与开发避坑经验7.1 前后端联调的典型问题速查联调阶段出问题最多我整理一张问题速查表供你参考。现象可能原因解决方案登录请求404后端接口路径没对齐检查Controller的RequestMapping和前端axios的URL是否一致请求跨域报错后端未配置跨域映射添加CorsConfig跨域配置类数据返回但页面空白JSON字段名与前端不一致用Swagger文档对照检查字段名大小写请求401token缺失或已过期检查请求头是否带Authorization重新登录分页数据加载不出来分页参数名不一致确认current/pageNum、size/pageSize的参数命名统一7.2 数据库设计阶段的教训复盘数据库设计我前后改了三次有些教训是改出来的。第一次设计老人表时没有单独设计健康档案表把病史信息直接塞在老人表里后来发现在院期间老人会多次体检、多次就诊需要在表里存多条记录就必须拆表。第二次设计费用模块时只做了费用汇总表费用明细只能用逗号分隔塞进一个字段里后期统计费用组成时非常痛苦只能分成主表和明细表。所以给同样在做毕设的同学一个忠告建表之前一定要把业务场景梳理清楚多想想数据会不会增长、查询维度有哪些、逻辑删除和信息留痕怎么实现。前期多花一小时设计后期能省十几个小时的返工时间。还有一点数据库每张表都要有create_time、update_time、create_by、update_by这四个审计字段别觉得多余出了问题排查、数据回溯全靠它们。7.3 权限接口越权问题实战排查分享一个实际排查过的安全问题。系统上线内部测试时我发现一个普通护理员账号可以通过浏览器地址栏直接访问管理员接口比如访问/manage/manager/list获取所有员工列表。前端菜单里确实看不到但是接口没有做权限拦截懂技术的人完全能绕过前端攻击接口。这说明管理系统的权限不能只靠前端菜单隐藏后端必须做接口级的权限校验。我的修复方案是在拦截器里从token解析出用户角色配合自定义注解RequirePermission在需要特定权限的Controller方法上加上该注解缺少权限直接返回403。配置好之后任何角色登录后能访问的接口就是它被授权的接口不存在绕过前端的情况。这个问题在答辩时被老师重点提问正好变成了整个项目的亮点说明了做安全防护不仅仅是技术问题更是业务责任心问题。8. 项目扩展方向与实用建议8.1 从毕设到商用系统的距离如果你拿着这套系统去接真实的敬老院项目还需要补不少功能。比如对接微信小程序端让家属可以通过小程序查看老人的日常动态、照片和费用账单这就是移动端扩展的典型需求。比如增加物联网设备对接智能手环采集老人的心率、血氧、步数等健康数据系统实时监测预警这个方向看起来很高级实际上通过成熟的硬件SDK也能实现。再比如数据大屏展示给院长办公室或者参观领导做一个可视化看板实时展示在院老人数、空床位数、今日护理任务完成率、月度营收趋势图。ECharts图表库插上就能用我之前做这部分扩展花了不到一周时间。这些扩展方向能帮你在毕设答辩或者标书方案里大大加分。8.2 代码质量维护的三个好习惯针对这个项目再多啰嗦几句代码规范的事情。第一个习惯是统一返回结果对象不要有些接口返回JSON对象有些接口返回字符串前后端协作者都累死。第二个习惯是参数校验要做在前端后端的校验也不能省重要参数用Valid注解加JSR 303校验规则防止脏数据入库。第三个习惯是接口文档随时更新后端代码改了Swagger注解没改联调时前端完全不知道怎么调文档和代码同步维护是最基础也最容易被忽视的。数据库字段的命名规范也要注意统一用下划线风格snake_case代码里用驼峰风格camelCaseMyBatis-Plus开启驼峰映射自动转换。不要出现一部分字段用下划线一部分字段用驼峰的混乱局面这种情况项目越写越难维护。8.3 我的最终使用感受与实际效果这套系统从编码到最终内部测试通过总共花了大约三个月时间每天平均投入三四个小时。真正运行起来之后我发现它的稳定性和实用性超出预期。敬老院的日常管理确实能从这套系统受益管理员录入一位新老人从原来手工填五份表花半小时缩短到系统录入十分钟完成月底费用计算从财务手动算两三天缩短到系统一键生成账单院长随时随地登录系统就能查看全院运营数据这是传统台账完全做不到的。对于正在做毕设或者想学习前后端分离项目的同学我的建议是不要只关注增删改查这些基础功能要把精力多花在业务流程的梳理和细节的打磨上那些才是决定一个系统好坏的关键部分。技术框架都是成熟的真正拉开差距的是你怎么运用这些框架去解决实际业务问题。希望这套系统的设计思路和开发经验能帮到你。本文还有配套的精品资源点击获取