SpringBoot+Vue养老公寓管理系统：前后端分离毕设项目实战解析

1. 项目概述与核心价值做毕设的时候很多人会卡在同一个地方题目选好了框架也会用但真要把一个完整系统从零到一搭出来涉及到的东西远比想象中多数据表怎么設計、接口怎么规划、前端怎么对接、部署的时候又是怎么一回事每一步都可能让人折腾几天。今天分享的这个项目——SpringBoot Vue 大健康养老公寓管理系统正好把这些环节完整走了一遍而且把源码、SQL脚本、接口文档都整理好了非常适合用来做Java Web方向的毕业设计或者给想入门前后端分离开发的同学当练手项目。这套系统的定位很清晰面向养老公寓的实际运营场景围绕老人的日常生活和健康管理把入住管理、健康档案、护理任务、用药提醒、家属访问这些业务串起来形成一个可运行的管理平台。业务上没有刻意堆砌复杂功能但覆盖了一个真实项目该有的核心环节老人信息的增删改查、健康指标的录入和趋势展示、房间状态的动态流转、护工任务的分配与跟踪都做得比较完整。前端用Vue Element UI搭建界面后端用SpringBoot提供接口MySQL承接数据存储整体技术栈非常主流也是目前市面上Java Web毕设最常用的组合。这套系统适合谁来参考如果你正在准备计算机相关专业的毕业设计尤其是想做前后端分离项目但还没完整跑通过一个全流程项目的那这份源码和配套文档能帮你省下大量踩坑的时间。如果你是想转行做Java开发需要一个中等复杂度项目来练习SpringBoot Vue协作开发这套系统同样是不错的参照物。项目里的SQL脚本可以直接导入数据库接口文档把每个接口的地址、参数、返回结构都列清楚了照着文档就能把前端页面跑起来前后端联调的过程非常顺畅。2. 系统架构与功能模块设计1.1 前后端分离的整体架构思路养老公寓管理系统采用前后端完全分离的架构后端只负责业务逻辑和数据接口前端独立开发和部署两者通过HTTP JSON进行数据交换。这样做的好处很直接前后端可以进行并行开发互不阻塞而且前端页面和后端服务可以分别部署在不同的服务器上将来做负载均衡或模块拆分也方便得多。后端的核心框架选的是SpringBoot理由很实在SpringBoot把Spring生态里大量繁琐的配置自动化了开发阶段不需要再手动编写XML配置文件主类一启动就能跑起来这对毕设项目来说极其友好。项目里用到了Spring Boot 2.7.x版本配合MyBatis-Plus作为持久层框架数据库操作以Mapper接口加注解为主复杂查询则写在XML文件中维护代码量比纯MyBatis大幅减少。权限控制这块用了Sa-Token或者Spring Security这类轻量级安全框架没有把所有接口裸奔出来登录后签发Token前端请求时在Header中携带后端通过拦截器校验身份虽然毕设场景对安全性的要求不会极度严苛但该有的闭环还是要有的。前端基于Vue全家桶搭建项目工程化结构比较标准vue.config.js负责构建配置src目录下区分了api、router、store、views、components几个核心目录每个目录职责单一。UI组件库选的Element UI配合Vue Router实现页面路由切换页面之间的状态管理交给Vuex网络请求统一封装了Axios实例基础URL、超时时间、Token注入、错误拦截全在这一层处理页面里不需要重复写这些逻辑。整个系统的数据流大概是这样的前端用户在页面上触发操作Axios把请求发到后端对应的Controller接口Controller接收参数校验身份调用Service层处理业务规则Service依赖Mapper操作数据库拿到结果再逐层返回给前端渲染。分层结构虽然没有刻意追求过度设计但Controller、Service、Mapper、Entity、DTO几个层次划分得很标准将来要扩展新功能的时候照着现有代码的套路加一层即可。1.2 功能模块拆解养老公寓的数字化管理闭环这套系统在功能模块划分上紧紧围绕“老人的日常照护”这条主线来设计一共拆成七个核心模块每个模块都对应真实的业务场景不会让人觉得功能是凭空拼凑的。老人档案管理是所有业务的基础。公寓里每一位入住的老人都会建立一份电子档案除了姓名、性别、出生日期、身份证号、联系方式这些基础字段外还包括入住日期、紧急联系人、既往病史、过敏药物、生活偏好等信息。这些字段在设计数据库时就要考虑好长度和类型比如联系电话统一用varchar而不是数字类型因为手机号可能会涉及隐私显示处理编辑器里也可能会混入特殊标记。老人档案模块支持新增、编辑、批量导入、按条件检索列表分页显示状态字段区分正常入住和已退住。健康监测管理是这套系统的一大特色。老人每天的基础体征数据比如血压、心率、血氧、体温、血糖都可以通过后台录入也可以预留接口对接智能手环等物联网设备。每次录入的数据会存入独立的体征记录表页面端通过ECharts图表把一段时间内的趋势线画出来护士长看一眼就能判断老人近期的身体状态是否稳定。这个模块里还设置了异常阈值判断当某次体征数据超出正常范围时系统自动给对应护工的待办列表里推送一条重点关注提醒这是普通CRUD系统之外的亮点功能。公寓房间管理负责楼栋、楼层、房型以及房间状态的维护。房间状态分为空闲、已入住、维修中、保洁中四种当老人办理入住时选择对应房间状态自动变为已入住退住时释放为空闲。房间与老人是一对一关系所以在数据库设计时老人表里会有一个room_id外键字段同时房间表里记录当前入住老人的ID两边互相关联页面上能方便地查到房间里住的是哪位老人也能查到某位老人住在哪个房间。护理任务管理把护工的日常工作数字化。管理员可以创建周期性的护理任务例如每天早晚各一次的血压测量每周两次的洗澡辅助等系统按规则自动生成当天的待办任务分配给指定护工。护工登录后能在个人工作台看到自己当天需要完成的全部任务逐项确认完成并登记执行时间。任务还支持主动指派和临时加派灵活应对突发情况任务完成的数据也会沉淀为统计数据月底可以用来核算护工的工作量。用药提醒管理针对需要长期服药的老人设计。系统维护每位老人的用药计划包括药品名称、剂量、服药时间、用药周期配置好之后系统会在每天的指定时间生成用药提醒页面上的待办中心会弹出提醒卡片。护工完成给药操作后在系统里确认系统自动记录执行人和执行时间形成完整的用药记录方便后期追溯。访客与家属管理负责来访人员登记和信息通知流程。家属预约来访后录入系统被访老人的信息自动关联访客到达公寓前台时前台可以快速查询预约记录确认身份后放行。系统还能给家属预留的监护人手机号发送短信通知提醒老人已安全到达或身体状态有变化虽然短信服务需要第三方平台的密钥但代码层面已经预留了对接位。告警与工单管理作为兜底模块把所有异常情况统一汇集。健康数据异常、设备离线、老人主动求助等场景会产生告警事件系统按紧急程度分色显示普通级别的告警自动关闭紧急级别的需要人工确认并生成工单指派给对应负责人处理。这个模块让系统从“记录台账”真正升维成“主动管理”也是答辩时拿得出手的亮点部分。3. 数据库设计与SQL脚本核心实现2.1 表结构设计字段规划与关联关系拿到SQL脚本之后第一步当然是导入数据库但建议先花点时间把表结构整体过一遍理解每张表为什么这样设计这样后面遇到问题也好排查。先看核心的老人信息表。这张表字段比较多除了常规个人信息外重点要注意的是业务状态字段——status用tinyint类型0表示正常入住1表示已退住2表示临时外出这类状态字段不要用varchar来存文字描述否则后续统计和检索都非常痛苦。老人表关联的关键外键包括room_id、caregiver_id、user_idroom_id关联房间表caregiver_id关联护工表user_id关联登录账户表通过这三个外键把业务数据串起来。健康体征记录表是数据量增长最快的一张表每位老人每天如果有三组体征数据一百位老人跑一年就是十几万条记录所以这张表在设计时特别留意了索引。查询的主要维度是老人ID和时间范围所以建立了联合索引(older_id, measure_time)查询语句会直接命中索引不会全表扫描。关于索引的取舍这里多说一句单表索引不是越多越好每次写入都要维护索引结构索引太多反而影响写入性能所以只给最常作为查询条件的字段加索引。房间表里有一个值得注意的设计细节房间编号使用了冗余字段而不是每次都用楼栋号、楼层号、房号拼接生成比如building_no floor_no room_no这样一个唯一的字符串编号直接在表中冗余存储。这样做的好处是前端展示列表时不需要重新拼接逻辑直接取这个字段即可查询和显示都方便。用户与角色相关表的设计遵循了RBAC模型的基本思想用户表、角色表、用户角色关联表三件套没有权限模块的话很多系统是不完整的。角色表里预设了管理员、护士长、护工、前台四种角色每种角色对应的菜单权限和按钮权限在前端路由里做了配置后端接口也有对应的角色校验逻辑。日志相关的表包括登录日志和操作日志。登录日志记录每次登录的IP、时间、浏览器信息操作日志记录用户进行了什么操作、操作了哪些业务数据。虽然日志表在功能演示时存在感不强但系统运维排查问题的时候非常依赖这些数据实际项目里日志设计往往会单独做一套配合ELK之类的日志平台使用毕设里先用数据库表的方式记录逻辑上已经足够完整了。2.2 SQL脚本的关键点解读与初始化数据项目附带的SQL脚本做的比较完整覆盖了建库、建表、初始化数据三个层面拿到手之后基本上一条命令就能把数据库环境准备好。整个脚本的结构是这样的最前面是创建数据库的语句指定字符集为utf8mb4排序规则选utf8mb4_general_ci。关于字符集的选型值得说一句utf8mb4是标准能完整支持四字节的Unicode字符包括emoji和生僻汉字养老公寓系统里老人名字可能会涉及到不常见的字用utf8创建数据库就存在存储失败的风险这是一个很容易踩的坑。建表语句里可以看到每张表都有id字段统一使用bigint自增主键表名和字段名都用了下划线命名法这是配合MyBatis-Plus默认的驼峰转换规则。MyBatis-Plus默认会把user_name映射为userName所以字段命名保持统一风格可以减少大量配置上的麻烦。每张表都带了create_time、update_time两个审计字段配合MyBatis-Plus的自动填充注解插入和更新时可以自动写入当前时间这个特性是通过MetaObjectHandler实现的。初始化数据部分脚本里写了很多模拟数据这是设计者刻意为之目的就是让你一启动系统就能看到效果不用从头录入大量数据。比如管理员账号默认是admin/admin123演示用的老人档案有几十条覆盖了不同的年龄段和健康状态护工账号也有对应的角色账号这些数据用不同的状态和年龄分布构造出来方便演示各种功能模块。导入数据时要注意脚本执行顺序先建库再建表再插数据如果中途报错多半是因为一次性执行了全部脚本导致上下文错乱分段执行就没事了。数据库相关的还有一个容易忽略的问题是时区设置。MySQL 8.0默认使用系统时区如果你的服务器或者本地环境时区不是东八区后端的LocalDateTime字段可能会出现几小时的偏差在JDBC连接串里指定serverTimezoneAsia/Shanghai就能避免这个问题这一点在项目部署时一定要处理。4. 接口设计与接口文档规范3.1 RESTful接口风格与统一返回体设计这套系统的接口设计遵循RESTful风格接口地址就是业务资源的名称通过HTTP方法表达操作类型GET用于查询POST用于新增PUT用于更新DELETE用于删除。比如老人档案的接口GET /api/older/page是分页查询POST /api/older是新增老人档案PUT /api/older是修改档案信息DELETE /api/older/{id}是根据ID删除记录。这种接口风格的好处是语义清晰对前端开发来说也容易记忆和猜测看到接口地址基本就能猜到字段含义。所有接口的返回格式统一封装成了Result对象包含三个核心字段code表示业务状态码message描述业务处理结果data装载实际数据。约定成功时code为200失败时根据情况返回400参数错误、401未认证、403无权限、500服务器错误等信息。前端Axios响应拦截器里会对code进行统一判断code不是200的时候弹出错误提示这样前端页面里处理错误逻辑的代码量大幅减少全局只需要写一次错误处理逻辑即可。分页查询接口的设计也有讲究。列表接口统一接收pageNum和pageSize两个分页参数返回结果中除了当前页的数据列表外还携带total总条数、pages总页数等元信息。前端表格组件的分页器数据直接映射到返回结果中不用自己手动计算总页数。用户输入搜索关键词时走的也是同一个接口只是额外传了对应的查询条件参数后端根据参数构造QueryWrapper动态拼接SQLMyBatis-Plus在分页插件配合下自动完成limit拼接和总条数查询代码量非常少。3.2 接口文档整理思路与Swagger使用技巧项目附带的接口文档是除了源码之外最重要的交付物写文档这件事很多人觉得麻烦但做毕设答辩时评委老师一定会翻接口文档文档规范程度直接影响答辩印象分。这套系统的接口文档基于SwaggerSpringFox自动生成同时辅以人工整理的接口说明文档两者配合既保证接口定义准确又弥补了自动生成文档在业务语义描述上的不足。Swagger的核心用法其实不复杂。后端项目引入springfox-swagger2和springfox-swagger-ui依赖后在启动类上添加EnableSwagger2注解配置一个Docket Bean指定扫描的包路径接口文档页面就搭建起来了。Controller接口上添加Api注解描述接口的用途方法上添加ApiOperation注解描述具体业务场景参数上添加ApiParam标注参数含义。这套注解体系写起来稍微有点繁琐但对团队协作和项目交接的价值是实打实的别人接手你的项目时打开Swagger页面就知道每个接口是干什么的不需要再去翻源码猜逻辑。这里也提一下Swagger配置的一个注意点SpringBoot 2.6及以上版本默认的路径匹配策略从AntPathMatcher改成了PathPatternParserSwagger的路径解析可能会受到影响导致页面无法访问解决方案是在application.yml配置文件中加一行spring.mvc.pathmatch.matching-strategyant-path-matcher这是版本升级引发的经典兼容问题。如果用的是SpringBoot 3.x建议直接用OpenAPI 3的springdoc框架而不是继续用SpringFox因为SpringFox对SpringBoot 3的支持并不好。人工整理的那份接口文档是按模块组织的每个模块下列出接口名称、请求地址、请求方式、请求参数说明、返回数据示例。对于关键接口还会附上一个调用示例比如提交登录请求时给出请求体的JSON示例和返回的Token信息示例前端拿到文档后照着示例格式就能完成联调不用反复问后端参数类型是什么。5. 前后端联调与本地部署实战4.1 环境准备与技术版本搭配部署这套系统前建议先把本地环境准备好环境版本和项目保持一致能省掉很多不必要的兼容问题。后端部分要求JDK 1.8或者更高版本Maven 3.6以上MySQL 8.0Redis 6.xIDE推荐用IntelliJ IDEA。前端部分要求Node.js 16.x以上npm 8.x以上Vue CLI默认安装即可。这套组合是经过时间检验的搭配网上输入关键词搜索时出现的各种“狂神说SpringBoot笔记”类教程也基本都是类似的版本组合参考价值很高。一个非常关键的版本问题是SpringBoot和JDK的对应关系。SpringBoot 2.x系列运行在JDK 8或JDK 11上如果你使用的SpringBoot版本太高比如3.x那就要求JDK 17才能运行用JDK 8编译会直接报错。所以当你下载一套源码后发现无法启动第一件事就是检查JDK版本和SpringBoot版本是否匹配这个问题的出现频率在毕设项目里极高。同样的问题也会出现在前端不同版本的Vue CLI、Webpack、Node.js之间也有兼容限制Node版本太高或太低都有可能导致npm install失败。数据库这部分需要特别注意字符集。建库时执行脚本里创建数据库的语句确保字符集是utf8mb4。如果你的本地数据库默认字符集是latin1或者其他老编码之后插入中文数据时就会出现乱码这种问题排查起来很费时间。把当前数据库的默认字符集修改为utf8mb4之后再执行SQL脚本中文数据基本就不会出问题了。Redis是作为缓存和Token会话存储来使用的如果你的环境里还没有安装RedisWindows用户可以直接下载Redis-x64版本解压完事双击redis-server.exe就能启动Mac用户用brew install redis一键安装。运行项目前先确认Redis处于启动状态否则系统启动成功后一调用登录接口就会报连接异常这是本地调试时非常常见的一个问题。4.2 启动后端服务的完整流程后端的启动流程并不复杂但每个细节都要做对。第一步是配置数据库连接信息在application.yml文件里修改spring.datasource相关参数注意要把url、username、password改成你自己的本地配置。配置文件里还会读取一个redis的地址和密码配置如果你的本地Redis没设密码redis.password这个配置项留空就行。第二步是确认项目依赖已经完整下载。在IDEA中打开项目后项目会自动识别为Maven项目等待右下角进度条走完依赖就下载好了。如果之前有人对pom.xml做过改动最好是先执行一下mvn clean install命令触发一次强制依赖下载让所有依赖包落地到本地Maven库中避免运行时缺包。这个环节有一个常见问题如果某些依赖在中央仓库已经下线或者版本冲突IDE可能会报红优先看一下具体是哪些包冲突适当调整pom中相应的版本号到兼容版本。第三步是检查数据库初始数据是否正确。项目启动时会执行SpringBoot的启动流程应用不会主动创建表表结构完全依赖前面提到的SQL脚本建立。所以在启动之前就要确认数据库里已经有这些表了最简单的验证方式是用数据库客户端工具连上去看一下表列表里是否包含系统设计时的十几张表。确认无误后运行主类中的main方法看到控制台打印出Tomcat started on port(s): 8080就说明服务启动成功了。后端服务启动成功后可以先在浏览器里访问一下接口文档地址看看接口列表是否正常显示。如果Swagger页面能正常打开说明后端服务的接口映射逻辑没有问题可以进入前后端联调阶段。4.3 前端安装依赖与本地开发环境配置前端开发环境的搭建相比后端环境稍显繁琐涉及到的工具链更分散不过按步骤来就不会走偏。前端项目根目录下会看到package.json文件这个文件里定义了项目依赖的npm包列表和脚本命令。打开终端切换到项目根目录执行npm install命令这个命令会根据package.json中的依赖声明把node_modules文件夹下载完整下载时间取决于网络情况大概率需要几分钟。依赖安装过程中如果出现报错首选的解决办法是清理npm缓存删除node_modules目录然后重新安装。这类问题大多数情况下是网络波动导致的包下载不完整。如果使用的npm源速度太慢可以切换到国内镜像源比如将registry地址切换为淘宝镜像源安装速度会有明显提升。这里也提醒一下npm install和npm ci这两个命令是有区别的一个是按package.json的宽松版本范围安装一个是严格按照package-lock.json的锁定版本安装如果当前项目里有lock文件用nmp ci反而能保证依赖版本不变。前端本地调试依赖Vite或Webpack DevServer作为开发服务器。项目启动命令通常是npm run serve这个命令会先经过一次工程化编译然后启动一个本地开发服务器默认端口是8080如果都被占用就会自动顺延。这里就涉及到一个前后端联调很关键的问题前端开发环境的地址是localhost:8080而后端的服务地址是localhost:8080两个端口不一样直接请求跨域会被浏览器拦截。解决跨域问题的方案这个项目里采用的方案是在vue.config.js文件中配置devServer.proxy代理。开发环境下前端把请求统一发到本地开发服务器开发服务器通过代理转发到后端真实的服务地址。配置起来非常简单proxy属性里指定目标地址为http://localhost:8080并将路径以/api开头的请求全部代理到后端地址上。这里的核心是前端代码中的所有请求都使用相对路径/api开头这样经过代理转发时就不会出现跨域问题了。生产环境部署时再由Nginx反向代理完成同样的能力。环境配置完成后执行npm run serve浏览器自动打开前端首页尝试登录如果能正常进入系统主界面说明前后端联调的基础通道已经打通了。4.4 打包部署与上线准备本地开发调试完成之后如果要部署到服务器上给答辩评委演示或者放到云服务器上跑起来就需要执行项目的正式构建流程。后端的部署产物是一个JAR包。在项目的根目录下执行maven的package命令Maven会经历编译、测试、打包等一系列生命周期最终在target目录下生成一个可执行的JAR文件。部署时在服务器上执行java -jar 包名.jar命令即可启动应用。如果服务器内存紧张可以给JVM指定启动内存参数比如java -Xms256m -Xmx512m -jar 包名.jar避免默认内存分配过大导致服务器OOM。前端的部署产物是一堆静态文件。执行npm run buildVue会把项目中的所有源码编译压缩生成dist目录里面包含index.html、JavaScript、CSS、图片等静态资源。把dist目录上传到服务器后可以用Nginx来托管这些文件并配置将所有API请求反向代理到后端的JAR服务端口上。这里有一个经典问题Vue Router默认采用History模式时用户直接访问某个子路由路径或者刷新页面时会出现404解决办法是在Nginx配置中添加try_files $uri $uri/ /index.html让请求最终落回前端入口文件。前端打包后布局异常的问题也值得提一下。本地开发时看起来一切正常但npm run build之后的产物体积更小路径更深如果组件里的CSS没有做样式隔离或者使用了绝对定位依赖了外部元素打包后浏览器渲染出来就容易错位。解决思路是检查全局样式和组件样式的作用域尽量减少对全局样式的依赖。另外也注意不要在CSS里使用会被PostCSS处理阉割的代码比如某些旧式写法在压缩后行为会变异这种情况通过浏览器开发者工具排查起来确实费时间但排查思路就是对比本地和打包后的元素样式差异。Jenkins自动部署这套流程如果上手了这一个单体项目的部署想在服务器上实现一键部署也可以借助Jenkins的简单流水线完成自动化。流程就是Jenkins监听代码仓库的push事件自动拉取后端代码执行Maven打包再把JAR包用脚本传到服务器上重启服务前端代码同理拉取后执行npm run build然后同步到Nginx的静态文件目录。这个能力虽然不是毕设必须但写进简历的加分效果非常明显正式工作中也会频繁用到。6. 常见问题排查与避坑指南5.1 前后端联调阶段的网络与跨域问题联调过程中遇到的第一类高频问题就是网络层面的。前端页面点击登录按钮后一片空白或者控制台报出“Failed to fetch”或“Network Error”百分之八十是代理配置或者后端地址不对。先用浏览器开发者工具的Network面板看一下请求到底是发到了哪个URL、返回了什么状态码如果状态码是404说明代理转发目标地址有问题后端Controller里的RequestMapping路径和前端请求路径不匹配如果状态码是403或401先查看是否未带Token或者Token过期如果请求地址是http://localhost:8080开头的原地址并且没有代理成功那就是devServer的proxy配置没有生效需要重启前端开发服务器。CORS跨域和后端配置也有关联。如果前端不用代理开发而是直接用完整地址请求后端后端就必须在配置里放开跨域限制可以用CrossOrigin注解标注在Controller上也可以实现WebMvcConfigurer的addCorsMappings方法做全局配置放行指定的来源、请求头和请求方法。加了跨域配置也不是万事大吉如果请求里带了自定义Header还需要额外放行allowedHeaders否则预检OPTIONS请求同样会失败。理解这一点就理解了跨域的本质可以节省很多调试时间。5.2 SpringBoot与Vue的版本兼容陷阱如果下载的这套项目和本地环境版本差距比较大最容易踩的坑就是版本兼容问题。后端方面SpringBoot版本的高低决定了JDK的最低版本要求SpringBoot 2.0以上需要JDK 8SpringBoot 3.0以上需要JDK 17。如果你的依赖版本是2.7.x建议直接用JDK 8或者11如果是3.xJDK 17是起步要求也就意味着IDEA版本和Maven版本也要相应升级否则编译环节就会报错。还有SpringBoot与MyBatis-Plus之间的配合也和版本有关引入最新版MyBatis-Plus的spring-boot3-starter时包名和依赖方式都和旧版本有区别引错依赖大概率启动失败。前端方面Vue CLI 4.x和5.x的版本要求差异也很明显。Vue CLI 5.0要求Node.js版本在12以上部分老项目用的Vue CLI 4.0搭配Node 10也能跑但如果Node版本过新一些老依赖在安装时就会出现兼容问题。另外这两天比较常见的Vue 3生态下的坑是Vite构建版本对Node的版本约束Vite 4以上要求Node 14.18或16以上版本低了直接报错版本高了又可能和旧依赖冲突控制好Node版本是前端环境搭建阶段的核心任务。5.3 数据库操作中的细节陷阱与排查思路数据库这一层的问题通常比较隐蔽。比如执行SQL脚本的时候建表成功但是初始化数据插不进去检查一下是不是开启了严格模式某些字段的非空约束或者默认值设置不符合预期也有可能是字符集造成的长度溢出。数据插入报错后先读一下错误信息的后半段Error Code和SQLState会是定位问题的最大线索。时间字段显示错误也是一个小高频。页面里看到的时间比实际时间少了8个小时这是MySQL时间存储的时区和Java本地时区不一致导致的也有可能是Jackson在序列化LocalDateTime时没有配置正确的格式化规则。项目里比较推荐的方案是统一将Jackson配置为返回yyyy-MM-dd HH:mm:ss字符串格式同时确认数据库连接串中的serverTimezoneAsia/Shanghai配置没有遗漏。这样前后端展示的时间就不会出现偏差。在这个环节上出的部署问题不在少数。日志表数据量增长过快的情况也有必要注意。运行了一段时间后系统可能变卡查一下日志表的数据量如果单表到了几百万行数据库整体性能都会下降在演示前清理一下日志表是常规操作。这也侧面说明了一个设计上的考量日志表可以考虑按月分表或者定期归档这个设计在项目进阶时可以作为优化点提出来。5.4 安全与权限配置的注意点这个系统包含了老人健康信息属于个人信息保护范围内所以项目里做了几层基本的保护措施。密码不能明文存储采用了MD5加盐的方式进行哈希后入库虽然MD5不是最强的加密方式但在毕设场景已经足够说明设计者有这样的安全意识答辩的时候也可以主动提一句后续可以升级为BCrypt。在实际项目里更推荐直接用BCrypt替代MD5这也是现成依赖库里就有工具类的原因。接口层面的防刷和校验项目里对登录接口做了简单的访问频率限制基于Redis的计数器模式实现。但是正式开发的系统除了这个限制以外常规的防SQL注入防线主要依靠MyBatis-Plus的预编译机制使用#{}占位符而不是${}拼接SQL前者是预编译方式可以放心防止SQL注入的发生项目里需要注意不要为了写动态SQL方便而滥用${}。角色权限方面系统是严格按照RBAC模型实现的管理员和护工虽然都能看到老人列表但护工的页面会隐藏一些敏感操作按钮后端接口也加了对应的角色拦截逻辑。前端隐藏按钮并不能真正防止接口被直接调用后端权限校验一定要做前后端权限校验双管齐下这个安全层次感在答辩时很加分。7. 这份源码之外的延伸建议作为一个完整的毕设项目这套系统从结构、功能、文档三个维度都做得挺齐全了。我在过代码的过程中发现遇到一个实战项目不用急着立刻去跑起来建议先围绕源码读一遍数据表结构再打开接口文档对照着看接口最后再动手启动项目。先理解、再操作这样的学习效果远好于一上来就盲目启动然后遇到问题手忙脚乱。最后再分享一个小技巧。如果你拿这套项目作为基础在答辩或作品集中想体现一些进阶能力有几个可以落地的改进方向一是把文件上传模块接上云存储服务用来上传老人证件的图片这样系统就具备了对象存储的实战经验二是用WebSocket实现健康数据的实时推送让大屏页面上的体征数据不用刷新就自动更新三是给系统加入基于AOP的接口访问日志把每次接口调用的耗时记录下来将来做慢接口分析时能直接用上这些数据。真正提升项目含金量的往往是这些看起来不起眼的系统化设计。养老公寓管理系统这类业务系统复杂度不在于算法而在于对业务流程的理解是否深入、数据模型是否合理、异常情况是否考虑周全。自己动手把这份源码吃透修改几个功能模块再加上一两个自己的设计亮点拿一个优秀的毕设成绩是大概率事件。希望这份源码和文档对你的毕设之路有实打实的帮助。