Spring Boot+Vue全栈实战：一站式老年服务平台部署与业务闭环

简介：这是一套基于SpringBoot+Vue的老年一站式服务平台毕业设计项目，适合Java方向毕业生、课程设计或期末大作业使用。项目包含完整的前后端代码与数据库脚本，覆盖用户端与后台管理端，界面简洁、操作路径清晰，并配有详细代码注释与部署说明，即使新手也能按步骤在IDEA中完成配置并运行。

压缩包共911个文件，约16.4MB，主要包含163个Java后台源码、57个Vue组件、164个JavaScript脚本、60个HTML页面、53个CSS样式，以及SQL数据库脚本和Maven/Tomcat等配置文件，结构完整，便于按模块查看与二次开发。数据库建议使用MySQL 5.7，开发环境为IDEA，部署需配合Tomcat 7/8及Maven。

上线后已有70人学习下载，项目经调试确保可运行，后台路径与前台路径均已标注，遇到部署问题还可联系作者咨询，对想快速完成毕设或提升全栈开发能力的同学具有实际参考价值。

1. 老年一站式服务平台：一套 springboot + vue 全栈源码该看什么

每到毕业设计季，后台问得最多的就是这种带源码、带部署教程的 springboot + vue 全栈项目，老年一站式服务平台是其中很有代表性的一个。它的业务并不复杂：老人或家属注册登录、维护健康档案、预约上门服务、查看订单进度，后台再挂一个管理端做服务上下架和基础数据管理。这套闭环能覆盖一个毕设项目里最常见的表设计、接口设计、权限控制和前后端联调，比单独看教程直观得多。

适合三类人。一是 springboot 和 vue 刚学完基础，想照着一套真实代码把前后端串联起来的人；二是毕设选题正好是社区服务、健康管理、平台预约方向，想拿现成框架改需求的人；三是准备 java 后端面试，想在项目经验里讲清楚一条完整业务链路的人。这套资源能解决的是「从零把项目跑起来并且能讲明白」，不是「开箱即用直接交论文」。

2. 技术栈与模块边界：这套 springboot + vue 源码为什么这么分层

这类平台天然有多角色、多入口的特征。老人端要填表单、查订单，服务人员端要接单、改状态，管理端要看统计、维护服务项，三套界面差异很大，放在同一个服务端页面里会越改越乱。前后端分离的结构把页面和接口彻底拆开，Vue 负责交互和路由，Spring Boot 只往外吐 JSON，数据库的读写全部收敛到后端。这个选型不是炫技，是这类业务场景下维护成本最低的做法。

分层清楚之后，还有一层好处：它和 java 后端面试里经常被追问的问题对得上——跨域怎么解决、接口怎么做鉴权、事务边界在哪、订单状态怎么防止并发改乱。与其背八股，不如照着这套代码把 controller、service、mapper 的调用关系捋一遍。

2.1 前后端分离的职责边界：Vue 管交互，Spring Boot 管数据

前端拿到的是一个单页应用，所有页面跳转由 vue-router 控制，数据请求由 axios 发出。后端不关心页面长什么样，只关心请求路径、参数、token 和数据库操作结果。两边通过 JSON 通信，前端拿到数据之后渲染，拿不到就显示错误提示。

理解边界之后，排错就快很多。前端报错先看 Network 面板里请求有没有发出去、返回什么状态码；后端报错再看控制台堆栈第一行是参数问题还是 SQL 问题。我见过太多人把时间花在反复刷新页面上，其实问题只是某个字段名下划线转驼峰没对上。

2.2 后端三层结构：controller、service、mapper 的一次完整调用

先看一个健康档案接口的最小实现，这是这套代码里最常见的形态：

@RestController @RequestMapping("/api/health") public class HealthProfileController { private final HealthProfileService healthProfileService; public HealthProfileController(HealthProfileService healthProfileService) { this.healthProfileService = healthProfileService; } @PostMapping("/profile") public Result<HealthProfile> save(@RequestBody @Valid HealthProfileDTO dto) { return Result.ok(healthProfileService.save(dto)); } @GetMapping("/profile/{userId}") public Result<HealthProfile> getByUser(@PathVariable("userId") Long userId) { return Result.ok(healthProfileService.getByUserId(userId)); } }

@RequestBody把前端传来的 JSON 绑定到 DTO 对象上，@Valid触发参数校验。Result 是统一返回包装，一般包含 code、message、data 三个字段，这样做的好处是前端拦截器只需要判断一次 code，不用每个接口自己处理异常。

实际项目里 service 层通常标注@Transactional，因为保存健康档案时可能要同时更新用户表的字段和档案表的字段，任何一个失败都要回滚。mapper 层只负责数据库读写，不写业务判断。这一层结构如果能自己画一遍，面试时项目介绍环节基本不会卡壳。

