1. 项目概述与选题背景每年到了毕业设计季我都会收到大量类似的咨询学长SpringBoot Vue 小程序这个组合到底怎么搭、居家养老服务系统该做哪些功能才能过答辩。说实话这个选题方向在近三年内一直是计算机毕业设计里的热门选项原因很简单技术栈主流、业务场景清晰、功能可繁可简、演示效果好。如果你正在为毕设选题发愁或者已经选了基于SpringBoot Vue的居家养老服务小程序这个题目但还不知道从哪里下手这篇文章就是写给你的。先说清楚这个项目到底是什么。居家养老服务小程序系统从业务上看解决的是社区养老场景下老人—家属—服务人员—管理机构四端之间的信息不对称问题。传统的居家养老模式里老人需要助餐、助洁、助医等服务时往往要打电话、托熟人、甚至跑社区服务站服务过程不透明、服务评价无记录、紧急情况无法及时响应。这套系统要做的就是把整个服务闭环搬到线上老人在小程序端浏览服务项目、下单预约、查看服务进度、提交评价服务人员护理员、社工接收工单、上门服务、填写服务记录家属绑定老人账号后可以远程查看服务情况和健康数据管理员通过Vue后台管理系统维护服务项目、审核工单、管理用户、统计分析数据。从技术角度看这套系统的核心价值在于打通了三个端SpringBoot后端负责业务逻辑与数据存储Vue管理后台给运营人员使用微信小程序面向老人和家属。三个端通过RESTful API通信数据库采用MySQL权限控制用JWT文件存储可以接本地目录或MinIO。整套技术栈都是目前企业里真实在用的组合不是那种为了应付答辩堆砌出来的伪需求。这个项目适合谁来参考如果你是计算机科学与技术、软件工程、大数据等专业的本科生正需要一套结构清晰、可二次开发的毕设源码这套系统的架构设计可以作为很好的基座。如果你想往Java后端或全栈方向求职把这份代码吃透、能讲清楚每个接口为什么这么设计面试时也是实打实的项目经验。甚至如果你是社区服务机构的IT负责人想快速搭一个养老服务信息化平台的雏形这套系统的功能划分也值得借鉴。2. 核心技术栈选型与架构设计2.1 为什么是SpringBoot Vue 小程序这个组合先聊聊技术选型的逻辑。很多人选型是跟风看到网上毕设源码都是这个组合就跟着用但真要问你为什么用SpringBoot不用SSH为什么前端用Vue不用React小程序为什么要单独做而不是套个Web页面就答不上来了。答辩时老师最爱问的就是这类问题所以我先把选型逻辑拆清楚。SpringBoot之所以成为Java后端的事实标准核心优势在于约定大于配置。传统的SSHSpring Struts Hibernate时代光配置文件就要写好几页光一个Spring容器加载XML配置就能把人绕晕。SpringBoot把自动配置、内嵌Tomcat、起步依赖这些东西做好了一个main方法就能启动整个Web服务。对于毕设项目来说这意味着你可以把更多精力放在业务代码上而不是纠结配置文件怎么写。Vue在国内中小型前端项目中的统治力就更不用说了。它的响应式数据绑定、组件化开发、Vue Router路由管理、Vuex/Pinia状态管理加上Element UI这类成熟组件库一个人在一到两周内搭出一个像样的管理后台完全不困难。尤其是Vue 3 Vite Element Plus这套新组合开发体验比Vue 2 Webpack时代舒服得多启动速度快、热更新及时、构建产物小。我在后面给出的方案里会详细说这套环境的搭建细节。小程序端的选型有一个关键决策点用原生小程序还是用uni-app跨端框架。我的建议是如果你只面向微信一个平台直接用原生小程序开发官方文档完善、调试工具好用、没有中间层的性能损耗。但如果你希望未来能扩展到支付宝小程序、抖音小程序甚至App端uni-app是更好的选择。咱们这篇以原生小程序为主因为大部分毕设只要求微信小程序能跑就行没必要引入更多复杂度。2.2 居家养老业务的角色模型与权限体系业务系统的设计一定要先理清角色角色理清了功能菜单、接口权限、数据隔离规则都跟着清晰了。居家养老服务系统里我建议按四种角色来建模老人服务对象注册登录后可以浏览服务项目、提交预约订单、查看服务进度、确认完成、评价服务、发起紧急求助。家属关爱者可以绑定老人账号查看老人的服务记录、健康数据、工单状态。家属本身不直接下单通常代老人操作。服务人员护理员/社工接收系统派发的工单、查看服务计划、上门服务后填写服务记录、更新老人健康数据。管理员运营人员维护服务项目、管理用户、审核工单、派单、处理投诉、查看统计报表。这四种角色的权限差异必须在后端接口层面做控制不能只在前端隐藏菜单。安全这块是答辩时的高频考点。我的做法是登录成功后签发JWT令牌令牌里包含userId和role字段后端通过拦截器解析令牌、校验角色再配合Spring AOP做细粒度的权限注解校验。比如PreAuthorize(hasRole(ADMIN))标注的接口就只有管理员能访问老人通过小程序调用下单接口时服务端还要校验当前登录用户的角色确实是老人或家属防止越权操作。2.3 前后端分离架构下的模块划分架构上我采用标准的前后端分离设计但考虑到毕设项目的规模和部署便利性最终产物是一个可执行jar包 一个小程序前端项目的结构。具体来说后端SpringBoot工程按照业务域拆包不是按层拆包。这里说一个很多毕设源码常见的坏习惯项目结构用controller、service、mapper这种按技术层分包结果几十个controller堆在一起找都找不到。更好的做法是按业务模块分包比如elder老人管理、order服务订单、worker服务人员、system系统管理等每个模块下面再放controller、service、mapper等。这样代码结构清晰答辩时展示起来也有条理得多。前端Vue管理后台单独一个工程开发时通过Vite代理解决跨域问题生产环境构建后把dist目录下的静态文件复制到SpringBoot的src/main/resources/static目录下这样最终只需要启动一个SpringBoot应用就能同时提供API接口和后台管理页面。小程序端是另一个独立工程通过request封装的网络请求模块访问后端API。具体的部署细节我放在后面的章节里详细展开。3. 数据库设计与核心表结构3.1 核心实体关系梳理数据库设计是这套系统的地基表结构设计得好不好直接影响开发效率和答辩质量。先梳理核心实体用户老人、家属、服务人员、管理员、服务项目、服务订单、工单、服务记录、评价、健康数据、紧急求助、公告、系统菜单。这里要重点说两个设计决策。第一个决策用户体系怎么设计很多新手会把老人、家属、服务人员、管理员分别建四张表字段各写各的结果登录时还得判断你到底该查哪张表非常痛苦。我的做法是建一张统一的user表里面放username、password、realName、phone、avatar、role等公共字段角色不同的人在user表里通过role字段区分同时针对角色的个性化信息再建扩展表。比如老人的详细健康档案放到elder_profile表服务人员的工作信息放到worker_profile表。家属和老人之间的绑定关系单独用一张elder_family_bind表来记录。这种设计的好处是登录认证只需要查一张表角色扩展信息通过关联查询获取逻辑清晰、扩展性好。第二个决策订单和工单的关系。老人下单后生成服务订单管理员审核通过后派单给服务人员服务人员接单后产生工单工单执行结束后填写服务记录。我建议把订单表service_order和工单表work_order分开设计订单记录的是用户想要什么服务工单记录的是谁来完成这个服务。两者通过订单号关联。为什么这么设计因为一个订单可能有多次服务频次比如助洁服务每周一次持续四周那就是一个订单对应四个工单。订单表记录订单的基本信息和总状态工单表记录每次执行的明细状态这样后续做统计报表时分表查询非常方便。3.2 核心表关键字段详解把最重要的三张表拿出来细讲。第一张是service_order服务订单表核心字段包括order_no订单号唯一建议用日期随机数生成方便排查问题、elder_id老人ID、family_id下单家属ID、service_item_id服务项目ID、worker_id服务人员ID初始为空派单后写入、appointment_time预约时间、address服务地址、status订单状态、amount订单金额、remark备注、create_time等。订单状态这个字段是核心业务逻辑的载体我采用了整数枚举0待审核、1已审核待派单、2已派单待服务、3服务中、4待确认完成、5已完成、6已取消、7已退款。第二张是work_order工单表和订单表1对N关联。关键字段有work_no、service_order_id、worker_id、start_time、end_time、service_content服务内容记录、images服务过程照片JSON数组字符串、feedback服务反馈、status。工单状态机和订单状态机是有联动的比如工单标记完成后订单要联动更新状态。第三张是elder_health_record老人健康数据表。字段包括elder_id、record_date、blood_pressure_high收缩压、blood_pressure_low舒张压、heart_rate心率、blood_sugar血糖、weight体重、create_worker_id测量人服务人员、remark。健康数据在居家养老场景里非常关键家属关心、医生需要、服务人员在服务过程中也要记录。后续做数据可视化分析时这些数据字段就是图表的数据源。3.3 数据库创建与初始数据准备表结构设计好了之后我建议直接用Navicat、DataGrip或者mysql命令行执行建表脚本创建好后导入初始数据。初始数据要准备哪几类一是管理员账号比如admin/admin123密码用MD5加盐或者BCrypt加密存储千万不要明文存储这是安全意识的体现二是服务项目数据助餐服务、助洁服务、助浴服务、助医服务、陪诊服务、康复护理、精神慰藉、紧急救助等每个服务项目包含名称、图标、价格、说明、时长等信息三是一些演示用的老人、家属、服务人员账号方便演示功能时切换角色操作。有一点要提醒数据库脚本文件一定要在交付文档里附上并且写出完整的建表和插入语句标明MySQL版本为5.7或8.0。答辩演示时老师可能让你现场还原环境一个能一键执行成功的SQL脚本可以帮你省下大量时间。另外在自己电脑上调试时建议把数据库连接信息放在application.yml里用不同profile区分开发环境和生产环境比如application-dev.yml连接本地库application-prod.yml连接服务器库切换环境时只需要改一个spring.profiles.active配置。4. SpringBoot后端核心实现4.1 后端工程搭建与统一响应体后端工程搭建时推荐去Spring Initializr生成基础项目选Spring Boot 2.7.x版本。为什么不选3.x因为3.x基于JDK17要求Jakarta EE规范很多老教程和新依赖版本还没跟上对毕设而言没必要冒这个险。SpringBoot 2.7.x搭配JDK1.8是一套经历了大量生产检验的稳定组合社区资料多出了问题也容易搜到答案。相关依赖需要引入spring-boot-starter-webWeb基础、mybatis-plus-boot-starterMyBatis-Plus、mysql-connector-javaMySQL驱动、lombok减少样板代码、jjwtJWT工具、spring-boot-starter-validation参数校验、hutool-all工具类集合强烈推荐处理字符串、日期、文件非常方便。统一响应体是接口设计的第一步。我习惯定义ResultT泛型类包含code、msg、data三个字段。code为200表示成功500表示失败401表示未认证403表示无权限。所有Controller的返回值都包装成Result对象配合全局异常处理器RestControllerAdvice统一捕获异常保证出错了返回的也是约定格式的JSON。这个设计看起来很简单但能让前后端联调时少扯很多皮也是答辩时展示项目规范性的一个亮点。4.2 登录鉴权与JWT身份验证登录流程是这样的用户输入账号密码后端校验用户名是否存在、密码是否正确BCrypt加密比对校验通过后生成JWT令牌返回给前端。JWT的载荷里放userId和role签名密钥配置在application.yml里。前端拿到token后存储在本地每次请求在Header中携带Authorization: Bearer token。后端通过自定义拦截器解析token。拦截器要做两件事一是放行登录、注册、获取服务项目列表等公开接口二是对非公开接口校验token是否存在且有效无效则返回401。这里要特别注意一个SpringBoot的坑拦截器拦截的是Controller层的请求但对于静态资源也要配置放行路径否则前端部署到SpringBoot后访问静态资源页面会被拦住。另外一个坑是跨域问题开发环境下前端跑在8080端口的小程序/管理后台后端跑在8081端口浏览器会拦截跨域请求。解决方法是配置CorsFilter设置允许的域名和请求头这个配置在我的项目里是必须提前写好的。4.3 服务订单与工单流转核心逻辑服务订单的状态流转是这套系统的核心业务后端代码必须把状态机逻辑写好。老人下单后订单状态为0待审核管理员审核通过后状态变为1待派单同时可以选择服务人员进行派单派单后状态变为2待服务服务人员上门扫码或点击开始服务状态变为3服务中服务完成后状态变为4待确认完成老人或家属确认完成状态变为5已完成其中任意环节都可以发起取消或退款流程。这里有几个细节要提醒。第一订单状态流转必须用update ... where status ?这种乐观锁方式防止并发操作导致状态错乱。比如两个请求同时想将订单从待审核改为已审核使用条件更新可以保证只有一个请求成功。第二订单状态变化要记录日志我在项目中加了一张order_log表记录每次状态变更的操作人、操作时间、变更前后的状态答辩时展示这个设计能加分不少。第三派单后要发送通知给服务人员毕设阶段可以简化处理在工单表里记录通知状态或者集成微信订阅消息如果不想引入太多复杂度写一个简单的站内信通知就够用了。4.4 文件上传与内容存储方案系统里有几个地方需要处理文件上传服务项目图片、服务记录照片、用户头像。毕设阶段最简单的方案是把文件保存到本地磁盘目录然后通过一个映射虚拟路径的配置对外提供访问。这里有一个很实用的技巧SpringBoot可以通过WebMvcConfigurer的addResourceHandlers方法将本地磁盘目录映射为URL路径。比如你在配置文件中设置file.upload-path/data/upload/然后代码里写registry.addResourceHandler(/upload/**).addResourceLocations(file: uploadPath)前端就可以通过http://localhost:8080/upload/xxx.jpg直接访问上传的图片了。如果你想让项目看起来更上档次可以集成MinIO对象存储服务。MinIO兼容Amazon S3协议可以自己搭建私有化对象存储服务。在application.yml中配置MinIO的endpoint、accessKey、secretKey再用Java SDK封装一个上传工具类把文件流上传到MinIO的bucket中返回访问URL。这个方案在企业项目中非常常见答辩时讲出来老师会觉得你有真实项目经验。热词里也提到了MinIO加入到SpringBoot可见这是很多人关注的点我补充一下MinIO配合SpringBoot的坑主要在于JDK版本和SDK版本兼容问题用2.7.x的SpringBoot配MinIO 8.x SDK时注意把okhttp版本升级到4.x以上否则会报NoSuchMethodError。5. Vue管理后台与小程序端实现5.1 Vue 3 Element Plus管理后台搭建管理后台我推荐直接用由vue3 vite element-plus pinia vue-router axios组成的一套模板。基础工程可以手动搭建也可以直接参考一些开源后台模板比如vue-element-plus-admin来做二次开发但毕设建议还是自己动手搭一遍把每个环节弄清楚。搭建流程说几个关键点。使用npm create vuelatest初始化工程选择Router、Pinia、ESLint选项。安装依赖后配置Vite的server.proxy代理开发环境中将/api前缀的请求代理到后端的http://localhost:8080这样避免跨域问题。Axios实例需要统一封装拦截器里自动从Pinia或localStorage中获取token添加到请求头响应拦截器里统一处理HTTP错误、业务错误码、token过期跳转登录页。管理后台的页面规划为登录页、系统首页Dashboard、老人管理页面列表/详情/编辑、服务项目管理页面增删改查、上下架、订单管理页面审核、派单、状态跟踪、工单管理页面查看、分配、用户管理页面家属、服务人员、评价管理页面、健康数据统计页面、公告管理页面。每个页面都是标准的表格表单弹窗分页组件组合Element Plus的el-table、el-dialog、el-form三个组件能解决80%的后台管理需求。5.2 小程序端页面结构与交互设计小程序端是面向老人和家属的核心入口页面结构设计要贴近真实使用场景。我的建议是底部TabBar四个入口首页服务推荐、公告、紧急救助入口、服务全部服务项目列表支持分类筛选、订单订单列表按状态Tab切换、我的个人信息、健康数据、家属绑定、地址管理、绑定账号。首页的布局参考常见的小程序商城风格顶部搜索栏中部轮播图下方是金刚区快捷入口图标再往下是服务项目推荐列表。服务列表页要注意分页加载的问题热词里提到微信小程序页面列表加载更多这是一个高频考点。具体实现是onReachBottom页面生命周期钩子在滚动到底部时触发如果没有到达最大页数就请求下一页数据并追加到列表尾部同时在页面底部显示已加载全部的提示。为了避免重复请求还要加一个isLoading锁防止滚动事件连续触发多次请求。订单列表页面采用状态Tab切换设计为全部/待审核/待服务/服务中/已完成/已取消几个维度。每个订单卡片展示服务项目名称、预约时间、服务人员姓名、订单状态。点击订单卡片跳转订单详情页详情页展示完整的订单信息、工单执行状态、服务记录、评价入口等。5.3 小程序请求封装与登录态管理小程序端和后端的接口通信需要统一封装。在小程序项目的utils目录下建一个request.js文件封装wx.request方法。封装内容包括baseURL配置开发环境可以用http://localhost:8080/api但真机调试时localhost指向的是手机本身需要改成电脑的局域网IP这是一个特别容易踩的坑调试时直接用微信开发者工具的不校验合法域名选项跳过域名校验请求拦截器自动从wx.getStorageSync(token)中获取token并放入Header响应拦截器统一判断业务状态码code为401时跳转登录页code为500时弹出错误提示Toast。登录态管理方面微信小程序推荐使用wx.login获取code然后传给后端后端调用微信接口换取openid再创建一个用户或绑定已有用户签发自定义token返回给小程序。但考虑到毕设项目需要简化演示很多源码直接使用手机号验证码或账号密码登录省去了微信开放平台的复杂配置。我的建议是做一个兼容方案首次进入引导用户通过手机号登录后端记录openid到user表中老用户登录时直接用账号密码或手机号验证码。这样既能贴合真实业务又不用依赖微信支付的资质要求。5.4 Vue打包部署与路由模式选择管理后台开发完后需要打包部署。这里要重点说两个问题。第一个问题是Vue Router的模式选择。默认是hash模式URL里带个#/不需要服务器额外配置部署简单。而history模式URL更美观但刷新页面时服务器需要做回退配置否则会出现404。因为我们的部署目标是SpringBoot的静态资源目录我建议直接用hash模式省心可靠。如果你非要用history模式需要在SpringBoot里加一个ErrorPage配置把所有的非API请求转发到index.html但这个配置和应用本身的404异常处理有冲突处理起来比较麻烦。所以省事优先使用hash模式。第二个问题是构建输出目录。Vue项目vite.config.js里设置build.outDir为../src/main/resources/static也就是让打包产物直接输出到SpringBoot的静态资源目录下。构建完成后把SpringBoot项目打成jar包运行java -jar即可同时提供后台管理页面和API服务。小程序端不需要打包直接在微信开发者工具中上传代码到测试版即可。实际开发中我建议的流程是日常开发时后端跑8080端口、前端管理后台跑8081端口通过Vite代理联调临近答辩时再做一次完整构建把前端产物合并到SpringBoot包里用一份jar单独跑全套系统演示给老师看。6. 常见问题与避坑实录6.1 小程序真机调式连不上后端这是最高频的问题。前端同学在微信开发者工具里预览一切正常但一扫码真机预览就发现所有接口都请求失败。原因很简单小程序的JS代码运行在手机上网络请求的目标地址http://localhost:8080指向的是手机自己的回环地址而不是你的开发电脑。解决方案是把baseURL改成电脑在局域网中的IP比如http://192.168.1.100:8080/api。同时需要在微信公众平台配置request合法域名。还有一个隐蔽的坑电脑防火墙可能会拦截手机的访问请求Windows系统下记得在防火墙放行8080端口我用Linux服务器部署时也要确认安全组策略放行了对应端口。6.2 JWT过期与刷新策略毕设阶段很多同学只做了token过期返回401的功能结果用户操作到一半被强制登出体验很差。更合理的方案是token设置较短有效期比如2小时同时签一个刷新令牌refresh_token有效期7天当请求返回401时前端自动携带refresh_token请求新的token无感刷新不需要用户重新登录。这个逻辑在Axios响应拦截器里实现比较合适判断401后发起一次refresh请求成功后重放原请求。代码量不大但讲解起来很加分面试和答辩都能用上。6.3 SpringBoot版本过高导致的兼容性坑热词里专门提到springboot版本太高这个坑确实恶心。我之前用SpringBoot 3.2做过一个项目结果MyBatis-Plus的旧版本和它不兼容MapperScan直接报错javax.servlet相关的工具类也全需要改成jakarta.servlet。解决方案就是老老实实用SpringBoot 2.7.x除非你确实需要3.x的特定功能。如果你已经想用JDK17了也要确保所有依赖都有适配版本mybatis-plus要用3.5.3.2以上javax.servlet-api要改成jakarta.servlet-api。另外Druid连接池版本过低也可能在SpringBoot 3.x上静默失效导致数据库连接不上。6.4 数据库连接池溢出问题项目长时间运行后出现Connection is not available, request timed out错误就是连接池满了。常见原因有两个一是代码中忘记关闭连接使用MyBatis-Plus时虽然会自动管理连接但如果手动获取了SqlSession没有关闭就会泄漏二是高并发场景下连接池配置太小。建议在application.yml中对Druid或HikariCP配置合理的最大连接数、最小空闲连接数、连接超时时间。排查方法是打开Druid的监控页面查看活跃连接数或者开启HikariCP的日志输出。毕设答辩时能主动讲出这个监控经验会让老师觉得你真的上过生产环境。6.5 Vue打包后路由刷新404视觉表现就是部署后点击页面正常一刷新就白屏或者404。前面已经说了用hash模式可以规避这里再补充一个细节即使使用hash模式也要注意Nginx或SpringBoot对index.html的MIME类型配置。SpringBoot默认配置一般没问题但如果你用Nginx部署且没有配置try_fileshistory模式下刷新404会直接让人怀疑人生。所以再次强调毕设项目全部采用hash模式省心。6.6 微信小程序页面生命周期与数据刷新问题小程序页面在每次显示时onShow钩子都会触发但onLoad只在首次进入页面时触发一次。很多人在onLoad中加载列表数据后从详情页返回列表页时发现数据没有刷新比如订单状态变了就很困惑。解决办法是把数据请求写在onShow中或者提供下拉刷新onPullDownRefresh。同时页面栈中的数据传递用eventChannel或全局状态来管理。这个小细节不留意演示时就会出现订单已完成但是列表还显示待服务这种尴尬情况。6.7 MySQL时区问题与数据展示偏差后端存储的时间在数据库中显示正常但前端查询出来就少了8小时或者反过来。这是经典的时区问题。解决方法是MySQL连接URL中加上serverTimezoneAsia/Shanghai确保JDBC驱动和数据库使用同一个时区。同时SpringBoot中spring.jackson.time-zoneGMT8也要配置。还有一个小建议所有时间字段用datetime类型存储Java实体类中统一用LocalDateTime接收后端返回给前端时用统一的日期格式比如yyyy-MM-dd HH:mm:ss避免前端轮子每次都不一样。7. 部署上线与交付文档编写7.1 本地环境搭建快速指南如果要快速把整套系统跑起来按照这条链路走先装MySQL 5.7或8.0导入我们准备好的db_elder_care.sql数据库脚本再装JDK1.8或JDK11修改application.yml里的数据库账号密码然后执行mvn spring-boot:run启动后端服务前端Vue工程执行npm install再执行npm run dev浏览器访问http://localhost:8081进入管理后台小程序端用微信开发者工具打开小程序目录修改request.js里的baseURL指向本地后端服务点击预览就能在模拟器中看到效果。部署到服务器上时我使用的是一台Linux服务器Ubuntu或CentOS安装JDK、MySQL把后端打成jar包用nohup java -jar xxx.jar log.log 21 方式后台运行然后用Nginx反向代理到域名。如果你没有云服务器用一台本地电脑Windows上安装VMware虚拟机跑Linux也能完成演示环境的搭建。7.2 核心文档的编写重点毕设交付通常需要开题报告、任务书、毕业论文、答辩PPT。我特别想强调毕业论文的编写顺序不要按论文模板顺序写而应该先写系统设计架构图、数据库ER图、核心接口设计再写系统实现核心代码展示和截图最后回头写绪论和文献综述。文献综述里可以引用一些社区居家养老信息化方向的研究论文比如智慧养老平台、时间银行互助养老模式等主题这些研究方向能体现你做的系统不仅是工程实现还有理论支撑。截图要重点截取小程序端的核心页面、后台管理系统页面、数据库表结构、核心代码段四类内容张张都有注释说明。文档目录里除了源码外一定还要包含readme.md运行说明包括环境要求、启动步骤、初始账号、sql文件建表与初始数据脚本、postman接口测试集合导出后在Postman中可以直接导入测试所有接口。这些细节是企业开发者的习惯也是老师判断你是不是真正做过项目的重要依据。7.3 答辩演示预案与加分亮点答辩演示最怕中途出问题。我的经验是准备两套方案一套是基于本机环境的完整演示另一套是录屏视频兜底。演示前做一遍删库重建——把数据库删掉重新导入从冷启动开始走一遍全流程确保所有环节在5分钟内能跑通。演示重点放在老人下单→管理员审核派单→服务人员接单→填写服务记录→老人确认评价这五个环节一气呵成让老师看到完整的业务闭环。除了顺畅的业务演示还有几个平时容易被忽略但能在答辩时加分的点项目的Git提交记录体现编码习惯和迭代思路、单元测试代码哪怕只覆盖了几个核心Service方法、代码注释质量关键业务方法必须注释完整、以及后端接口文档如果有Swagger注解就更好了。这些工程素养层面的东西往往比功能本身更能打动答辩评委。8. 项目的二次扩展方向毕设交完不是终点这套系统的架构天然预留了几个很好的扩展点。第一个扩展方向是智能监测硬件接入。居家养老场景最终要连接智能手环、血压计、SOS一键呼叫设备等IoT终端。可以在后端引入EMQ X或RabbitMQ做物联网消息接入在老人档案中维护设备ID健康数据表增加设备维度。热血一点说从软件系统升级成软硬一体解决方案这个转型对求职或者创业都有实际价值。第二个扩展方向是大数据分析可视化。目前系统已经积累了大量订单数据和健康数据完全可以引入ECharts做大屏展示服务量趋势、区域服务分布、老人健康风险分级等再配合SpringBoot定时任务Scheduled每天汇总前一天的数据到统计表后台管理系统首页变成动态驾驶舱演示效果会非常震撼。SpringBoot整合Quartz定时任务也是面试常问点一举两得。第三个扩展方向是多端适配与商业模式落地。小程序基于uni-app重构后可以轻松发布到支付宝小程序等平台管理后台可以增加商户端角色实现服务商入驻模式订单增加支付流程后即可对接微信支付。有了真实支付闭环系统的实用价值就和demo拉开质的差距。不过如果你的毕设不需要这些功能不必硬加把现有功能做到稳定、文档写清楚、答辩讲明白就已经能达到优秀论文的水平。我带过不少学生的毕设一个很深的体会是技术这个环节反而不容易拉开差距真正拉开差距的是能不能把系统讲成一个完整的故事。从业务需求到技术选型从表结构设计到状态流转从功能实现到部署演示每个环节都能回答清楚为什么这么做这才是毕设拿高分的关键。希望这篇拆解能帮你把这条链路打通做一个真正能拿得出手、讲得清楚的居家养老小程序系统。