
简介面向微信小程序毕业设计与课程设计场景的上门维修系统完整源码包覆盖用户、维修员、管理员三类角色的业务闭环。用户端支持首页、广告资讯、维修信息、维修记录、评价与收藏管理维修员可维护维修信息与记录、处理评价管理员则统管用户、维修员、维修信息、维修记录、评价、广告及系统配置功能结构完整适合Java后端与小程序的综合实战练习。包内共1249个文件含java后端、vue管理端、wxml/wxss小程序页面、png/jpg图片、js逻辑文件、json配置及sql数据库脚本等并附带批量启动与构建脚本压缩包26.02MB。已有87人学习下载可据此快速搭建环境、梳理前后端分离开发流程也可作为项目实现时的参考原型节省从零设计到编码的时间。1. 上门维修系统毕设源码Java 小程序 MySQL 的组合为什么值得下“用户在小程序里提交报修维修员接单填写维修记录管理员在后台查评价和工单状态”——这是一套微信小程序毕业设计源码最常见的功能闭环技术栈是 java 小程序 mysql项目名称叫上门维修系统。如果你的毕业设计或课程设计正卡在“有题目没代码、有代码不会跑”的阶段这份资源最大的价值不是省下写代码的时间而是给你一条完整的、能跑通的落地路径前台小程序、维修员端、管理后台三个角色的数据全部串在一个 MySQL 数据库里。它适合两类人想快速完成毕设交付的在校生以及想用真实项目练一遍 Java Web 全栈的初学者。接下来我会把环境、表结构、接口逻辑和踩坑点逐个拆开讲照着做基本能复现。如果你只是想要代码但不想理解业务结构后面几章至少能帮你少踩一半的坑。2. 环境对齐是第一步JDK1.8、MySQL5.7、Tomcat7 与三个批处理脚本不管代码多完整环境不对齐第一步就会卡住。先说结论这份资源是按“JDK 1.8 MySQL 5.7 Maven 3.3 Tomcat 7”这套组合准备的数据库工具是 Navicat 11小程序端用 HBuilderX 或微信开发者工具打开。这套组合看起来老但恰恰是很多高校实验室和毕设答辩环境的默认配置。版本选型不是拍脑袋而是因为项目里大量依赖、连接方式和 SQL 写法都是基于这套环境验证过的换新版本反而容易出现“你根本不知道为什么”的报错。2.1 版本清单与选型理由为什么是 JDK 1.8 而不是 17先把版本对照表放出来你按这张表装就不会乱组件建议版本说明JDK1.8大多数毕设代码基于 JDK 8 编译换高版本会触发兼容问题MySQL5.7与 Navicat 11 配合最顺避免 MySQL 8 的认证插件和 SSL 问题Navicat11导入数据库文件、查表结构最方便Maven3.3依赖管理3.3 以下对 JDK 8 支持不好Tomcat7与 JDK 8 组合稳定部署 war 包最常用小程序工具HBuilderX / 微信开发者工具二选一即可选 JDK 1.8 而不是 17核心原因是 JSP、Servlet 以及老版本 Spring 项目在 JDK 9 以上会出现模块化限制例如javax.xml.bind在 JDK 11 被移除编译直接报错。MySQL 5.7 选型则是考虑到 Navicat 11 对 MySQL 8 的caching_sha2_password认证插件支持不好连接时报错时很多人会误判成密码错误其实是协议不兼容。如果你电脑上已经装了 MySQL 8我建议不要强行切换而是给这个项目单独装一个 MySQL 5.7 实例端口用 3307避免影响你其他的开发环境。2.2 安装与启动脚本1-install.bat、2-run.bat、3-build.bat 怎么配合压缩包里带了三个批处理文件1-install.bat、2-run.bat、3-build.bat。这是 Windows 环境下最常见的顺序脚本含义从命名就能看出来先安装依赖再构建打包最后启动运行。我拆过的项目里很多新手上来就双击2-run.bat结果提示找不到依赖原因就是第一步还没执行。# 1-install.bat 常见内容以包内实际脚本为准 mvn -f pom.xml clean install -DskipTests # 2-run.bat 常见内容 mvn -f pom.xml spring-boot:run # 3-build.bat 常见内容 mvn -f pom.xml package -DskipTests-DskipTests是跳过测试用例编译毕设项目一般没有完整测试集加这个参数能减少构建时间。spring-boot:run是 Spring Boot 插件的启动命令如果你看到的是catalina.bat run说明项目是传统 war 包部署方式那就用 Tomcat 7 的 bin 目录手动启动。跑脚本之前务必先做两件事一是确认JAVA_HOME环境变量指向 JDK 1.8二是在命令行执行mvn -v看到 Maven 版本号否则脚本会直接闪退。2.3 数据库导入Navicat 11 导入 MySQL 5.7 的字符集细节数据库文件是.sql后缀用 Navicat 11 导入时最容易翻车的是字符集。新建连接时字符集选utf8mb4导入 SQL 文件时同样保持 utf8mb4否则中文字段会变成问号。导入前建议先手动建一个空库CREATE DATABASE IF NOT EXISTS wx_repair DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE wx_repair; -- 然后通过 Navicat 的“运行 SQL 文件”功能导入包内的 SQL SHOW TABLES;utf8mb4与utf8的区别在于能完整支持 emoji 和部分生僻字虽然这个系统里大概率用不到 emoji但统一用 utf8mb4 可以避免后续插入数据时报Incorrect string value错误。COLLATE utf8mb4_unicode_ci是排序规则影响中文排序和查询时的比较逻辑保持默认即可。导入完成后用SHOW TABLES验证表数量是否与文档一致如果有表缺失大概率是 SQL 文件里DROP TABLE语句顺序导致的重新导入前先手动清空目标库。3. 数据与业务如何落库核心表、登录态与维修闭环系统的业务模型从摘要里看得很清楚用户、维修员、管理员三个角色围绕“维修信息—维修记录—评价信息”这条主链路展开。先理解表之间的关系再看代码才不会迷路。这一章我用“从表结构倒推业务”的方式把后端的设计逻辑讲透同时给出典型的建表语句和接口处理范式。3.1 核心表设计从业务功能倒推五张关键表根据摘要描述管理员要管理“用户、维修员、维修信息、维修记录、评价信息、广告信息”这说明核心数据表至少有六张。但真正决定业务闭环的是维修相关的三张表维修信息表存用户提交的报修单维修记录表存维修员的处理结果评价信息表存用户对服务的反馈。典型的结构如下CREATE TABLE repair_info ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, user_id INT NOT NULL COMMENT 用户ID, repair_type VARCHAR(50) COMMENT 维修类型如水电/家电, description TEXT COMMENT 故障描述, status TINYINT DEFAULT 0 COMMENT 0待接单 1维修中 2已完成 3已取消, create_time DATETIME COMMENT 提交时间 ); CREATE TABLE repair_record ( id INT PRIMARY KEY AUTO_INCREMENT, repair_id INT NOT NULL COMMENT 关联repair_info.id, worker_id INT NOT NULL COMMENT 维修员ID, result TEXT COMMENT 处理结果, cost DECIMAL(10,2) DEFAULT 0 COMMENT 费用, record_time DATETIME COMMENT 记录时间 ); CREATE TABLE evaluation ( id INT PRIMARY KEY AUTO_INCREMENT, repair_id INT NOT NULL, user_id INT NOT NULL, score INT DEFAULT 5 COMMENT 评分1-5, content VARCHAR(500), eval_time DATETIME );建表语句里最重要的字段是repair_id它把维修记录、评价信息都关联到原始报修单上这就是一对多关系一条维修信息可以对应一条维修记录、一条评价也可以对应多次记录比如维修员上门两次。status字段是整个系统的状态机核心所有角色看到的列表都要根据这个值过滤。实际项目包里的 SQL 字段名可能与这里不完全一致但业务含义相同你导入后可以用 Navicat 的表设计器对比查看。3.2 登录与鉴权用户、维修员、管理员如何走同一套接口三个角色共用同一个后端应用登录接口通常只有一套靠用户类型字段区分后续权限。常见做法是在用户表里加role字段0 表示用户1 表示维修员2 表示管理员。Controller 层的处理逻辑通常是拦截器读取登录状态再校验角色编码。// 伪代码登录接口处理逻辑 PostMapping(/api/login) public Result login(RequestBody LoginRequest req) { User user userMapper.findByUsername(req.getUsername()); if (user null || !user.getPassword().equals(MD5Util.md5(req.getPassword()))) { return Result.error(用户名或密码错误); } // 生成登录令牌放入当前会话 session.setAttribute(loginUser, user); return Result.success(user); } // 伪代码权限拦截器 public boolean preHandle(HttpServletRequest request, HttpServletResponse response) { User user (User) request.getSession().getAttribute(loginUser); if (user null) { response.setStatus(401); return false; } // 判断接口要求的角色与当前用户角色是否匹配 if (requiredRole(request.getRequestURI()) ! user.getRole()) { response.setStatus(403); return false; } return true; }这个设计点值得你在毕设答辩时讲清楚前端小程序不直接访问数据库所有数据操作都走后端接口登录后把用户对象放进 Session 或 Token后续请求通过拦截器验证身份。requiredRole方法可以是一个简单的路径映射表例如/api/admin/**要求角色为管理员/api/worker/**要求角色为维修员。如果项目用的是前后端分离登录后返回 token 给小程序小程序每次请求携带 token 即可后端用过滤器解析。3.3 维修业务闭环从提交报修到评价完成的完整数据流理解整个系统的关键在于一条业务链用户提交维修信息 → 维修员接单并填写维修记录 → 用户对维修记录进行评价 → 管理员在后台查看统计。这条链路上的状态值变化非常固定状态值含义该状态下的操作0待接单维修员可查看并接单1维修中维修员填写处理中记录2已完成用户可发起评价3已取消用户取消报修用户提交报修后repair_info.status初始为 0维修员点击接单状态改为 1维修完成填写repair_record后状态改为 2用户只有在状态为 2 时才能提交评价。如果用户中途取消状态直接改为 3这条工单不再进入维修员列表。这个状态机在代码里往往用Integer判断没有太复杂的流程引擎但你在写业务逻辑时要注意一个常见问题高并发情况下两个维修员同时接单一个简单的update repair_info set status 1 where id ? and status 0就能避免重复接单这个 SQL 的where status 0条件就是乐观锁的简化版答辩时能讲出这一点会加分不少。4. 三端联动的路由逻辑小程序页面、Vue 后台与角色权限上门维修系统不是单页面应用而是“小程序 Web 后台”两个前端载体后面再接一套 Java 后端。小程序端给用户和维修员用Web 后台给管理员用。这一章把两端的技术栈和页面组织方式讲清楚顺便解释项目根目录里那些奇怪的.bak文件是什么来历。4.1 小程序端页面结构首页、广告、新闻资讯与个人中心摘要里说用户和维修员在小程序端能看到“首页、广告信息、新闻资讯、我的”四个板块。这是一个典型的 tabBar 结构四个页面平级切换业务入口集中在“我的”页面里——用户能看到维修信息管理、维修记录、评价信息、收藏管理维修员能看到同一页面的不同菜单项。小程序的页面配置文件通常是app.jsonpages 数组的顺序决定启动页{ pages: [ pages/index/index, pages/ad/ad, pages/news/news, pages/mine/mine ], window: { navigationBarTitleText: 上门维修, navigationBarBackgroundColor: #4CAF50, backgroundTextStyle: light }, tabBar: { list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/ad/ad, text: 广告 }, { pagePath: pages/news/news, text: 资讯 }, { pagePath: pages/mine/mine, text: 我的 } ] } }pages/index/index对应首页后面的字段分别对应页面文件所在路径tabBar.list最多配五个这里正好四个。注意小程序的页面文件是四件套.js、.wxml、.wxss、.json页面目录里缺任何一个文件都会导致编译失败。“我的”页面里的菜单通常通过wx:for循环渲染点击后wx.navigateTo跳转到对应管理页这个管理页就是维修信息、维修记录、评价信息等功能的入口。4.2 后台管理端从 .bak 文件看出管理系统技术栈你解压项目后会在后台管理目录里看到一堆带.bak后缀的文件比如main.css.bak、update-password.vue.bak、IndexMain.vue.bak、IndexAsideStatic.vue.bak、BreadCrumbs.vue.bak、IndexHeader.vue.bak。.bak就是备份文件说明这个后台管理界面是 Vue 单文件组件结构。把这几个文件名串起来看IndexMain.vue是主体内容区IndexAsideStatic.vue是左侧静态菜单栏IndexHeader.vue是顶部导航栏BreadCrumbs.vue是面包屑导航——这是非常标准的后台管理布局。后台管理的前端结构通常是index.html入口main.js创建 Vue 实例router.js配置路由。例如update-password.vue.bak说明系统里有“修改密码”功能页对应的管理员操作是个人中心里的密码重置。部署时如果 Vue 端是本地开发模式运行npm install和npm run dev即可但正式的毕设环境一般会把 Vue 构建后的静态文件放到 Java 项目的webapp目录下这样 Tomcat 启动后直接通过http://localhost:8080访问同一套后端不会出现跨域问题。这一点是很多新手容易忽略的小程序通过wx.request请求http://localhost:8080属于跨域而后台管理端如果和 Java 后端同端口部署则天然同源。4.3 三端权限矩阵角色决定菜单菜单决定可见数据权限的最终落点是菜单和数据范围。把摘要里的功能整理成一张矩阵表你在答辩时照着讲即可角色可见模块关键操作看不到的数据用户首页、广告、资讯、我的提交维修信息、查看维修记录、评价、收藏维修员信息、他人的工单维修员首页、广告、资讯、我的查看待接单、接单、填写维修记录用户评价管理、管理员菜单管理员系统首页、个人中心、用户管理、维修员管理、维修信息管理、维修记录管理、评价信息管理、广告信息管理、系统管理分配维修单、删改用户、维护广告、查看评价统计无注意用户和维修员在小程序端看到的 tabBar 几乎一样区别在“我的”页面里的菜单列表。真正实现这种差异的代码不在小程序端而在后端接口前端根据登录用户的role字段动态渲染菜单后端又根据role限制了接口返回的数据范围。比如维修员调用repair_info/list时后端只返回status 0的待接单和worker_id 当前用户id的已接单用户调用同一接口时则只返回user_id 当前用户id的数据。很多新手直接把前端菜单藏起来就以为安全了实际上后端接口不过滤数据范围才是真正的漏洞。5. 常见问题避坑版本冲突、真机请求与中文乱码这一章是我在拆解和复现同类毕设项目时碰到的最多的坑。现象、原因、解决方式一条条写清楚你照着排查能省下大量时间。5.1 现象本地跑通换到另一台电脑启动白屏或 500原因项目在原始电脑上使用的 JDK、MySQL 版本与目标机器不一致。最常见的是目标机器装了 MySQL 8驱动连接串还写着com.mysql.jdbc.Driver而 MySQL 8 要求使用com.mysql.cj.jdbc.Driver同时需要显式追加serverTimezoneAsia/Shanghai参数。解决先看项目的application.properties或db.properties连接串如果驱动是com.mysql.jdbc.Driver要么把 MySQL 降级到 5.7要么把连接串改成spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver spring.datasource.urljdbc:mysql://localhost:3306/wx_repair?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseuseSSLfalse一定要加MySQL 8 默认开启 SSL 加密连接本地开发环境没配证书时会出现SSL connection error。serverTimezone不加的话时间字段会报错因为 MySQL 8 默认时区与 JVM 不一致。5.2 现象小程序开发工具里请求正常真机预览时全部失败原因微信小程序真机环境强制校验合法域名开发工具勾选了“不校验合法域名”才能连本地接口但真机没有这个选项。你本地http://localhost:8080不是 HTTPS 域名真机直接拦截。解决开发调试阶段在微信开发者工具右上角“详情—本地设置”里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。如果你要部署到体验版就必须准备一台 HTTPS 域名服务器把后端接口挂上去并在小程序后台配置 request 合法域名。很多毕设只是本地演示勾选该项即可但答辩时如果评委用手机扫码预览你要提前说明这是本地调试模式。5.3 现象导入 SQL 后中文全部变成问号原因SQL 文件本身是 UTF-8 编码但 Navicat 11 连接数据库时默认字符集是GBK或latin1导入时把 UTF-8 的中文字节用错误字符集解析落库就成乱码。解决在 Navicat 中新建查询先执行SET NAMES utf8mb4;再一次连接数据库时右键连接属性选择“编码—UTF-8”。如果已经导入且乱码最简单的办法是把库删掉重新导入不要试图用UPDATE修复因为字节已经损坏。导入后执行SELECT * FROM repair_info;抽查几条中文数据是否正常。5.4 现象Maven 构建失败报Failed to execute goal或依赖下载超时原因Maven 镜像源默认连中央仓库国内网络环境下载依赖慢或直接失败。另一个常见原因是settings.xml里配置了不存在的本地仓库路径。解决修改 Maven 的settings.xml把镜像源换成阿里云mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/central/url /mirror同时确认localRepository标签指向的目录存在Windows 路径例如D:/maven_repo不要写反斜杠否则部分插件会报错。改完重新执行1-install.bat。5.5 现象Tomcat 7 启动后页面能开但接口返回 404原因项目部署路径与访问路径不匹配。如果你把 war 包命名为repair.war那访问地址是http://localhost:8080/repair/小程序请求路径也应该带上/repair前缀。很多接口文档里写的是/api/login实际要访问/repair/api/login。解决在项目里全局搜索/api/看后端RequestMapping是否有类级别的/repair前缀。或者直接看 Tomcat 的webapps目录下 war 包解压后的文件夹名。最省事的做法是把 war 包改名为ROOT.war覆盖这样访问根路径http://localhost:8080/即可所有接口路径都与开发时一致。这个方法我每次部署毕设项目都在用能少改很多代码。6. 答辩演示的进阶做法十分钟闭环路径与接口验证技巧资源能跑通只是第一步答辩时要让评委一眼看出系统的完整性。我常用的做法是提前准备一条“演示闭环”把三个角色的动作串成十分钟的剧情同时用接口工具快速验证数据一致性。演示路径我建议固定为五步第一步用普通用户账号登录小程序首页查看广告和资讯进入“我的—维修信息”提交一条新的维修单描述写“厨房水龙头漏水”第二步切换维修员账号登录在维修信息列表看到这条新单点击接单第三步维修员进入维修记录管理填写上门处理结果状态变为已完成第四步切换回用户账号对该条维修单提交五颗星评价并写评语第五步用管理员账号登录后台在用户管理、维修员管理、评价信息管理三个页面分别展示这条数据的完整生命周期。这条路径覆盖了全部核心表的新增、更新、联查操作。演示过程中用一个小技巧在浏览器开发者工具的 Network 面板里打开repair_record相关的请求当场展示接口返回的 JSON 数据。这一步不需要额外工具但能直观证明数据确实从小程序写入了 MySQL而不是写死在页面里。如果你安装过接口调试工具也可以直接调用后端接口模拟用户提交// 模拟小程序 wx.request 的请求格式 wx.request({ url: http://localhost:8080/api/repair/save, method: POST, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) }, data: { repairType: 水电维修, description: 厨房水龙头漏水需要更换阀芯 }, success: (res) { if (res.data.code 200) { wx.showToast({ title: 提交成功 }); } } });这里的Authorization头是常见做法如果项目用的是 Session 登录态则不需要这个字段后端从 Cookie 中读取会话。演示前你先用数据库工具查一下repair_info表的最大自增 id讲解时把这个 id 指给评委看说明每提交一条工单数据库里就真实多一条记录。这种“先讲业务、再讲数据、最后讲验证方式”的节奏比空念 PPT 可靠得多。我还有另一个习惯答辩前务必把数据库重新导出一次清空自己测试产生的脏数据然后按照第 2 章的顺序从零跑一遍。每次我以为代码没问题都会被这一步查出问题——不是某个脚本没执行就是 MySQL 服务没启动。从那以后我每次拿到新的课设或毕设源码都强制自己从空白环境完整走一遍部署链路确认没有依赖“上次碰巧配置过的环境变量”才能安心。希望这份拆解能帮你在复现这套上门维修系统时少走弯路把时间留给真正重要的业务理解和答辩准备。本文还有配套的精品资源点击获取