拿到这个标题的时候我多看了一眼——养老院管理系统管理系统系统两个字打了两遍。不过说实话这种命名在课程设计和毕业设计里太常见了大家关注的重点本来也就不在标题上而在于那一串技术栈SpringBoot、Vue、MySQL、MyBatis外加一个完整源码。这个组合可以说是当前Java全栈项目里最经典的一套没有之一。我印象中每年这个时候都会有人来问同一类问题养老院管理系统怎么做、前后端怎么连、MyBatis的复杂查询怎么写、Vue页面从哪开始搭。这篇文章我就结合自己做过的类似项目以及辅导过的几个同学踩过的坑把这个系统的设计思路、技术实现、数据库建模和部署运行完整拆一遍。不管你是拿来当毕业设计交差还是自己想练手做点能放上简历的东西这套内容都能直接拿去用。1. 为什么偏偏是SpringBootVue技术选型背后的现实逻辑1.1 从验收和面试两个角度倒推技术选型先说结论这个组合火不是因为它多潮而是因为它在能体现技术能力和不会把自己坑死之间取了最稳的平衡点。从项目验收的角度看SpringBoot把过去Spring MVC那一大堆XML配置、web.xml、监听器、过滤器全自动装配了一个main方法直接启动。这对学生来说意味着后端环境几乎零成本就能跑起来。Vue那边则是典型的前后端分离前端工程和后端工程可以分开讲、分开演示、分开截图放论文。答辩的时候你光靠这是前端工程、这是后端工程、他们通过接口通信这个基本事实就能讲出好几页PPT。而MyBatis的存在让SQL可控复杂查询你能手写不怕框架自动生成的SQL太笨这一点在涉及多表关联的业务里非常加分。从面试的角度看就更好理解了。现在Java后端岗位最常挂在职位描述里的几个词是什么SpringBoot、MyBatisMyBatis、MySQL。Vue则是大多数公司全栈岗和前端协作岗的常识性要求。这套系统做完之后你简历上写基于SpringBootVue的管理系统开发经验面试官看到的是你具备了一个完整Web项目从0到1的落地能力而不是单纯看过某个框架的文档。1.2 这套组合在工程里的真实分工很多人把前后端分离挂在嘴边但真正动手时还是会混成一团。我说一下这套组合里每一层到底负责什么SpringBoot后端应用的骨架。负责接收HTTP请求、处理后返回JSON数据。它自己不写SQL只负责调度Service层的业务逻辑。MyBatis持久层框架。负责把Java方法映射成SQL语句把数据库查询结果映射回Java对象。你可以把MyBatis理解为SQL翻译官它最大的价值是动态SQL。MySQL数据存储层。老人的基本信息、床位状态、缴费记录、护理记录全部落在这里。Vue前端界面层。负责渲染页面、收集用户操作、调用后端接口。配合Element UI不写一行CSS也能做出像样的管理后台。这是一套清晰的单向依赖链路Vue请求SpringBootSpringBoot调MyBatisMyBatis操作MySQL。理解了这个链路你后面看代码、改bug都会快很多。2. 养老院业务拆解管理系统到底在管什么2.1 从老人入院到退院的核心业务流很多同学拿到这类系统第一反应是不就是对几张表增删改查吗。这种想法会让你把项目写成一个毫无业务逻辑的CRUD空壳答辩时一问就露馅。养老院管理系统真正要管理的是完整业务流老人从咨询、入院、建档、入住到退院的整个生命周期。完整的业务流大概是这样的家属来院里参观咨询前台登记意向信息老人办理入院时做一次健康评估确定护理等级自理、半自理、全护理签完协议后分配房间和床位然后建立老人档案档案里包含身份信息、家属联系方式、既往病史、过敏史入住之后每天产生护理记录、健康监测记录、餐饮记录每个月或者每个季度做一次费用结算包括床位费、护理费、餐饮费、医疗耗材费如果老人离院办退住手续并结算押金。这些环节听起来多映射到系统里其实就是几个模块的事情但它们之间的数据关系必须贯穿。2.2 功能模块地图与角色权限围绕上面这条业务流系统要具备以下模块模块核心功能面向角色登录与权限登录认证、角色识别、菜单控制所有用户老人管理老人档案增删改查、入院登记、退院、家属信息维护前台、管理员房间床位管理房间信息维护、床位状态查看、床位分配前台、管理员护理管理每日护理记录录入、护理计划查看护理员健康档案管理体检记录、异常指标记录护理员、管理员费用管理费用项配置、账单生成、缴费登记财务、管理员访客管理访客登记、探访记录前台系统管理用户管理、角色管理、个人密码修改管理员权限这块我建议用简化版的角色区分而不是一上来就搞完整的RBAC五表结构。用户表里设计一个role字段取值admin、frontdesk、nurse、finance前端拿到角色后渲染不同的侧边菜单后端在拦截器里根据角色白名单放行接口就够了。原因很简单毕设和练手项目不需要那么重的权限设计维护成本反而拖慢进度如果你真想炫技再单独加一张权限表也不冲突。3. 数据库设计一张床位如何串联起整个系统3.1 核心表结构与字段设计数据库是这个系统最关键的部分。代码写错了可以改表结构设计烂了后面全是坑。我见过超多同学在项目后期痛苦无比本质原因就是当初建表时偷了懒外键关系没想清楚。这个系统的核心表我建议至少包含以下这些user用户表role角色表可选room房间表bed床位表elderly老人表caregiver护理人员表也可以并入user表nursing_record护理记录表health_record健康档案表fee_item费用项表fee_record缴费记录表visit_record访客记录表其中最关键的表是elderly和bed它们之间的关联决定了整个系统的数据走向。先看elderly表怎么做字段设计字段名类型说明idBIGINT主键自增nameVARCHAR(50)老人姓名genderTINYINT性别1男2女ageINT年龄id_cardVARCHAR(18)身份证号唯一索引phoneVARCHAR(20)老人或家属联系电话health_statusVARCHAR(255)健康情况简述allergy_infoVARCHAR(255)过敏史可以为空room_idBIGINT关联room表分配的房间bed_idBIGINT关联bed表分配的床位statusTINYINT在住1/退住0/预登记2create_timeDATETIME入院登记时间update_timeDATETIME信息更新时间deletedTINYINT逻辑删除标记这里有个容易忽略的点room_id和bed_id不一定同时、一定非空。老人入院登记时可能先登记档案例信息后面再分床所以这两个字段要允许为空。但是一旦分配了床位bed表里对应床位的状态就要立刻从空闲变成占用这一步藏在后端Service层里。3.2 字段类型、状态语义与逻辑删除的设计心得再聊几个设计细节都是实际开发里总结出来的金额一律用DECIMAL(10,2)。费用相关的字段别用FLOAT、DOUBLE否则算到分位时会遇到二进制浮点误差账单对不上非常尴尬。Java侧对应BigDecimal查询出来也不会丢精度。状态字段用TINYINT加注释别直接存active、inactive这种字符串。用数字的好处是存储小、索引快写SQL时看一眼注释就知道含义。逻辑删除必须做但不建议全局开启。elderly表、user表、fee_record这种核心表一定用deleted字段做逻辑删除这样误删了还能恢复答辩时也能说是考虑了数据审计需求。但注意不要把MyBatis的逻辑删除插件全局覆盖到所有表有些关联表删了就删了搞逻辑删除反而增加查询的负担。外键不要用物理外键。数据库里的FOREIGN KEY约束在真实项目和毕设里都是一个负担——插入顺序受限、删除受限、连表查询时需要额外的约束检查。我这个项目里所有外键关系都是逻辑外键存room_id、bed_id需要关联时用JOIN。缺点是需要你自己保证数据一致性但只要接口写规范问题不大。索引elderly表的id_card建唯一索引name建普通索引status建普通索引。bed表的status建索引因为你要频繁查哪些床位空闲。这些都是查询频率决定索引别想着给所有字段都建索引会拖慢插入速度。4. 后端实现SpringBootMyBatis的几个关键环节4.1 工程结构与统一返回结果后端工程结构我建议按业务划分包而不是按技术层划分。也就是说不要建一堆entity、mapper、service、controller的大杂烩包而是老人模块的Controller、Service、Mapper放在一起房间模块放在一起。这样后期加功能、改代码的时候所有相关文件都在眼前。每个Controller返回的数据格式必须是统一的。我常用的方式是封装一个Result类里面就三个字段code、message、data。成功时code是200失败时是500未登录是401。前端的axios拦截器只认这个结构拿到code不是200就弹错误提示。这样做的好处是前后端联调时不用每个接口单独约定格式省掉大量沟通成本。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String msg) { ResultT result new Result(); result.setCode(500); result.setMessage(msg); return result; } }4.2 MyBatis动态SQL条件分页查询的完整写法养老院管理系统里面最常用、也最考验Mapper功力的是老人列表的查询。这个功能表面上只是列表页实际上包含了三个难点关键字搜索、状态筛选、关联查询房间和床位信息。如果只用简单注解拼SQL代码会非常痛苦。比如前端传过来可能只有name可能只有status可能两个都有还可能为空查询全部。用MyBatis的动态SQL就非常优雅select idselectElderlyPage resultTypemap SELECT e.id, e.name, e.gender, e.age, e.id_card, e.phone, e.status, r.room_number, b.bed_number FROM elderly e LEFT JOIN room r ON e.room_id r.id LEFT JOIN bed b ON e.bed_id b.id where if testname ! null and name ! AND e.name LIKE CONCAT(%, #{name}, %) /if if teststatus ! null AND e.status #{status} /if if testroomId ! null AND e.room_id #{roomId} /if AND e.deleted 0 /where ORDER BY e.create_time DESC /select注意两个细节LIKE查询用了CONCAT(%, #{name}, %)而不是直接在Java里拼好再传进去这样可以防止SQL注入LEFT JOIN是因为老人可能还没分配房间床位如果用INNER JOIN会把这一部分人漏掉。这就是我为什么坚持用MyBatis而不是JPA——这种复杂的查询你完全能控制SQL的每一条细节不会被框架生成的性能垃圾影响。分页实现我推荐用PageHelper插件引入依赖后在Service层直接PageHelper.startPage(pageNum, pageSize)紧接着的第一个查询会被自动加上LIMIT同时返回PageInfo对象里带了总条数、总页数这些信息。前端分页组件直接用这些字段即可。4.3 JWT登录鉴权与全局异常处理登录功能是每个管理系统的标配但实现方式差别很大。我这里推荐一个适合本项目的方案JWT 拦截器。用户登录成功后后端生成一个JWT令牌把用户id和角色放进去往前端返回。前端把令牌存进localStorage之后每次请求都在Authorization头里带上。后端写一个拦截器放行登录接口和静态资源路径其余接口全部从Header解析JWT解析成功就放行解析失败返回401。这个方案的优点是不依赖Session也不需要在Redis里维护登录态对毕设项目来说足够清晰。涉及写操作的地方记得加事务注解。比如床位分配这个动作要干三件事更新elderly表的room_id和bed_id、把bed表的status改成占用、往操作日志里插一条记录。这三个动作必须有事务保证否则中间一步失败会出现老人有床位但床位状态还是空闲、或者老人信息更新了但日志没记录的脏数据。在Service方法上标注TransactionalSpring会自动帮你回滚。全局异常处理用RestControllerAdvice统一兜底。Controller里不要到处try-catch包业务异常而是抛出自定义业务异常由全局异常处理器统一捕捉并转换为Result.error返回。这样前端拿到的永远是统一格式不会偶尔蹦出来一个500 HTML页面。5. Vue前端管理后台的开发套路5.1 工程创建、路由与权限菜单前端工程用Vue CLI或者Vite创建都可以。如果你Node版本是16以上我建议直接用Vite创建Vue 3项目开发服务器启动速度比Webpack快很多。如果学校要求Vue 2也没问题把本文中的Element UI换成Element Plus或者Element UI注意版本差异即可。路由和权限这块最省力的方案是路由表全部静态注册在router/index.js里但每个路由的meta里加一个roles数组。前端在登录后从后端拿到当前用户角色在全局前置守卫里判断当前要跳转的路由是否包含该角色没有就跳404页。侧边菜单也基于路由表渲染按角色过滤出可见项。这个方案省掉动态路由的复杂逻辑但效果上足够唬人。// 路由示例 { path: elderly, name: ElderlyManage, component: () import(/views/elderly/index.vue), meta: { title: 老人管理, roles: [admin, frontdesk] } }5.2 表格页面三件套el-table、el-form、el-dialog管理后台最重复、最模板化的工作就是列表页和表单弹窗。我的经验是花一下午把一套通用页面模板写好后面所有模块直接复制改名。以老人管理页面为例核心骨架是el-table展示列表每一列对应一个字段操作列放编辑退住查看按钮。顶部放el-form作为搜索条件包括姓名输入框、状态下拉框、查询和重置按钮。新增和编辑用一个el-dialog弹窗里面是el-form字段对应elderly表的属性床位的分配用el-select联动接口查空闲床位。底部用el-pagination分页组件当前页和页大小绑定到data变量点击翻页重新调接口。这个组合好用在哪里Element UI的表格自带排序、空数据占位弹窗表单有自带的校验规则必填、手机号格式、年龄范围你不需要为每个模块造轮子。唯一要注意的是表单校验规则必须和后端一致比如前端规定年龄在0到120之间后端也要再做一次校验永远不要信任前端传过来的数据。5.3 axios封装与跨域联调直接在每个页面里调axios很不优雅而且一旦请求地址变了或者要统一处理错误提示你会改到怀疑人生。我的习惯是在api目录下做一个request.js文件封装axios实例并配置请求拦截器和响应拦截器// request.js const service axios.create({ baseURL: /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) { this.$message.error(res.message); return Promise.reject(new Error(res.message)); } return res; }, error { if (error.response error.response.status 401) { this.$message.error(登录已过期请重新登录); localStorage.clear(); window.location.href /login; } return Promise.reject(error); } );后端启动在8080端口前端启动在8081端口直接请求跨域报错。解决办法两选一后端加CORS配置或者前端在vue.config.js里配置devServer的proxy代理。你来看这套系统时如果两个工程都跑在本机用proxy是最省事的——前端的baseURL写成/api代理把/api开头的请求转发到localhost:8080浏览器完全感知不到跨域的存在。6. 部署运行与高频踩坑汇总6.1 从零跑起来的完整步骤拿到完整源码之后想要顺利跑起来我建议按下面这个顺序走检查本机环境。JDK 1.8Maven 3.6以上MySQL 5.7或8.0Node.js 16左右一个IDEA和一个VSCode或WebStorm。创建数据库。在MySQL里执行项目提供的sql脚本注意脚本里的CREATE DATABASE语句可能需要手动改库名。修改后端配置。打开application.yml确认数据库名、账号密码、端口号是否正确时区设置是否有serverTimezoneAsia/Shanghai。启动后端。IDEA里打开后端工程等待Maven依赖下载完运行主类上的main方法。看到Spring Boot启动日志里出现Tomcat started on port 8080就算成功。安装前端依赖。在Vue工程目录下执行npm install这一步如果慢可以换国内镜像。启动前端。npm run dev或者npm run serve浏览器访问localhost:8081能弹出登录页就说明前端工程没问题。联调。用项目文档里的默认账号密码登录试着查询老人列表、分配床位、新增缴费记录观察前后端是否正常通信。6.2 我见过的五个高频坑和处理方法这个项目我在辅导过程中见过的问题集中在下面几个地方现象原因处理方法启动报错Communications link failure或者时区警告MySQL连接配置中时区未设置或者驱动版本不匹配在JDBC URL后加serverTimezoneAsia/ShanghaiuseSSLfalseMySQL 8必须用com.mysql.cj.jdbc.Driver前端登录页正常但登录后列表接口报403、404前端代理没有配置或者后端拦截器拦截了OPTIONS预检请求检查vue.config.js里的proxy拦截器放行OPTIONS请求方法IDEA编译报找不到lombok的getter/setterLombok插件未安装或者pom依赖版不兼容安装Lombok插件或把代码改成手写getter/setter最稳妥npm install报版本冲突ERR!Node版本与Vue CLI不兼容用nvm切换到Node 16删除node_modules重新安装图片/文件上传后刷新页面打不开前端访问了源码文件目录不存在的绝对路径后台上传时把相对路径和文件名存数据库前端拼接后端地址访问第六个坑是本地文件上传路径这个是很多同学最容易忽略的。上传图片如果直接写死一个本地磁盘路径比如D:/upload部署到别的机器就崩了。正确做法是上传到项目运行目录下的一个静态资源映射路径然后在Spring配置里通过WebMvcConfigurer做资源映射这样整个项目是一个相对自包含的可移植工程。7. 拿到源码之后阅读顺序与二次开发方向7.1 推荐的源码阅读顺序拿到别人的源码第一件事别急着点运行先阅读搞懂结构再动手。我推荐的阅读顺序是先看数据库脚本。把所有表结构过一遍理解每张表的作用和表间关系。这一步最快建立全局认知。再看后端entity和Mapper。看实体类字段与表字段的映射关系看XML里SQL的写法和表关联方式。然后按业务走一遍Service和Controller。不要按目录顺序读而是按业务故事线走。例如从老人入住这个动作开始看Controller入口、Service逻辑、Mapper SQL三条线是怎么串起来的。最后看前端。先看路由配置和api目录再看一个典型的列表页实现理解页面是怎么调接口的。如果执行完这四步你大概花费两到三个小时但之后无论改bug还是加功能你都胸有成竹。7.2 三个值得做的二次开发方向如果你想让它不只是拿来交差而是成为面试时的谈资我建议从下面三个方向挑一个动手改第一个方向是统计报表可视化。给系统增加一个Dashboard页统计当前在住老人数、空床位数、本月营收、护理等级分布用ECharts画柱状图、饼图和趋势线。这些数据全部来自现有表结构的聚合查询业务上非常合理视觉冲击力又强答辩演示时放第二页PPT完全没有问题。第二个方向是护工排班日历。养老院里护理员是按班次上班的给护理模块增加一个排班功能前端用日历组件展示某个月份每个护工的班次后端对应排班表的增删改查。这个功能与现有用户表、护理记录表都能产生关联做出来的系统就从一个档案管理工具升级成了运营管理工具。第三个方向是消息通知和待办提醒。比如老人生日自动提醒、退住流程审批通知、费用账单到期提醒。可以用一个简单的通知表加上前端轮询接口实现轮询或者直接引入WebSocket在护士站大屏和前端页面上推送提醒。这个方向能明显提升系统的智能化观感而且代码量不大。我个人觉得二开的关键不是功能的多少和华丽程度而是你敢不敢改核心逻辑、能不能说清楚改完之后的收益。哪怕只是给床位分配功能加了连续选择多个空床位批量分配你在面试时讲这件具体的事也比说我做了个管理系统强十倍。最后分享一点带人做这类项目的体会拿到一个管理系统的源码最忌讳的就是把它当成纯粹的代码拼装其实你真正吃透了一个业务领域里数据是怎么流转的、状态是怎么变化的、角色是怎么协作的那套方法论可以迁移到任何行业的管理软件里。养老院管理系统只不过恰好选了一块业务足够清晰、又足够有人情味的场景。带着这个视角去读代码收获会比多写一个模块大得多。
拿到这个标题的时候我多看了一眼——养老院管理系统管理系统系统两个字打了两遍。不过说实话这种命名在课程设计和毕业设计里太常见了大家关注的重点本来也就不在标题上而在于那一串技术栈SpringBoot、Vue、MySQL、MyBatis外加一个完整源码。这个组合可以说是当前Java全栈项目里最经典的一套没有之一。我印象中每年这个时候都会有人来问同一类问题养老院管理系统怎么做、前后端怎么连、MyBatis的复杂查询怎么写、Vue页面从哪开始搭。这篇文章我就结合自己做过的类似项目以及辅导过的几个同学踩过的坑把这个系统的设计思路、技术实现、数据库建模和部署运行完整拆一遍。不管你是拿来当毕业设计交差还是自己想练手做点能放上简历的东西这套内容都能直接拿去用。1. 为什么偏偏是SpringBootVue技术选型背后的现实逻辑1.1 从验收和面试两个角度倒推技术选型先说结论这个组合火不是因为它多潮而是因为它在能体现技术能力和不会把自己坑死之间取了最稳的平衡点。从项目验收的角度看SpringBoot把过去Spring MVC那一大堆XML配置、web.xml、监听器、过滤器全自动装配了一个main方法直接启动。这对学生来说意味着后端环境几乎零成本就能跑起来。Vue那边则是典型的前后端分离前端工程和后端工程可以分开讲、分开演示、分开截图放论文。答辩的时候你光靠这是前端工程、这是后端工程、他们通过接口通信这个基本事实就能讲出好几页PPT。而MyBatis的存在让SQL可控复杂查询你能手写不怕框架自动生成的SQL太笨这一点在涉及多表关联的业务里非常加分。从面试的角度看就更好理解了。现在Java后端岗位最常挂在职位描述里的几个词是什么SpringBoot、MyBatisMyBatis、MySQL。Vue则是大多数公司全栈岗和前端协作岗的常识性要求。这套系统做完之后你简历上写基于SpringBootVue的管理系统开发经验面试官看到的是你具备了一个完整Web项目从0到1的落地能力而不是单纯看过某个框架的文档。1.2 这套组合在工程里的真实分工很多人把前后端分离挂在嘴边但真正动手时还是会混成一团。我说一下这套组合里每一层到底负责什么SpringBoot后端应用的骨架。负责接收HTTP请求、处理后返回JSON数据。它自己不写SQL只负责调度Service层的业务逻辑。MyBatis持久层框架。负责把Java方法映射成SQL语句把数据库查询结果映射回Java对象。你可以把MyBatis理解为SQL翻译官它最大的价值是动态SQL。MySQL数据存储层。老人的基本信息、床位状态、缴费记录、护理记录全部落在这里。Vue前端界面层。负责渲染页面、收集用户操作、调用后端接口。配合Element UI不写一行CSS也能做出像样的管理后台。这是一套清晰的单向依赖链路Vue请求SpringBootSpringBoot调MyBatisMyBatis操作MySQL。理解了这个链路你后面看代码、改bug都会快很多。2. 养老院业务拆解管理系统到底在管什么2.1 从老人入院到退院的核心业务流很多同学拿到这类系统第一反应是不就是对几张表增删改查吗。这种想法会让你把项目写成一个毫无业务逻辑的CRUD空壳答辩时一问就露馅。养老院管理系统真正要管理的是完整业务流老人从咨询、入院、建档、入住到退院的整个生命周期。完整的业务流大概是这样的家属来院里参观咨询前台登记意向信息老人办理入院时做一次健康评估确定护理等级自理、半自理、全护理签完协议后分配房间和床位然后建立老人档案档案里包含身份信息、家属联系方式、既往病史、过敏史入住之后每天产生护理记录、健康监测记录、餐饮记录每个月或者每个季度做一次费用结算包括床位费、护理费、餐饮费、医疗耗材费如果老人离院办退住手续并结算押金。这些环节听起来多映射到系统里其实就是几个模块的事情但它们之间的数据关系必须贯穿。2.2 功能模块地图与角色权限围绕上面这条业务流系统要具备以下模块模块核心功能面向角色登录与权限登录认证、角色识别、菜单控制所有用户老人管理老人档案增删改查、入院登记、退院、家属信息维护前台、管理员房间床位管理房间信息维护、床位状态查看、床位分配前台、管理员护理管理每日护理记录录入、护理计划查看护理员健康档案管理体检记录、异常指标记录护理员、管理员费用管理费用项配置、账单生成、缴费登记财务、管理员访客管理访客登记、探访记录前台系统管理用户管理、角色管理、个人密码修改管理员权限这块我建议用简化版的角色区分而不是一上来就搞完整的RBAC五表结构。用户表里设计一个role字段取值admin、frontdesk、nurse、finance前端拿到角色后渲染不同的侧边菜单后端在拦截器里根据角色白名单放行接口就够了。原因很简单毕设和练手项目不需要那么重的权限设计维护成本反而拖慢进度如果你真想炫技再单独加一张权限表也不冲突。3. 数据库设计一张床位如何串联起整个系统3.1 核心表结构与字段设计数据库是这个系统最关键的部分。代码写错了可以改表结构设计烂了后面全是坑。我见过超多同学在项目后期痛苦无比本质原因就是当初建表时偷了懒外键关系没想清楚。这个系统的核心表我建议至少包含以下这些user用户表role角色表可选room房间表bed床位表elderly老人表caregiver护理人员表也可以并入user表nursing_record护理记录表health_record健康档案表fee_item费用项表fee_record缴费记录表visit_record访客记录表其中最关键的表是elderly和bed它们之间的关联决定了整个系统的数据走向。先看elderly表怎么做字段设计字段名类型说明idBIGINT主键自增nameVARCHAR(50)老人姓名genderTINYINT性别1男2女ageINT年龄id_cardVARCHAR(18)身份证号唯一索引phoneVARCHAR(20)老人或家属联系电话health_statusVARCHAR(255)健康情况简述allergy_infoVARCHAR(255)过敏史可以为空room_idBIGINT关联room表分配的房间bed_idBIGINT关联bed表分配的床位statusTINYINT在住1/退住0/预登记2create_timeDATETIME入院登记时间update_timeDATETIME信息更新时间deletedTINYINT逻辑删除标记这里有个容易忽略的点room_id和bed_id不一定同时、一定非空。老人入院登记时可能先登记档案例信息后面再分床所以这两个字段要允许为空。但是一旦分配了床位bed表里对应床位的状态就要立刻从空闲变成占用这一步藏在后端Service层里。3.2 字段类型、状态语义与逻辑删除的设计心得再聊几个设计细节都是实际开发里总结出来的金额一律用DECIMAL(10,2)。费用相关的字段别用FLOAT、DOUBLE否则算到分位时会遇到二进制浮点误差账单对不上非常尴尬。Java侧对应BigDecimal查询出来也不会丢精度。状态字段用TINYINT加注释别直接存active、inactive这种字符串。用数字的好处是存储小、索引快写SQL时看一眼注释就知道含义。逻辑删除必须做但不建议全局开启。elderly表、user表、fee_record这种核心表一定用deleted字段做逻辑删除这样误删了还能恢复答辩时也能说是考虑了数据审计需求。但注意不要把MyBatis的逻辑删除插件全局覆盖到所有表有些关联表删了就删了搞逻辑删除反而增加查询的负担。外键不要用物理外键。数据库里的FOREIGN KEY约束在真实项目和毕设里都是一个负担——插入顺序受限、删除受限、连表查询时需要额外的约束检查。我这个项目里所有外键关系都是逻辑外键存room_id、bed_id需要关联时用JOIN。缺点是需要你自己保证数据一致性但只要接口写规范问题不大。索引elderly表的id_card建唯一索引name建普通索引status建普通索引。bed表的status建索引因为你要频繁查哪些床位空闲。这些都是查询频率决定索引别想着给所有字段都建索引会拖慢插入速度。4. 后端实现SpringBootMyBatis的几个关键环节4.1 工程结构与统一返回结果后端工程结构我建议按业务划分包而不是按技术层划分。也就是说不要建一堆entity、mapper、service、controller的大杂烩包而是老人模块的Controller、Service、Mapper放在一起房间模块放在一起。这样后期加功能、改代码的时候所有相关文件都在眼前。每个Controller返回的数据格式必须是统一的。我常用的方式是封装一个Result类里面就三个字段code、message、data。成功时code是200失败时是500未登录是401。前端的axios拦截器只认这个结构拿到code不是200就弹错误提示。这样做的好处是前后端联调时不用每个接口单独约定格式省掉大量沟通成本。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String msg) { ResultT result new Result(); result.setCode(500); result.setMessage(msg); return result; } }4.2 MyBatis动态SQL条件分页查询的完整写法养老院管理系统里面最常用、也最考验Mapper功力的是老人列表的查询。这个功能表面上只是列表页实际上包含了三个难点关键字搜索、状态筛选、关联查询房间和床位信息。如果只用简单注解拼SQL代码会非常痛苦。比如前端传过来可能只有name可能只有status可能两个都有还可能为空查询全部。用MyBatis的动态SQL就非常优雅select idselectElderlyPage resultTypemap SELECT e.id, e.name, e.gender, e.age, e.id_card, e.phone, e.status, r.room_number, b.bed_number FROM elderly e LEFT JOIN room r ON e.room_id r.id LEFT JOIN bed b ON e.bed_id b.id where if testname ! null and name ! AND e.name LIKE CONCAT(%, #{name}, %) /if if teststatus ! null AND e.status #{status} /if if testroomId ! null AND e.room_id #{roomId} /if AND e.deleted 0 /where ORDER BY e.create_time DESC /select注意两个细节LIKE查询用了CONCAT(%, #{name}, %)而不是直接在Java里拼好再传进去这样可以防止SQL注入LEFT JOIN是因为老人可能还没分配房间床位如果用INNER JOIN会把这一部分人漏掉。这就是我为什么坚持用MyBatis而不是JPA——这种复杂的查询你完全能控制SQL的每一条细节不会被框架生成的性能垃圾影响。分页实现我推荐用PageHelper插件引入依赖后在Service层直接PageHelper.startPage(pageNum, pageSize)紧接着的第一个查询会被自动加上LIMIT同时返回PageInfo对象里带了总条数、总页数这些信息。前端分页组件直接用这些字段即可。4.3 JWT登录鉴权与全局异常处理登录功能是每个管理系统的标配但实现方式差别很大。我这里推荐一个适合本项目的方案JWT 拦截器。用户登录成功后后端生成一个JWT令牌把用户id和角色放进去往前端返回。前端把令牌存进localStorage之后每次请求都在Authorization头里带上。后端写一个拦截器放行登录接口和静态资源路径其余接口全部从Header解析JWT解析成功就放行解析失败返回401。这个方案的优点是不依赖Session也不需要在Redis里维护登录态对毕设项目来说足够清晰。涉及写操作的地方记得加事务注解。比如床位分配这个动作要干三件事更新elderly表的room_id和bed_id、把bed表的status改成占用、往操作日志里插一条记录。这三个动作必须有事务保证否则中间一步失败会出现老人有床位但床位状态还是空闲、或者老人信息更新了但日志没记录的脏数据。在Service方法上标注TransactionalSpring会自动帮你回滚。全局异常处理用RestControllerAdvice统一兜底。Controller里不要到处try-catch包业务异常而是抛出自定义业务异常由全局异常处理器统一捕捉并转换为Result.error返回。这样前端拿到的永远是统一格式不会偶尔蹦出来一个500 HTML页面。5. Vue前端管理后台的开发套路5.1 工程创建、路由与权限菜单前端工程用Vue CLI或者Vite创建都可以。如果你Node版本是16以上我建议直接用Vite创建Vue 3项目开发服务器启动速度比Webpack快很多。如果学校要求Vue 2也没问题把本文中的Element UI换成Element Plus或者Element UI注意版本差异即可。路由和权限这块最省力的方案是路由表全部静态注册在router/index.js里但每个路由的meta里加一个roles数组。前端在登录后从后端拿到当前用户角色在全局前置守卫里判断当前要跳转的路由是否包含该角色没有就跳404页。侧边菜单也基于路由表渲染按角色过滤出可见项。这个方案省掉动态路由的复杂逻辑但效果上足够唬人。// 路由示例 { path: elderly, name: ElderlyManage, component: () import(/views/elderly/index.vue), meta: { title: 老人管理, roles: [admin, frontdesk] } }5.2 表格页面三件套el-table、el-form、el-dialog管理后台最重复、最模板化的工作就是列表页和表单弹窗。我的经验是花一下午把一套通用页面模板写好后面所有模块直接复制改名。以老人管理页面为例核心骨架是el-table展示列表每一列对应一个字段操作列放编辑退住查看按钮。顶部放el-form作为搜索条件包括姓名输入框、状态下拉框、查询和重置按钮。新增和编辑用一个el-dialog弹窗里面是el-form字段对应elderly表的属性床位的分配用el-select联动接口查空闲床位。底部用el-pagination分页组件当前页和页大小绑定到data变量点击翻页重新调接口。这个组合好用在哪里Element UI的表格自带排序、空数据占位弹窗表单有自带的校验规则必填、手机号格式、年龄范围你不需要为每个模块造轮子。唯一要注意的是表单校验规则必须和后端一致比如前端规定年龄在0到120之间后端也要再做一次校验永远不要信任前端传过来的数据。5.3 axios封装与跨域联调直接在每个页面里调axios很不优雅而且一旦请求地址变了或者要统一处理错误提示你会改到怀疑人生。我的习惯是在api目录下做一个request.js文件封装axios实例并配置请求拦截器和响应拦截器// request.js const service axios.create({ baseURL: /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) { this.$message.error(res.message); return Promise.reject(new Error(res.message)); } return res; }, error { if (error.response error.response.status 401) { this.$message.error(登录已过期请重新登录); localStorage.clear(); window.location.href /login; } return Promise.reject(error); } );后端启动在8080端口前端启动在8081端口直接请求跨域报错。解决办法两选一后端加CORS配置或者前端在vue.config.js里配置devServer的proxy代理。你来看这套系统时如果两个工程都跑在本机用proxy是最省事的——前端的baseURL写成/api代理把/api开头的请求转发到localhost:8080浏览器完全感知不到跨域的存在。6. 部署运行与高频踩坑汇总6.1 从零跑起来的完整步骤拿到完整源码之后想要顺利跑起来我建议按下面这个顺序走检查本机环境。JDK 1.8Maven 3.6以上MySQL 5.7或8.0Node.js 16左右一个IDEA和一个VSCode或WebStorm。创建数据库。在MySQL里执行项目提供的sql脚本注意脚本里的CREATE DATABASE语句可能需要手动改库名。修改后端配置。打开application.yml确认数据库名、账号密码、端口号是否正确时区设置是否有serverTimezoneAsia/Shanghai。启动后端。IDEA里打开后端工程等待Maven依赖下载完运行主类上的main方法。看到Spring Boot启动日志里出现Tomcat started on port 8080就算成功。安装前端依赖。在Vue工程目录下执行npm install这一步如果慢可以换国内镜像。启动前端。npm run dev或者npm run serve浏览器访问localhost:8081能弹出登录页就说明前端工程没问题。联调。用项目文档里的默认账号密码登录试着查询老人列表、分配床位、新增缴费记录观察前后端是否正常通信。6.2 我见过的五个高频坑和处理方法这个项目我在辅导过程中见过的问题集中在下面几个地方现象原因处理方法启动报错Communications link failure或者时区警告MySQL连接配置中时区未设置或者驱动版本不匹配在JDBC URL后加serverTimezoneAsia/ShanghaiuseSSLfalseMySQL 8必须用com.mysql.cj.jdbc.Driver前端登录页正常但登录后列表接口报403、404前端代理没有配置或者后端拦截器拦截了OPTIONS预检请求检查vue.config.js里的proxy拦截器放行OPTIONS请求方法IDEA编译报找不到lombok的getter/setterLombok插件未安装或者pom依赖版不兼容安装Lombok插件或把代码改成手写getter/setter最稳妥npm install报版本冲突ERR!Node版本与Vue CLI不兼容用nvm切换到Node 16删除node_modules重新安装图片/文件上传后刷新页面打不开前端访问了源码文件目录不存在的绝对路径后台上传时把相对路径和文件名存数据库前端拼接后端地址访问第六个坑是本地文件上传路径这个是很多同学最容易忽略的。上传图片如果直接写死一个本地磁盘路径比如D:/upload部署到别的机器就崩了。正确做法是上传到项目运行目录下的一个静态资源映射路径然后在Spring配置里通过WebMvcConfigurer做资源映射这样整个项目是一个相对自包含的可移植工程。7. 拿到源码之后阅读顺序与二次开发方向7.1 推荐的源码阅读顺序拿到别人的源码第一件事别急着点运行先阅读搞懂结构再动手。我推荐的阅读顺序是先看数据库脚本。把所有表结构过一遍理解每张表的作用和表间关系。这一步最快建立全局认知。再看后端entity和Mapper。看实体类字段与表字段的映射关系看XML里SQL的写法和表关联方式。然后按业务走一遍Service和Controller。不要按目录顺序读而是按业务故事线走。例如从老人入住这个动作开始看Controller入口、Service逻辑、Mapper SQL三条线是怎么串起来的。最后看前端。先看路由配置和api目录再看一个典型的列表页实现理解页面是怎么调接口的。如果执行完这四步你大概花费两到三个小时但之后无论改bug还是加功能你都胸有成竹。7.2 三个值得做的二次开发方向如果你想让它不只是拿来交差而是成为面试时的谈资我建议从下面三个方向挑一个动手改第一个方向是统计报表可视化。给系统增加一个Dashboard页统计当前在住老人数、空床位数、本月营收、护理等级分布用ECharts画柱状图、饼图和趋势线。这些数据全部来自现有表结构的聚合查询业务上非常合理视觉冲击力又强答辩演示时放第二页PPT完全没有问题。第二个方向是护工排班日历。养老院里护理员是按班次上班的给护理模块增加一个排班功能前端用日历组件展示某个月份每个护工的班次后端对应排班表的增删改查。这个功能与现有用户表、护理记录表都能产生关联做出来的系统就从一个档案管理工具升级成了运营管理工具。第三个方向是消息通知和待办提醒。比如老人生日自动提醒、退住流程审批通知、费用账单到期提醒。可以用一个简单的通知表加上前端轮询接口实现轮询或者直接引入WebSocket在护士站大屏和前端页面上推送提醒。这个方向能明显提升系统的智能化观感而且代码量不大。我个人觉得二开的关键不是功能的多少和华丽程度而是你敢不敢改核心逻辑、能不能说清楚改完之后的收益。哪怕只是给床位分配功能加了连续选择多个空床位批量分配你在面试时讲这件具体的事也比说我做了个管理系统强十倍。最后分享一点带人做这类项目的体会拿到一个管理系统的源码最忌讳的就是把它当成纯粹的代码拼装其实你真正吃透了一个业务领域里数据是怎么流转的、状态是怎么变化的、角色是怎么协作的那套方法论可以迁移到任何行业的管理软件里。养老院管理系统只不过恰好选了一块业务足够清晰、又足够有人情味的场景。带着这个视角去读代码收获会比多写一个模块大得多。
