简介：基于小程序的上门维修系统源码，面向高校软件专业毕业设计、课程设计等场景，解决了维修服务类课题从零搭建前后端与数据库的难题。系统分为前台用户模块、维修员模块和管理员模块三部分，分别支持维修信息与维修记录管理、评价信息管理、广告与新闻资讯维护等功能，完整覆盖预约报修类项目的核心业务闭环。压缩包共1249个文件，约26.06MB，以Java、Vue、JS等开发文件为主，另有数据库SQL脚本，并配有多张PNG/JPG界面截图与说明文档，项目环境为JDK1.8、MySQL5.7、Tomcat7及微信开发者工具，可直接导入相关IDE运行。已有121人学习/下载，适合作为课题设计参考或二次开发蓝本，有利于梳理角色权限、数据表设计和小程序端页面交互；内容预览中还包含运行部署批处理脚本，便于快速完成环境搭建与启动验证。
1. 小程序上门维修系统源码：不是小程序Demo，是一整套能答辩的Java项目
第一次打开“小程序上门维修系统源码”这个zip压缩包时，多数人会被里面的文件后缀吓到：main.css.bak、update-password.vue.bak，乍看以为是一堆备份文件混进了项目里。真正看进去后会明白，这套资源的核心不是小程序那几十KB页面，而是Java后台、MySQL表结构和三套角色模块组成的完整业务闭环。去年我给不少准备Java课程设计和毕业设计的同学看过类似包，结论非常一致：这是一份“小程序前端 + Java后端 + 数据库脚本”三段式齐全的源码，从用户下单、维修员接单、管理员审核到评价管理，每个环节都有代码落点，适合拿来改改交作业，也适合当成SSM架构练手项目拆着玩。
2. 从zip到能跑起来：三个bat脚本、数据库导入与首次启动
2.1 先摸清压缩包骨架：那些.bat文件才是入口
解压后不要急着用IDE打开源码，先把根目录下的一排批处理文件搞明白。这类“1-install.bat、2-run.bat、3-build.bat”的结构在Java毕设里很常见，基本约定是：
| 脚本 | 约定作用 | 实际验证点 |
|---|---|---|
| 1-install.bat | 初始化环境 | MySQL服务是否启动、Maven依赖是否拉全 |
| 2-run.bat | 一键启动项目 | Tomcat能正常起来，端口无冲突 |
| 3-build.bat | 重新构建 | 修改后端代码后重新打war包 |
常见做法是先跑1-install.bat，再跑2-run.bat；只有改动Java源码才需要碰3-build.bat。我一般会把这三个.bat都用文本编辑器打开看一眼，重点是里面有没有写死数据库密码，因为这直接决定你后面要不要改配置。
@echo off echo [1/3] 检查MySQL服务... net start mysql || echo MySQL服务未启动，请先手动启动 echo [2/3] 创建数据库并导入... mysql -uroot -p123456 -e "create database if not exists repair_db default charset utf8mb4" mysql -uroot -p123456 repair_db < db/repair_db.sql echo [3/3] 拉取Maven依赖... mvn clean install -DskipTests pause这段批处理的逻辑很直白：先确保MySQL服务在跑，再建库导数据，最后用Maven把依赖装好。“||”的含义是前一条命令失败时才执行后面那句提示，所以如果你本机MySQL服务名不是默认的“mysql”，这里会一直报错——这是第一次跑install脚本最常见的翻车点。另外注意-p123456，如果本地数据库密码不是123456，务必改成你自己的，否则第二步导入必失败。
2.2 数据库导入：Navicat 11 连 MySQL 5.7 的四个细节
数据库是这个项目的重头戏。先强调一遍环境：MySQL 5.7 + Navicat11，这套组合如果换成MySQL 8会出现密码认证插件不兼容的问题，所以别轻易升级数据库版本。
导入时按这个顺序操作：
# 1. 打开Navicat，新建连接，端口默认3306 # 2. 右键连接，新建数据库，库名与脚本内库名保持一致，字符集选utf8mb4 # 3. 选中库，右键“运行SQL文件”，选择压缩包里sql目录下的脚本 # 4. 执行完毕后刷新，看表是否全部生成这里有三个细节你是绕不过去的。第一，库名不一致会导致启动后报“Table doesn't exist”，Java代码里配的是哪个库名，Navicat里就必须建重名库；第二，字符集统一utf8mb4，否则导入中文数据会变成一堆问号，尤其是广告信息、评价内容；第三，这一步值得多花二十分钟把表结构过一遍，这属于全场收益最高的做法，因为后面调接口时你经常要回头查字段名。
导入完成后建议执行一条验证命令，确认核心表都在：
SHOW TABLES;正常情况下你会看到用户表、维修员表、维修信息表、维修记录表、评价信息表、广告信息表、新闻资讯表和系统管理相关的表。如果表数量少了一半，那多半是SQL脚本半路出错，回到第3步重新导入。
2.3 首次启动：Tomcat 7、端口占用与日志定位
数据库就绪后，项目能否启动取决于两点：Tomcat版本对不对、端口有没有被占用。这个包的服务端是基于JDK1.8 + Tomcat7的，如果你机器上装的是Tomcat9或10，轻则启动报错，重则Servlet API不兼容页面白屏。
启动命令不复杂：
cd tomcat7/bin startup.bat启动后马上看日志，不要干等：
cd ../logs tail -f catalina.out看到“INFO: Server startup in xxx ms”才算真正起来。如果日志刷到一半停住或者报Port 8080 was already in use，说明8080端口被别的进程占了。解决手法是用netstat -ano | findstr 8080找到占用进程的PID，再去任务管理器结束它，或者改Tomcat的server.xml把端口换成8081。改端口的话记得小程序端的请求地址要同步改，否则会出现后端明明在跑、小程序却一直请求超时的诡异现象。
3. 三端模块拆解：用户、维修员、管理员的数据流设计
3.1 管理员端：系统首页聚合 + 五张核心管理表的权限边界
管理员是这个系统里权限最大的角色，功能上覆盖“系统首页、个人中心、用户管理、维修员管理、维修信息管理、维修记录管理、评价信息管理、广告信息管理、系统管理”。
从数据角度看，管理员端首页通常就是一组统计数字：注册用户量、维修员数量、待处理维修单数、平均评价分。这些统计背后是SQL聚合查询，你可以直接复用项目里写好的统计接口。
管理员端真正的核心是“用户管理”和“维修员管理”。一般靠user表和repairer表里单独的角色字段区分，管理员对这俩表拥有新增、禁用、删除的权限。“禁用”这个操作值得提一句，它在设计里一般是改status字段而不是物理删除，这样保留用户的历史维修记录和评价，后续出对账数据才不会丢。
“广告信息管理”和“新闻资讯管理”属于内容发布模块，这在毕业设计答辩时是很好的功能闪光点，因为很多同学的项目里没有“运营后台”的概念。这两块本质是富文本的增删改查，需要注意的是富文本内容里可能带HTML标签，前端展示时如果直接渲染会XSS，所以小程序端展示广告详情时要做好标签过滤或使用组件自带的安全渲染。
3.2 维修员端：接单、回填记录与评价处理的状态流转
维修员端的入口与用户端一致：首页、广告信息、新闻资讯、我的。在“我的”页面下，维修员可以管理维修信息、维修记录和评价内容，注意这里比用户端少了“我的收藏”，因为收藏是纯用户行为。
维修员的核心动作其实是“状态流转”，这在整个项目里最有设计含量。一条维修信息的完整状态一般是这样：
待接单 → 维修中 → 已完成 → 已评价
这四个状态在表里通常用一个state字段表示，后端接口接收参数修改字段值。很多没做过这类项目的同学会把状态处理写成一堆if-else硬编码，这里我建议你去看一下源项目写的状态码定义，一般会有常量类管理，比散落的魔法数字好维护得多。
维修员端最容易在答辩被追问的问题是：“多个维修员怎么避免重复接单？”常见做法是维修员点击接单时，后端接口先做一次状态查询，只有“待接单”状态才允许更新，并且将维修员ID写入订单记录。如果没做并发控制，两个维修员同时点接单，就可能出现一条维修单被认领两次。
3.3 用户端：下单、维修、评价、收藏的完整闭环链路
用户端是功能最全的端口，同时也是数据表的“起点”和“终点”。用户进来看到首页、广告信息、新闻资讯，在“我的”页面里管理自己的维修信息、维修记录、评价信息和收藏。
整条业务链路可以串成一句话：用户提交维修信息，维修员接单并回填维修记录，用户针对记录做评价，评价数据沉淀后成为管理员后台的统计数据源。这个闭环里评价和收藏单独设计了表，评价表通常关联维修记录ID，收藏表关联广告信息或资讯ID。
我建议你拿到源码后先画一张简化的表关系图，再对照项目代码逐个看接口。这个项目的后台表大概是这样的关系：
-- 用户表与维修信息表（简化示意） CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50), role TINYINT ); CREATE TABLE repair_info ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, repairer_id INT, status TINYINT, create_time DATETIME, FOREIGN KEY (user_id) REFERENCES user(id) ); CREATE TABLE repair_record ( id INT PRIMARY KEY AUTO_INCREMENT, repair_id INT, content VARCHAR(500), cost DECIMAL(10,2), create_time DATETIME ); CREATE TABLE evaluation ( id INT PRIMARY KEY AUTO_INCREMENT, record_id INT, score TINYINT, content VARCHAR(500) );这段SQL只保留最关键的外键关系。注意repair_info同时挂了用户ID和维修员ID，这表示一条维修信息由用户发起、被维修员接单后建立关联；evaluation挂在repair_record下面而不是repair_info下面，这个设计是合理的，因为一次维修信息可以被拆分成多次维修记录，评价针对的应该是具体某次维修服务，而不是整张维修单。
4. 小程序端联调：HBuilderX/微信开发者工具与Java后端对接
4.1 页面结构认识：pages目录、tabBar与列表加载更多
小程序端的代码在项目里是独立目录，用HBuilderX或微信开发者工具都能打开。如果你在项目里看到的是main.css.bak这种文件，说明开发者用的是HBuilderX加Vue风格写法，这种项目的目录结构一般是：
pages/ index/ 首页 advertise/ 广告列表 news/ 新闻资讯 mine/ 我的 repair/ 维修信息 record/ 维修记录 evaluate/ 评价 favorite/ 我的收藏底部tabBar一般是首页、广告信息、新闻资讯、我的四个入口。“广告信息”这个概念在你的微信小程序里对应的是一个列表页加详情页，数据来自后端的广告表。
列表页的“加载更多”是答辩时常被问到的功能点，小程序里做法是用页面的onReachBottom生命周期：
Page({ data: { pageNum: 1, pageSize: 10, list: [], hasMore: true }, onReachBottom() { if (!this.data.hasMore) return this.setData({ pageNum: this.data.pageNum + 1 }) this.loadList() }, async loadList() { const res = await request(`/api/advert/list?pageNum=${this.data.pageNum}&pageSize=${this.data.pageSize}`) this.setData({ list: this.data.list.concat(res.records), hasMore: this.data.pageNum < res.totalPage }) } })这段代码的要点有两个：第一，onReachBottom是页面滚动到底部的自动回调，不需要你自己绑定滚动事件；第二，分页数据用concat追加而不是覆盖，否则第二页数据会把第一页顶掉，页面看起来永远只有10条。hasMore判断来自后端返回的总页数，如果后端接口没返回这个字段，你需要自己在返回体里加。
4.2 request请求封装与URL配置：本地联调的正确姿势
小程序发请求不能直接裸写wx.request，一般会封装一个request模块，统一管理BASE_URL、请求头、token注入和错误拦截。源码里大概率已经有封装，你把URL改成自己电脑的局域网IP即可。
const BASE_URL = 'http://127.0.0.1:8080' function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method: method, data: data, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token') || '' }, success(res) { if (res.statusCode === 200) { resolve(res.data) } else { wx.showToast({ title: '请求失败', icon: 'none' }) reject(res) } }, fail(err) { reject(err) } }) }) } module.exports = request参数说明：BASE_URL在真机调试时要改成电脑在局域网内的IP，比如http://192.168.1.100:8080，不能继续用127.0.0.1，因为手机上的127.0.0.1指向手机自己；用Promise包装是为了配合async/await写法，让分页、表单提交这类逻辑更清晰。
4.3 常见联调报错与定位顺序
联调阶段最常出现的三类问题，按“能通、通了一半、响应了但用不了”的顺序排：
第一，完全请求不通，提示“ERR_CONNECTION_REFUSED”。这通常是后端Tomcat没启动，或BASE_URL的端口写错。
第二，请求通了但报500。这是后端接口异常，优先看Tomcat的catalina.out日志，定位到具体哪一行Java报错。最常见原因是数据库表字段和实体类对不上，比如实体里写的是createTime，数据库里字段叫create_time，且MyBatis没开启驼峰映射。
第三，响应200但页面没数据。这种情况优先排查返回体结构和前端解析字段是否一致，后端返回{code:0, data:[...]}，前端却去取result.list，字段对不上就会白屏。
5. 避坑指南：从项目能跑到能演示的五条血泪经验
5.1 本地环境层的三个坑：端口占用、数据库密码和字符集
坑一：Tomcat启动失败，日志提示端口占用。现象是双击startup.bat后窗口一闪而过，浏览器访问8080打不开。原因多半是之前装过其他服务占用了8080。解决：netstat -ano | findstr 8080查到PID后在任务管理器结束进程，或改Tomcat的server.xml换端口，但换端口后记得同步改小程序端的BASE_URL。
坑二：启动时提示“Access denied for user 'root'@'localhost'”。原因是项目里jdbc.properties或application.yml配置的数据库密码和你本机实际密码不一致。解决：找到配置文件改成你自己的密码。这类项目的数据库配置一般在src/main/resources目录下，文件名可能是jdbc.properties、db.properties或application.yml。
坑三：导入SQL后中文全部变成乱码。原因是Navicat连接字符集和导入字符集不一致。解决：新建数据库时直接选utf8mb4，导入前在Navicat的连接属性里把编码也设为utf8mb4。项目里的数据库连接URL最好也加上characterEncoding=utf-8，否则后端读写中文时会出现问号。
5.2 小程序联调层的两个坑：合法域名与后端地址漂移
坑四：小程序请求报“不在以下合法域名列表中”。现象是预览时接口全部失败，后台日志里根本没收到请求。原因：微信开发者工具默认校验HTTPS合法域名，本地调试的http接口不在白名单里。解决：开发者工具右上角“详情—本地设置”里勾选“不校验合法域名、TLS版本以及HTTPS证书”。这是本地开发的常规操作，上线时才需要配置正式域名和HTTPS证书。
坑五：在电脑上调试好好的，手机扫码预览就请求超时。原因是BASE_URL用的是127.0.0.1或localhost。解决：把BASE_URL改成电脑的局域网IP，并确保电脑防火墙放行8080端口。这条我最常遇到，每次帮人排查时项目里的URL基本都是localhost，一上真机必翻车。
6. 上线前强制走一遍的三处自查：改配置、验权限、真机测
毕业设计答辩前的技术检查，我建议你不要把时间花在调页面样式的边角上，按“数据能不能写进库、三个角色能不能登录、IP地址能不能换”这三步来。
第一，改数据库配置。用文本编辑器打开jdbc.properties或application.yml，把用户名、密码改成你本机的，同时确认连接URL里的库名和Navicat里建的一致。这一处改不对，后面所有页面都会因为数据库连接失败白屏。
第二，验三个角色的权限闭环。用管理员账号登录，在用户管理里新建一个测试用户；再建一个维修员账号；然后模拟用户下单、维修员接单、回填记录、用户评价的完整流程。核心验证点是状态流转：维修单从“待接单”变成“维修中”时，用户端能否同步看到状态变化。
第三，小程序真机预览一轮。用手机扫码后测以下路径：用户提交维修信息、维修员接单后修改状态、用户再次查看订单详情、管理员在后台看到统计数量变化。这里最容易暴露问题的是页面之间的跳转参数，比如维修单ID在页面跳转时丢参，导致详情页空白。
我之前帮人看项目时吃过一次亏：源码在一台电脑上调通了，换到另一台电脑演示时，才发现数据库密码被写死在多个配置文件里，只改了一处照样启动失败；从那以后我每次拿到类似的Java毕设包，都会先全局搜索一遍数据库密码和三处BASE_URL，确认没有遗漏才继续往下走。这个习惯帮我少翻了好几次车，希望帮到你。
本文还有配套的精品资源，点击获取
