企业官网建设流程全解析

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后端的事实标准，核心优势在于"约定大于配置"。传统的SSH（Spring + 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-web（Web基础）、mybatis-plus-boot-starter（MyBatis-Plus）、mysql-connector-java（MySQL驱动）、lombok（减少样板代码）、jjwt（JWT工具）、spring-boot-starter-validation（参数校验）、hutool-all（工具类集合，强烈推荐，处理字符串、日期、文件非常方便）。

统一响应体是接口设计的第一步。我习惯定义Result<T>泛型类，包含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 vue@latest初始化工程，选择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_files，history模式下刷新404会直接让人怀疑人生。所以再次强调，毕设项目全部采用hash模式，省心。

6.6 微信小程序页面生命周期与数据刷新问题

小程序页面在每次显示时，onShow钩子都会触发，但onLoad只在首次进入页面时触发一次。很多人在onLoad中加载列表数据后，从详情页返回列表页时发现数据没有刷新（比如订单状态变了），就很困惑。解决办法是把数据请求写在onShow中，或者提供下拉刷新onPullDownRefresh。同时，页面栈中的数据传递用eventChannel或全局状态来管理。这个小细节不留意，演示时就会出现"订单已完成但是列表还显示待服务"这种尴尬情况。

6.7 MySQL时区问题与数据展示偏差

后端存储的时间在数据库中显示正常，但前端查询出来就少了8小时，或者反过来。这是经典的时区问题。解决方法是：MySQL连接URL中加上serverTimezone=Asia/Shanghai，确保JDBC驱动和数据库使用同一个时区。同时SpringBoot中spring.jackson.time-zone=GMT+8也要配置。还有一个小建议：所有时间字段用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 2>&1 &方式后台运行，然后用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拉开质的差距。不过，如果你的毕设不需要这些功能，不必硬加，把现有功能做到稳定、文档写清楚、答辩讲明白，就已经能达到优秀论文的水平。

我带过不少学生的毕设，一个很深的体会是：技术这个环节反而不容易拉开差距，真正拉开差距的是"能不能把系统讲成一个完整的故事"。从业务需求到技术选型，从表结构设计到状态流转，从功能实现到部署演示，每个环节都能回答清楚"为什么这么做"，这才是毕设拿高分的关键。希望这篇拆解能帮你把这条链路打通，做一个真正能拿得出手、讲得清楚的居家养老小程序系统。