简介：本资源是一套面向计算机专业本科生的毕业设计完整实现方案，聚焦社区维修服务场景，采用前后端分离架构解决传统报修流程低效、信息不透明等实际问题。项目基于Spring Boot构建稳定后端，Vue.js实现响应式前端界面，MySQL支撑数据持久化，适合作为课设、毕设或期末大作业的高质量参考范例。压缩包共808个文件，涵盖122个Java核心业务类、46个Vue组件、153个JS交互逻辑、44个CSS样式及48个JPG/PNG素材资源，辅以SQL建库脚本、项目说明文档与完整论文，总大小23.76MB，结构清晰、模块完整，便于快速部署与二次开发。目前已有163人学习下载，资源包含可直接运行的调试环境配置（JDK+IDEA+Tomcat）、双框架备选方案（Spring Boot/SSM）及典型功能模块如用户报修、工单分配、进度跟踪与后台管理，为初学者提供可落地的工程实践路径，也为进阶者预留了功能扩展接口与代码优化空间。
1. 社区维修平台为什么不能只靠“前后端分离”四个字糊弄过去：Spring Boot + Vue 落地时，90% 的毕业设计卡在「业务闭环」而非技术堆砌
你手里的毕设题目写着“基于 Spring Boot + Vue 的社区维修平台”，但真正打开代码仓库、跑通首页、点开提交按钮——才发现：用户提报的维修单，后台查不到；师傅接单后，前端页面没刷新；历史订单导出 Excel，字段全是 null。这不是环境配错了，也不是 Maven 依赖冲突了，而是从需求建模第一天起，就漏掉了“社区维修”这个场景里最硬的三颗钉子：服务时效性（2 小时响应承诺）、角色状态机（居民→报修人 / 物业→派单员 / 师傅→执行者）、工单生命周期（待接单→已派单→上门中→已完成→已评价→已归档）。很多同学把 Vue 当成“套壳工具”，把 Spring Boot 当成“接口生成器”，结果论文写满 RESTful 设计原则，答辩时却答不出“师傅拒单后，工单该退回给谁、触发什么通知、是否计入考核”。这篇笔记不讲 Vue 生命周期或 Spring Security 配置，只聚焦一个目标：用最小可行代码，把“居民在线报修→物业分配师傅→师傅确认上门→居民线上验收”这条主链路，在本地完整走通、可验证、能截图进论文。适合正在写开题报告、卡在数据库 ER 图、或已写完一半代码但联调总失败的本科开发者。
2. 从零搭起可运行骨架：用 Spring Boot 3.2 + Vue 3（Pinia + Element Plus）跑通首条工单流
2.1 后端：Spring Boot 3.2 初始化与核心模块分层设计
Spring Boot 版本选 3.2.x（非 2.x），原因很实际：JDK 17+ 成为高校实验室主流，而 Spring Boot 3.x 强制要求 Jakarta EE 9+（包名从javax.*变为jakarta.*），若用旧版，后续集成 WebSocket 推送、Spring Data JPA 多数据源时会因包冲突反复报错。初始化命令如下：
# 使用 start.spring.io 官方脚手架（推荐） curl "https://start.spring.io/starter.zip?type=gradle-project&language=java&bootVersion=3.2.12&baseDir=demo-repair-platform&groupId=com.example&artifactId=demo-repair-platform&name=demo-repair-platform&description=Community+Repair+Platform&packageName=com.example.demo&packaging=jar&javaVersion=17&dependencies=web,lombok,data-jpa,h2,validation,websocket" -o repair-backend.zip解压后，关键目录结构需强制规范：
com.example.demo.user：用户实体与 Service（含 Role 字段区分RESIDENT/PROPERTY/TECHNICIAN）com.example.demo.order：工单核心模块（RepairOrder实体 +OrderService状态变更逻辑）com.example.demo.notice：轻量通知（WebSocket 推送，非邮件/SMS）
提示：H2 数据库仅用于本地开发与论文演示。
application.yml中必须显式关闭 H2 控制台（spring.h2.console.enabled=false），否则答辩现场被评委点开/h2-console看到空表会暴露未初始化问题。
2.2 前端：Vue 3 + Pinia + Element Plus 最小化集成方案
Vue CLI 已淘汰，改用 Vite 创建项目（编译快、热更稳）：
npm create vite@latest repair-frontend -- --template vue cd repair-frontend npm install npm install pinia element-plus @element-plus/icons-vue axios关键配置文件修改：
main.js中注册 Pinia 和 Element Plus：
import { createApp } from 'vue' import { createPinia } from 'pinia' import ElementPlus from 'element-plus' import 'element-plus/dist/index.css' import App from './App.vue' const app = createApp(App) app.use(createPinia()) // 必须在 use(ElementPlus) 之前 app.use(ElementPlus) app.mount('#app')src/stores/order.js定义工单状态管理（非简单 reactive，需封装提交逻辑）：
import { defineStore } from 'pinia' import axios from 'axios' export const useOrderStore = defineStore('order', { state: () => ({ currentOrder: null, orderList: [] }), actions: { // 提交新报修单（关键：携带用户ID、地址、故障描述、图片base64） async submitRepair(formData) { try { const res = await axios.post('/api/orders', formData) this.currentOrder = res.data return res.data } catch (err) { throw new Error(`报修失败：${err.response?.data?.message || '网络错误'}`) } } } })参数说明：
formData必须包含userId（前端从 localStorage 读取）、address（字符串，非经纬度）、description（限 500 字）、images（字符串数组，每项为data:image/jpeg;base64,...）。此处不校验图片大小，但论文中需注明“实际部署应增加后端图片尺寸限制”。
2.3 前后端联调第一关：跨域与接口契约对齐
Spring Boot 默认禁止跨域，@CrossOrigin注解仅适用于单 Controller，生产级方案是全局配置：
// src/main/java/com/example/demo/config/WebConfig.java @Configuration public class WebConfig { @Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurer() { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOrigins("http://localhost:5173") // Vite 默认端口 .allowCredentials(true) .maxAge(3600); } }; } }前端 Axios 全局配置（src/utils/request.js）：
import axios from 'axios' const request = axios.create({ baseURL: 'http://localhost:8080', // Spring Boot 默认端口 timeout: 10000, headers: { 'Content-Type': 'application/json' } }) // 请求拦截：自动携带 token（若实现登录） request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) config.headers.Authorization = `Bearer ${token}` return config }) export default request逻辑说明：
baseURL必须写死为http://localhost:8080，不可用/api相对路径——Vite 开发服务器代理（vite.config.js 中的server.proxy）仅在开发时生效，打包后失效。此配置确保：本地开发时请求发往后端，论文截图时 URL 清晰可追溯。
3. 数据库设计：避开“三张表搞定一切”的玄学陷阱，用状态机驱动工单流转
3.1 核心四表 ER 关系与字段取舍逻辑
社区维修不是电商订单，不能直接照搬user-order-item三层结构。关键差异在于：
- 居民报修无“购物车”概念，一次只报一个故障点；
- 物业派单不等于“支付成功”，需人工干预；
- 师傅接单后存在“上门中”中间态，需记录预计到达时间；
- 验收环节需居民二次确认，非系统自动完成。
因此，必须拆出repair_order（主单）与order_status_log（状态日志）两张表，而非在repair_order中加status字段硬编码。ER 设计如下（MySQL 8.0+）：
| 表名 | 关键字段（非全字段） | 设计理由 |
|---|---|---|
sys_user | id,username,role(RESIDENT/PROPERTY/TECHNICIAN),phone | 角色字段用枚举值，避免关联 role 表增加复杂度；phone用于短信通知（论文可写“预留扩展”） |
repair_order | id,user_id,address,description,created_time,updated_time | 不存 status 字段！状态由日志表驱动，便于审计与回溯 |
order_status_log | id,order_id,status(PENDING/ASSIGNED/ON_SITE/COMPLETED/EVALUATED),operator_id,operate_time,remark | 每次状态变更必写日志，operator_id记录操作人（物业或师傅 ID），remark存拒单原因等文本 |
order_image | id,order_id,image_url,sort_order | 图片单独建表，支持多图上传；image_url存相对路径（如/uploads/20240520/abc.jpg），后端提供静态资源映射 |
注意：
repair_order.updated_time仅记录最后编辑时间（如居民修改地址），不反映状态变更。所有状态时间以order_status_log.operate_time为准——这是论文中“工单时效性分析”的数据源。
3.2 工单状态机：用 Java 枚举 + 服务方法强制流转约束
定义状态枚举（com.example.demo.order.enums.OrderStatus）：
public enum OrderStatus { PENDING("待接单", Arrays.asList("PROPERTY")), // 仅物业可操作 ASSIGNED("已派单", Arrays.asList("PROPERTY", "TECHNICIAN")), // 物业派单、师傅接单 ON_SITE("上门中", Arrays.asList("TECHNICIAN")), // 师傅点击“已到达” COMPLETED("已完成", Arrays.asList("TECHNICIAN")), // 师傅点击“维修完成” EVALUATED("已评价", Arrays.asList("RESIDENT")); // 居民提交评价 // 注意：无“已取消”状态，拒单走“退回待接单”流程 }关键服务方法（OrderService.java）：
@Transactional public void changeStatus(Long orderId, OrderStatus targetStatus, Long operatorId) { RepairOrder order = orderRepository.findById(orderId) .orElseThrow(() -> new RuntimeException("工单不存在")); // 1. 校验操作人权限 SysUser operator = userRepository.findById(operatorId) .orElseThrow(() -> new RuntimeException("操作人不存在")); if (!targetStatus.getAllowRoles().contains(operator.getRole())) { throw new RuntimeException("权限不足：" + operator.getRole() + " 无法执行 " + targetStatus.getDesc()); } // 2. 校验状态流转合法性（防跳步） OrderStatus currentStatus = getCurrentStatus(orderId); if (!isValidTransition(currentStatus, targetStatus)) { throw new RuntimeException("状态非法跳转：" + currentStatus + " → " + targetStatus); } // 3. 写入状态日志 OrderStatusLog log = new OrderStatusLog(); log.setOrderId(orderId); log.setStatus(targetStatus); log.setOperatorId(operatorId); log.setOperateTime(LocalDateTime.now()); statusLogRepository.save(log); }参数说明：
isValidTransition()方法需硬编码规则，例如PENDING → ASSIGNED允许，PENDING → COMPLETED禁止。此设计让答辩时可清晰展示“状态流转图”，比写一堆 if-else 更具工程说服力。
3.3 初始化测试数据：用 Flyway 实现数据库版本可控
Gradle 依赖加入：
implementation 'org.flywaydb:flyway-core'在src/main/resources/db/migration下创建V1__init.sql：
-- 创建用户（密码为明文，仅用于演示） INSERT INTO sys_user (id, username, password, role, phone) VALUES (1, 'resident001', '$2a$10$ZzZzZzZzZzZzZzZzZzZzZu', 'RESIDENT', '13800138000'), (2, 'property001', '$2a$10$ZzZzZzZzZzZzZzZzZzZzZu', 'PROPERTY', '13800138001'), (3, 'tech001', '$2a$10$ZzZzZzZzZzZzZzZzZzZzZu', 'TECHNICIAN', '13800138002'); -- 创建测试工单 INSERT INTO repair_order (id, user_id, address, description, created_time, updated_time) VALUES (1, 1, '3栋2单元501室', '厨房水龙头漏水，已关闭总阀', NOW(), NOW()); -- 初始状态日志 INSERT INTO order_status_log (id, order_id, status, operator_id, operate_time, remark) VALUES (1, 1, 'PENDING', 2, NOW(), '系统自动生成');逻辑说明：Flyway 在应用启动时自动执行 SQL，确保每次
mvn spring-boot:run都有干净测试数据。密码用 BCrypt 加密（$2a$10$...是占位符），实际部署需用BCryptPasswordEncoder.encode()生成。
4. 避坑指南：毕业设计高频翻车现场与血泪解决方案
4.1 现象：Vue 页面提交报修单，后端 Controller 日志显示收到请求，但数据库无记录，也无异常抛出
原因：RepairOrder实体类中@Id注解缺失，或@GeneratedValue策略与 H2 不兼容（如用了GenerationType.IDENTITY但 H2 表未设AUTO_INCREMENT）。
解决：检查RepairOrder.java，确保主键定义为：
@Id @GeneratedValue(strategy = GenerationType.IDENTITY) // H2 支持 private Long id;并在application.yml中开启 JPA DDL 自动创建（仅开发）：
spring: jpa: hibernate: ddl-auto: update # 或 create-drop（每次重启重建）4.2 现象：Element Plus 的el-upload组件上传图片后，后端@RequestBody接收为 null
原因：el-upload默认用multipart/form-data提交，而@RequestBody只解析application/json。强行用@RequestBody会导致解析失败且静默丢弃。
解决：后端改用@RequestParam接收文件，前端改用action属性直传：
<el-upload action="http://localhost:8080/api/orders/upload" :auto-upload="false" :http-request="handleUpload" >@PostMapping("/upload") public ResponseEntity<Map<String, String>> uploadImage(@RequestParam("file") MultipartFile file) { // 保存文件到 uploads 目录，返回 URL String url = "/uploads/" + System.currentTimeMillis() + "_" + file.getOriginalFilename(); Files.write(Paths.get("uploads", url.substring(1)), file.getBytes()); Map<String, String> res = new HashMap<>(); res.put("url", url); return ResponseEntity.ok(res); }4.3 现象：WebSocket 连接成功，但@MessageMapping方法不触发，控制台无日志
原因：Spring Boot 3.x 中@MessageMapping默认使用 STOMP 协议，需前端显式连接/ws端点并订阅/topic/xxx，而非直接@SendTo。常见误用是后端写@SendTo("/topic/notify")，前端却用new WebSocket("ws://...")原生连接。
解决：前端改用stompjs库：
npm install stompjs @stomp/stompjsimport { Client } from '@stomp/stompjs' const client = new Client({ brokerURL: 'ws://localhost:8080/ws', onConnect: () => { client.subscribe('/topic/notify', (message) => { console.log('收到通知：', message.body) }) } }) client.activate()后端WebSocketConfig.java需启用 STOMP：
@Configuration @EnableWebSocketMessageBroker public class WebSocketConfig implements WebSocketMessageBrokerConfigurer { @Override public void configureMessageBroker(MessageBrokerRegistry config) { config.enableSimpleBroker("/topic"); // 订阅前缀 config.setApplicationDestinationPrefixes("/app"); // 发送前缀 } }4.4 现象：论文答辩时演示“师傅接单”，点击按钮后页面无反应，Network 面板显示 403 Forbidden
原因：Spring Security 默认拦截所有 POST 请求，而@PreAuthorize("hasRole('TECHNICIAN')")注解未生效，因未在SecurityConfig中启用方法级安全。
解决：在SecurityConfig.java中添加：
@Configuration @EnableMethodSecurity // 关键！启用 @PreAuthorize public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authz -> authz .requestMatchers("/api/public/**").permitAll() .requestMatchers("/api/**").authenticated() ) .csrf(csrf -> csrf.disable()); // 毕设可禁用，论文需注明“实际部署需启用” return http.build(); } }并在 Controller 方法上加注解：
@PreAuthorize("hasRole('TECHNICIAN')") @PostMapping("/orders/{id}/accept") public ResponseEntity<?> acceptOrder(@PathVariable Long id) { ... }4.5 现象：H2 数据库控制台能打开，但看到repair_order表为空，sys_user表却有数据
原因：Flyway 的 SQL 文件命名不规范（如V1_init.sql缺少双下划线），或spring.flyway.locations配置路径错误，导致迁移未执行。
解决：检查application.yml：
spring: flyway: locations: classpath:db/migration # 必须与文件实际路径一致并确认 SQL 文件名为V1__init.sql（两个下划线），且位于src/main/resources/db/migration/目录下。启动日志中应出现Flyway Community Edition 9.x.x by Redgate和Successfully validated 1 migration。
5. 让论文图表有说服力：用真实交互截图+数据库日志证明“业务闭环”已达成
5.1 截图组合拳：四张图讲清一条工单的全生命周期
毕业设计论文中，“系统功能截图”章节最容易沦为摆拍。要让评委信服你真跑通了，必须用同一张工单 ID 的连续截图，且每张图标注关键数据来源。推荐以下四图组合（按答辩顺序排列）：
| 图序 | 截图内容 | 数据来源说明 | 论文标注建议 |
|---|---|---|---|
| 图1 | 居民端：填写报修表单（含地址、描述、上传2张图） | 前端el-form绑定formData，图片预览用el-image | “图X-1：居民通过 Web 端提交维修申请，系统生成工单 ID：20240520001” |
| 图2 | 物业端：工单列表页，显示“待接单”状态，点击“派单”弹出师傅选择框 | 后端GET /api/orders?status=PENDING返回数据，status字段来自order_status_log最新记录 | “图X-2：物业人员在工单池中筛选待处理工单，选择技术员 tech001 进行派发” |
| 图3 | 师傅端：APP 首页收到推送（WebSocket），点击进入详情页，底部按钮“确认上门”高亮 | 前端stompjs订阅/topic/notify，message.body解析为 JSON 包含orderId | “图X-3：系统通过 WebSocket 实时推送新工单，技术员响应后状态更新为‘上门中’” |
| 图4 | 数据库日志表查询结果（H2 Console 截图）：order_id=20240520001对应 4 条日志，status字段依次为PENDING→ASSIGNED→ON_SITE→COMPLETED | 执行 SQL：SELECT * FROM order_status_log WHERE order_id = 20240520001 ORDER BY operate_time | “图X-4：工单状态变更日志，时间戳精确到秒，证明业务流程可审计、可追溯” |
提示：所有截图必须带系统当前时间（Windows 任务栏/ macOS 菜单栏可见），避免被质疑为 PS。H2 Console 截图需显示 URL 栏
http://localhost:8080/h2-console和数据库连接状态。
5.2 数据库日志表设计：为论文“数据分析”章节埋下伏笔
很多同学在“系统测试”章节只写“测试通过”，却错过用真实日志做量化分析的机会。order_status_log表天然支持以下论文加分项：
| 分析维度 | SQL 示例 | 论文可写内容 |
|---|---|---|
| 平均响应时长（待接单→已派单） | SELECT AVG(TIMESTAMPDIFF(SECOND, l1.operate_time, l2.operate_time)) AS avg_seconds FROM order_status_log l1 JOIN order_status_log l2 ON l1.order_id = l2.order_id WHERE l1.status='PENDING' AND l2.status='ASSIGNED' | “经统计，物业平均派单耗时 142 秒，满足‘2 小时内响应’的服务承诺” |
| 师傅接单率 | SELECT COUNT(*)*100.0/(SELECT COUNT(*) FROM repair_order) AS rate FROM order_status_log WHERE status='ASSIGNED' GROUP BY order_id | “技术员接单率达 96.3%，未接单工单均因技能不匹配被系统自动过滤” |
| 工单完成时效分布 | SELECT HOUR(TIMEDIFF(l1.operate_time, l2.operate_time)) AS hour_diff, COUNT(*) FROM order_status_log l1 JOIN order_status_log l2 ON l1.order_id = l2.order_id WHERE l1.status='ON_SITE' AND l2.status='COMPLETED' GROUP BY hour_diff | “87% 的维修工单在 2 小时内完成，最长耗时 4.5 小时（涉及配件更换）” |
注意：以上 SQL 需在 H2 Console 中手动执行并截图，不要在论文中贴 SQL 代码，只放分析结论图表。评委更关心你是否理解数据价值，而非会不会写 SQL。
5.3 答辩话术：当被问“这个系统和普通表单网站有什么区别？”
这个问题直击毕设灵魂。别答“用了 Spring Boot 和 Vue”，要聚焦社区维修场景的不可替代性。我一般这样答（语速放慢，手指屏幕）：
“评委老师好，核心区别在于‘状态驱动’而非‘页面驱动’。普通表单提交后，数据进数据库就结束了；而我们的系统，每一次点击——居民提交、物业派单、师傅确认、居民评价——都触发状态机变更，并写入不可篡改的日志表。比如您看这张图（指向图4），同一个工单 ID 有 4 条日志，每条记录操作人、时间、状态。这意味着：如果居民投诉‘师傅没来’，我们可以立刻查日志，确认他是否点了‘上门中’；如果物业说‘派单超时’，我们能精确算出从报修到派单花了多少秒。这种可审计、可追溯、可量化的业务闭环，才是社区维修平台真正的价值，也是我整个设计的落脚点。”
这句话把技术细节（状态机、日志表）转化成了业务语言（可审计、可追溯、可量化），且指向答辩现场的截图证据。说完停顿两秒，等评委点头，再补充一句：“当然，实际落地还需对接短信网关、GIS 地图，这些我在论文‘未来工作’章节已列出。”
希望帮到你。
本文还有配套的精品资源，点击获取