2.3 核心表设计：四张表怎么撑起一次服务预约

这类平台的核心表不多，但字段关系值得细看。最典型的四张表是用户表、健康档案表、服务项目表和订单表，下面两张是关联最紧密的：

CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` VARCHAR(32) NOT NULL COMMENT '登录名', `password` VARCHAR(64) NOT NULL COMMENT '密码，存放密文', `role` TINYINT NOT NULL DEFAULT 2 COMMENT '0=管理员 1=服务人员 2=老人家属', `real_name` VARCHAR(32) DEFAULT NULL COMMENT '真实姓名', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `create_time` DATETIME DEFAULT NULL COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

用户表里最关键的是role字段，整套权限控制都建立在它上面。逃生版的项目里权限往往写在每个接口的 if 判断里，严谨一点的会结合 Spring Security 或拦截器统一处理。

CREATE TABLE `service_order` ( `id` INT NOT NULL AUTO_INCREMENT COMMENT '订单ID', `user_id` INT NOT NULL COMMENT '下单老人ID', `service_id` INT NOT NULL COMMENT '服务项目ID', `worker_id` INT DEFAULT NULL COMMENT '服务人员ID', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0=待确认 1=已确认 2=服务中 3=已完成 4=已取消', `scheduled_time` DATETIME NOT NULL COMMENT '预约上门时间', `amount` DECIMAL(10,2) NOT NULL COMMENT '订单金额', `remark` VARCHAR(255) DEFAULT NULL COMMENT '备注', `create_time` DATETIME DEFAULT NULL COMMENT '下单时间', PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_worker_id` (`worker_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表刻意只存 user_id 和 service_id 关联，不冗余服务名称和老人姓名。查询时再做连表，字段更新不会出现两边不一致。健康档案表则以 user_id 为主键一对一关联，记录身高体重、血压、过敏史、慢性病情况，下单时服务人员能看到这些信息决定是否接单。

字段类型上有个细节：状态用 TINYINT 还是 VARCHAR，我建议按这套代码原始定义来，不要自己随手换。TINYINT 省空间，但可读性差，需要用常量类映射；VARCHAR 直观，但查询条件容易写错拼写。两种都有维护成本，关键是选一种之后全项目保持一致。

3. 本地部署实操：从解压到浏览器访问的完整命令与配置

拿到压缩包之后，第一件事不是打开代码乱看，而是先按顺序把环境对齐。这类项目最劝退的环节往往不是代码本身，而是 JDK 版本、Node 版本、数据库版本互相不匹配，导致启动报错一堆英文，看着像大问题，实际上就是环境问题。

下面这一整套流程，我按「后端 → 数据库 → 前端」的顺序走，每一步都给出命令和验证方式。顺序不要乱，先让后端独立能启动，再导入数据，最后启动前端联调，这样出问题的时候定位范围最小。

3.1 环境核对：JDK、Maven、Node、MySQL 的版本底线

用命令检查版本是必要步骤。java -version、mvn -v、node -v、npm -v各执行一遍，确认终端里能识别到。很多启动失败是因为装了 JDK 但 PATH 没配好，IDE 里能运行，命令行里一敲就提示找不到命令。npm 慢的问题也在这里提前处理掉，把镜像换成国内源，后面npm install能省下大量时间。

3.2 修改数据库配置并启动后端：端口和连接串是第一个坎

后端模块一般是一个独立的 Maven 工程，导入 IDEA 后先找到src/main/resources/application.yml或.properties文件。这个文件是后端的启动总开关，最常见的改动就是数据库账号密码和端口。

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/elderly_service?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

serverTimezone是 MySQL 8 最常遇到的坑，不加这一项启动时经常报时区错误。characterEncoding=utf8保证中文写入不乱码，实际库表建议统一用 utf8mb4。依赖下载完成后，直接在 IDEA 里运行启动类，看到 Tomcat started on port 8080 就说明后端起来了。

如果用的是命令行，在工程根目录执行：

mvn spring-boot:run

第一次运行会下载大量依赖，时间可能比较长，这是正常的。启动过程中如果报红，先看是不是 Maven 仓库里的包不完整，常见解法是删掉本地仓库对应的目录再重新刷新依赖。

3.3 导入初始 SQL：库建不对，后面所有页面都是空的

后端能启动之后，数据库必须跟着就位。源码里通常会带一个.sql文件，放在 doc、sql 或 db 目录下，里面是建库建表和初始数据。命令行导入：

mysql -u root -p < /your/path/elderly_service.sql

导入完成后进入 MySQL 检查一下：

mysql -u root -p USE elderly_service; SHOW TABLES;

至少要看到 user、service_item、service_order 这几张表，并且 user 表里有初始账号。很多新手在这一步习惯用 Navicat 手工建表，我建议不要这么做。手工建表极容易漏字段、漏外键，直接导入随包 SQL 才能确保前后端字段对得上。

后端和数据库都就绪后，可以用浏览器访问http://localhost:8080看后端是否正常响应，或者直接启动前端再联调。

3.4 启动前端：npm install 与 devServer 代理配置

前端工程一般叫 frontend、web 或 vue 开头。命令行进入该目录，先装依赖再启动：

npm install npm run serve

装依赖时需要确认 package.json 里的项目用的是 Vue 2 还是 Vue 3，命令本身区别不大，但启动成功后浏览器地址和端口可能有差异。前端开发服务器默认通常在 8081、3000 或 5173，不要和后端 8080 混在一起。

联调遇到跨域时，检查工程里的vue.config.js：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

项目里所有请求都走/api开头，开发环境下由 devServer 转发到后端 8080。如果你是 Vite 工程，这一段的写法会体现在vite.config.js的server.proxy里，核心逻辑一样。看到App running at之后，用浏览器打开前端地址，登录页能弹出来，整个链路就算通了。

4. 核心业务链路：一次服务预约背后，前端路由、接口和状态如何协作

环境通了只是第一步，真正要读懂这套源码，必须顺着一条完整业务链路走一遍。我选最典型的一条：老人登录 → 完善健康档案 → 预约服务 → 服务人员确认 → 服务完成。下面按这条线把关键代码拆开。

4.1 登录鉴权：前端路由守卫与后端 token 校验

老人在前端登录成功后，后端会返回一个 token，前端把它存到 localStorage。之后每次请求都带上这个凭证，页面跳转由 vue-router 守卫控制，这条链路是 Vue 项目里最常见也最值得抄的写法：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { next('/login'); } else { next(); } });

页面级别的权限用路由守卫解决，接口级别的权限由后端拦截器兜底。后端拦截器的基本思路是放行登录接口，其余请求统一验 token：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getRequestURI().startsWith("/api/auth")) { return true; } return TokenUtils.verify(request.getHeader("Authorization")); } }

verify里一般会解析 token 过期时间和签名，失败就抛出未认证异常。这套逻辑能覆盖大部分场景。需要留意的是路由守卫只做前端体验层面的拦截，后端校验才是真正的安全边界，改代码时不要把这两层混着写。

4.2 健康档案：一个表单页面对应一次 POST 请求

老人第一次使用平台，先填一份健康档案。前端表单提交时把数据 POST 到/api/health/profile，后端做参数校验和保存。前端提交代码一般是这样的逻辑：

submitForm() { this.$http.post('/api/health/profile', this.form).then(res => { if (res.data.code === 200) { this.$message.success('档案已保存'); } }); }

这份档案的数据会在服务人员接单前展示，决定服务人员是否接单，所以业务上通常要求过敏史和慢性病字段必填。前后端字段一一对应，前端是bloodPressure，后端 DTO 里就是bloodPressure，如果是blood_pressure就需要在 DTO 上做映射，否则数据传过去直接为 null，表单显示正常、库里却是空的，这种问题最隐蔽。

4.3 服务预约：订单状态如何从待确认走到已完成

订单是这套系统的核心，状态流转是毕设答辩时最容易讲出深度的点。老人提交预约后订单状态是 0（待确认），服务人员接单后变成 1（已确认），服务完成后变成 3（已完成）。这中间每一次变更都要带上权限和状态校验：

public void confirm(Long orderId, Long workerId) { ServiceOrder order = orderMapper.selectById(orderId); if (!"0".equals(order.getStatus())) { throw new BizException("当前订单状态不允许操作"); } order.setStatus("1"); order.setWorkerId(workerId); orderMapper.updateById(order); }

selectById先查原状态再修改，防止把已经取消的订单重新置为确认。更严谨的做法是在订单表加版本号字段，更新时带上version条件，这一处的设计可以直接当作面试亮点来讲。

数据联动上，订单完成之后，后台的统计报表、服务人员的接单数量、老人的订单列表都会刷新。改这一块代码时要顺着service_order表的主键往回追，看哪些查询条件是user_id、哪些是worker_id，改错一个条件表面上页面没变化，但数据统计就会串线。

5. 避坑指南：部署与联调中五个高频翻车点的排查记录

这一章是血泪经验。下面五条问题是我在实际帮人看这套代码时遇到频率最高的，每一条都按「现象 → 原因 → 解决」来写，你顺着排查基本能覆盖 80% 的启动问题。

5.1 后端启动失败，报依赖下载错误或 JDK 内部错误

现象：Maven 刷新依赖时大量报红，或者启动时提示java.lang.IllegalArgumentException: Unsupported class file major version。

原因：springboot 版本和本地 JDK 不匹配。新版 springboot 用了较高版本的字节码，JDK 版本太旧编译不过去；反过来，springboot 版本太高、JKD 太旧也会启动失败。

解决：先看pom.xml里 parent 声明的 springboot 版本，再看java -version。这类毕业设计项目一般不要追新，用 JDK 8 加对应支持的 springboot 版本最稳。确认后刷新 Maven，必要时清理本地仓库重新拉取。

5.2 npm install 卡住不动，或 node_modules 反复丢失

现象：执行npm install长时间停在某个包上，半天没有进度；有时装完一次，换台电脑又要装半天。

原因：默认 npm 源在海外，网络波动大。这个属于 Vue 环境配置里的经典问题，不是代码问题。

解决：先切镜像源，再重装。

npm config set registry https://registry.npmmirror.com npm cache clean --force rm -rf node_modules package-lock.json npm install

切完镜像源之后速度会明显改善。node_modules 不要手工去改内容，出现诡异报错先删掉整个目录重新安装，比逐个包排查快得多。

5.3 后端能启动，但接口报错：数据库连不上或表不存在

现象：页面能打开，登录时提示系统错误，后端控制台显示Communications link failure或Table doesn't exist。

原因：数据库连接串里的库名写错，或者 SQL 没导入成功，再或者 MySQL 8 的认证插件和驱动版本不兼容。

解决：先确认库里有没有service_order等表，没有就重新导入 SQL。再做一次连接串自检，localhost:3306/elderly_service的后半段要和实际库名完全一致。MySQL 8 场景下要在 URL 尾部加serverTimezone=Asia/Shanghai，驱动版本也要跟着升级，避免caching_sha2_password认证报错。

5.4 前端请求跨域，Network 面板显示 CORS 或 404

现象：前端独立端口打开，页面能渲染，但所有接口请求都报跨域，或者请求能发出但返回 404。

原因：开发环境下跨域通常不是因为后端没配跨域，而是前端 devServer 代理没生效。404 则多半是接口路径拼接错了。

解决：先在浏览器 Network 面板看请求 URL，确认是http://localhost:8081/api/...还是直接打到了后端。正确姿势是请求路径以/api开头，由 devServer 转发到 8080。检查vue.config.js里 proxy 的 target 端口是否和后端server.port一致。如果前后端接口已经不在一个端口，这个配置是绕不开的。

5.5 能启动但页面空白，或登录后一直回登录页

现象：前端启动成功，控制台不报错，但页面白屏；或者登录成功后刷新又跳回登录页。

原因：白屏一般是路由模式或静态资源路径问题，跳回登录页则是 token 没有正确存进去，或者后端返回的 token 字段名和前端取的不一致。

解决：先打开控制台看有没有 JS 报错，再点登录看 Network 里登录接口返回的数据结构。重点确认后端返的是token还是data.token，前端localStorage.setItem的 key 必须和路由守卫里读的 key 完全一样。这种问题往往不是逻辑断掉，而是字段名差一个点。

6. 验证与进阶：三种角色走通闭环，再把打包产物塞回 springboot

部署完成不等于交付完成。我建议拿到资源后先不要急着改业务，按三种角色把流程完整跑一遍，确认每一步在数据库里都有记录。

6.1 用户端：建档、预约、查单

用初始账号登录前端，进入个人中心，先填健康档案，保存成功后到订单页提交一个预约。然后在数据表里查service_order，确认状态是 0。

6.2 服务端与管理员：接单、改状态、看统计

切换到服务人员账号，在待接单列表里确认刚下的单，再去数据库看status是否变成 1。最后用管理员账号登录后台，查看订单列表和统计模块，数据对得上，说明权限控制和数据链路都是通的。

6.3 进阶：把 Vue 打包产物放回 Spring Boot

如果答辩时只想开一个后端进程，不想同时开前端 devServer，可以走这个常见的部署方式：

npm run build cp -r dist/* ../backend/src/main/resources/static/

重新启动后端，直接访问http://localhost:8080就能看到前端页面，登录、预约、后台管理全在一个服务里，跨域问题一并消失。需要注意 vite 或 vue-cli 打包后的资源路径，如果页面白屏，去vue.config.js里把publicPath改为相对路径重新打包。

我给自己定的规矩是：每接手一套 springboot + vue 源码，先不急着改业务，而是用默认账号从头到尾跑一遍「建档 → 预约 → 接单 → 完成 → 后台对账」这五个步骤，任何一步在库里没留下记录，我都不会把它交付出去。希望帮到你。

本文还有配套的精品资源，点击获取