企业官网建设流程全解析

简介：基于小程序的上门维修系统源码，是一套面向计算机相关专业毕业设计或课程设计的完整项目。系统包含前台用户、维修员和管理员三大模块：用户可管理维修信息、维修记录、评价与收藏；维修员可处理维修及评价；管理员则负责用户、维修员、维修信息、记录、评价、广告及系统管理等全流程功能。后端采用Java语言开发，搭配MySQL数据库，支持Tomcat部署，适合用户练习或二次开发。压缩包共1249个文件，容量约26.06MB，涵盖png/jpg图片资源、vue/js前端交互逻辑、wxml/wxss小程序页面、java后端代码、sql数据库脚本等，目录结构完整，便于按模块查阅和调试；目前已有121人学习/下载。资源包含完整前后端源码与数据库文件，同时附带环境配置说明（JDK1.8、MySQL5.7、Navicat、微信开发者工具等），从小程序端到后台管理均有清晰分层，能帮助读者快速理解上门维修业务的实现流程，并可作为毕设答辩或课程报告的有力支撑。

1. 先回答一个问题：这套上门维修小程序源码，拿来当毕设底子靠不靠谱

做上门维修系统毕业设计，最忌讳的是拿到一套源码却不知道它要表达什么。这套基于小程序的上门维修系统源码，包含了用户端、维修员端和管理员端三个完整角色：用户能报修、查记录、写评价、收藏；维修员能接单、回填维修记录、处理评价；管理员在 Vue 后台里管用户、维修员、广告和资讯。后端是 Java（JDK1.8 + Maven + Tomcat7），数据库是 MySQL5.7，小程序端可以用 HBuilderX 或微信开发者工具直接打开跑。我的判断是：它适合两类人——想快速搭出毕设框架后专心写论文的，以及课程设计想从三端分离架构里学点前后端配合的。下面我按拆包顺序，把目录结构、部署流程、业务闭环和踩坑点一次讲透。

2. 技术栈拆解：从 .bak 文件和 bat 脚本判断这套源码的真实结构

2.1 先看压缩包里到底有什么：三个工件的分工

解压这个 zip 之后，第一件事不是急着点 1-install.bat，而是先看文件清单。你会看到 main.css.bak、main.js.bak、update-password.vue.bak、IndexMain.vue.bak、IndexAsideStatic.vue.bak、BreadCrumbs.vue.bak、IndexHeader.vue.bak 这一串文件，另外还有 1-install.bat、2-run.bat、3-build.bat 三个批处理。这组文件放在一起，直接告诉你三件事。

第一，管理端是 Vue 技术栈。Index 开头的那几个 vue 文件对应的是后台管理页面的框架骨架：IndexAsideStatic.vue 是左侧静态菜单，IndexHeader.vue 是顶部导航栏，BreadCrumbs.vue 是面包屑，IndexMain.vue 是主内容区容器，update-password.vue 是修改密码页。这一套组合就是典型的 Vue 后台布局，菜单加头部加内容区，你改菜单项只需要改 IndexAsideStatic.vue 里的菜单数组。

第二，1-install.bat、2-run.bat、3-build.bat 是管理端的三个生命周期命令：安装依赖、启动开发服务、打包生产文件。也就是说管理端不是 JSP 那种后端直接输出的老式页面，而是独立的前后端分离工程。你得先让 Java 后端跑起来提供接口，再启动 Vue，浏览器里的后台才能有数据。

第三，那些 .bak 文件是作者做二次修改时的旧版本备份。比如 main.css.bak 是 main.css 的上一版，update-password.vue.bak 是修改密码页上一版。这种备份习惯在毕业设计源码里不多见，但对你自己二开来说很有用：改崩了直接把 .bak 后缀去掉覆盖回去就行，不用重新下载整个包。

后端这边再看环境要求：JDK1.8、Maven3.3、Tomcat7、MySQL5.7。这组环境比较老，但恰恰说明它是经典的 Java Web 组合。用 IDEA 导入时，如果 pom.xml 里是 spring-boot 依赖，那大概率能直接跑 Application 启动类；如果只有 Spring MVC + MyBatis 的坐标，那就得走传统 Tomcat 部署路线，配置 Artifact 把 war 包丢进 Tomcat 的 webapps 目录。我不建议你在这时候纠结用哪种框架，源码能跑通就行，毕业设计讲清楚业务逻辑比秀框架重要得多。

2.2 数据库表结构：一张表对应一个角色菜单

用 Navicat 导入数据库后（具体步骤第 3 章详说），里面至少可以看到这么几类核心表：用户表、维修员表、维修信息表、维修记录表、评价信息表、广告信息表、新闻资讯表，以及收藏相关的关联表。我把它们对应的业务场景整理成了下面这个对照关系：

这里建议你重点看维修信息表和维修记录表的关系。维修信息表可以理解成“工单主表”，用户填写的报修内容、期望上门时间、联系地址都存在这里；维修记录表是“执行表”，存放维修员到达时间、处理措施、材料费用。两张表用维修单号或用户 ID 关联。答辩时评委问“用户报修后进度怎么跟踪”，你直接把这两张表的状态字段拿出来讲：待接单、已接单、已完成、已评价，每个状态对应一个更新时间，一条完整链路就出来了。

权限设计上，用户端和维修员端虽然是同一个小程序工程里的不同入口，但后端接口层会做角色判断，登录成功后返回的 role 字段决定了你能访问哪些接口。管理员不掺和这个流程，只走 Vue 后台。这种设计的好处是前端代码量少，坏处是你联调时要特别留意请求头里带没带角色标识，后面第 5 章我会专门说这个坑。

2.3 为什么要理解 .bak 文件的开发习惯：版本回退的最省事方案

很多毕业设计源码不会留 .bak 文件，这套留了，说明作者在改新版功能时把旧版本单独存了一份。对你自己来说，保留这些备份是有价值的。比如你改完了管理端的主题颜色、改了侧边栏菜单的排序，结果发现改完页面错乱，这时候直接把 .bak 改名替换回去是恢复最快的。

我一般建议的做法是：拿到源码后先建一个干净的备份文件夹，把原始 zip 再解压一份当作“出厂状态”，所有改动都只动第二份。这样你反复改都不会把原始文件搞丢。另外，第一次跑通之前不要删任何 .bak 文件，因为你不知道它是不是启动逻辑里会用到的组件。

3. 把三端跑通：数据库导入、Tomcat 部署、小程序联调的完整命令

3.1 用 Navicat 导入数据库，并处理字符集和 SQL 版本问题

数据库这步是整套源码能不能跑起来的根。在 MySQL5.7 里新建一个数据库，名字可以叫 repair，字符集选 utf8mb4，排序规则选 utf8mb4_general_ci。然后拿 Navicat 11 的“运行 SQL 文件”功能把源码包里的 .sql 文件导进去。导入过程中你大概率会遇到两类问题，我一个个说。

第一类问题是字符集不兼容。假设你的 .sql 文件是从 MySQL8.0 环境导出的，文件头可能带 utf8mb4_0900_ai_ci，这个排序规则在 MySQL5.7 里直接不认识，Navicat 会报 1273 错误。解决办法是用编辑器打开 .sql 文件，全局替换 utf8mb4_0900_ai_ci 为 utf8mb4_general_ci，再重新导入。这是环境版本不一致造成的典型场景，我刚拿到这套源码时第一轮就栽在这上面。

第二类问题是建表顺序导致外键失败。如果导入时报“无法创建外键约束”，不要慌，在 .sql 文件最前面加一行SET FOREIGN_KEY_CHECKS=0;让 MySQL 跳过外键检查，导入完成后再恢复。导入成功后做一次验证，执行这段 SQL：

USE repair; SHOW TABLES; -- 预期能看到用户表、维修员表、维修信息表、维修记录表、评价信息表、广告信息表等

3.2 后端用 IDEA 导入：识别 Spring Boot 和传统 SSM 的两种启动方式

后端工程的导入我用的是 IDEA，Maven3.3 配 JDK1.8 是这套源码的基线。打开 IDEA 后选择 Import Project，定位到 Java 后端目录，选 pom.xml 作为 Maven 工程导入。第一次导入会花几分钟拉依赖，建议在 Maven 的 settings.xml 里把阿里云镜像配上，不然十几个依赖可能等十几分钟。

导入后先确认启动方式。如果项目里存在带有 @SpringBootApplication 注解的类，直接右键运行那个类的 main 方法，这是 Spring Boot 的方式，不需要单独装 Tomcat，内置容器就会在 8080 端口把服务顶起来。如果项目结构里有 webapp 目录和 web.xml，那是传统 SSM 或者 SpringMVC 单体的结构，需要手动配置 Tomcat7。

配置 Tomcat 的路径是 Run → Edit Configurations → 点加号 → Tomcat Server → Local，Application server 指向你本机解压的 Tomcat7 目录，Deployment 里添加 Artifact。启动前记得在 Tomcat 的 server.xml 里确认端口没被占用，我习惯把 HTTP 端口固定成 8080，如果被占就改成 8081，同时把小程序端的请求地址同步改掉。

启动成功的标志是控制台出现类似 “Tomcat started on port(s): 8080” 的日志。如果改成 Spring Boot 方式启动则会有生成长日志。此时浏览器访问 http://localhost:8080 能看到接口响应或默认欢迎页。啥页面都没有但接口能通，也说明后端是好的，重点是小程序端能不能请求通，下一节就讲这个。

3.3 小程序端用 HBuilderX 打开：请求地址、合法域名和跨域

小程序端我一般用 HBuilderX 打开，也可以用微信开发者工具。打开工程后先找到封装网络请求的文件，常见名字有 utils/request.js、api.js、http.js。里面的 baseURL 默认可能是别人的 ip 或域名，要改成你自己的本机地址。

// utils/request.js 中修改请求基础地址 const BASE_URL = 'http://localhost: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/x-www-form-urlencoded' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || '请求失败' }) } }, fail: (err) => reject(err) }) }) }

这段代码先定义接口基础地址，再封装 wx.request 成 Promise 方式，页面里可以直接用 async/await 调用。这里的 header 用的是表单格式，对应 Java 后端常见 @RequestParam 接收参数的方式。如果你拿到源码发现后端是用 @RequestBody 接收 JSON，那 header 要改成 'Content-Type': 'application/json'，并且 data 要序列化成字符串。前后端传参格式不匹配是最隐蔽的联调问题，接口报 200 但后端拿到的全是 null，这属于玄学表象下的技术问题。

微信开发者工具这里还有一个特定的限制：本地调试访问 http 接口会被拦。解决方法是在「详情 → 本地设置 → 街道不校验合法域名」前打勾。如果你要真机预览，上述设置就不生效了，你需要保证手机和电脑在同一局域网，然后把 baseURL 改成电脑的局域网 IP，例如 http://192.168.1.101:8080。要注意这是开发阶段的临时方案，正式上线必须用备案的域名配 HTTPS。

Vue 管理端这边，三个 bat 文件对应三条命令。1-install.bat 里的 npm install 可以手动执行，加个国内镜像源会更稳，然后是 npm run serve 启动开发服务。启动后控制台会给出一个本地访问地址，打开就能看到后台登录页。后台登录页面和后端接口之间如果遇到跨域请求被拦截，大概率是前端用了 axios 但没配代理，需要在 vue.config.js 里加 proxy 配置，把后端的 http://localhost:8080 指进去。源码里如果已经有 proxy 配置，你只需要把 target 地址换成自己的后端地址。

至此，数据库、Java 后端、小程序端、Vue 管理端四个部分全部跑通之后，整个系统的联调才算真正开始。

4. 维修工单的 7 个状态：从用户报修到评价闭环的数据流转

4.1 用户端报修：wx.request 到后端 Mapper 的调用链

用户端的核心操作是“提交报修”。用户在小程序首页或「我的」页面进入维修信息列表，点新增，填写问题描述、联系电话、上门地址、期望时间，提交后就是一个 POST 请求打向后端接口。这个接口一般叫 repair/add，对应 Controller 层的一个方法，经过 Service 层处理后，最终由 Mapper 层执行 INSERT 语句。为了让你对这条链路有直观概念，我来拆一段后端接口签名的典型写法：

@PostMapping("/repair/add") @ResponseBody public Result addRepair(@RequestParam("userId") Integer userId, @RequestParam("content") String content, @RequestParam("address") String address, @RequestParam("expectTime") String expectTime) { RepairInfo repair = new RepairInfo(); repair.setUserId(userId); repair.setContent(content); repair.setAddress(address); repair.setExpectTime(expectTime); repair.setStatus(0); // 0待接单 1已接单 2已完成 repairService.insert(repair); return Result.ok(); }

这段代码做了三件事：接收前端参数、封装实体、设置初始状态后插入数据库。注意 @RequestParam 对应的是上面 request.js 里表单格式的 header，如果你改过前端传参方式，这里要同步改。status 字段的初始值 0 很关键，它代表“待接单”状态。整条调用链不分页、不做校验，是典型的毕设级写法，但胜在链路完整，适合你画时序图。

4.2 维修员接单与回填：状态更新和事务边界

维修员登录后看到的是待接单工单列表。点接单的操作本质是一次 UPDATE，把维修信息表里对应工单的 status 从 0 改成 1，同时把当前维修员的 ID 写进工单的 maintainerId 字段。这两个更新操作必须放在同一个事务里，否则会出现“状态显示已接单但没绑定维修员”的脏数据。

维修员上门处理完问题后，进入「维修记录」页面填写处理结果。这里涉及主表和从表的两次写入：维修信息表状态改为 2（已完成），维修记录表新增一条记录，内容包括维修项目、费用、完成时间。主表管状态流转，从表管明细数据，这两张表通过工单 ID 关联。如果你要把数据设计写进论文，这种“一单一记录”的关系就是核心。

这里我想提醒你一个容易搞错的概念：维修信息表和维修记录表不是传统意义上的父子表，它们在状态上是并行的。维修记录一旦产生，维修信息的状态才允许改成已完成。很多同学画 E-R 图时把维修记录画成维修信息的子表向下延伸，严格说也不算错，但从业务实现来看，它们是按工单 ID 关联的同级表。答辩时如果被追问，直接回答“维修记录是对维修单的执行结果回填”，这个表述最准确。

4.3 管理员后台与评价管理：数据收口的关键模块

管理员通过 Vue 后台管理整个系统的数据入口。用户管理里可以禁用异常账号；维修员管理里能审核维修员账号或修改接单状态；维修信息管理和维修记录管理主要是查看和筛选；评价信息管理能删除不合适的内容；广告管理和资讯管理控制小程序首页展示的内容。

这里实现上最麻烦的是广告信息。小程序首页的广告位通常用轮播图或固定地址块展示，管理员在后台上传图片并配置跳转链接，小程序端通过一个 banner 接口拉取广告列表。广告图如果直接上传到本地服务器，会占 Tomcat 的磁盘空间，而且项目重启后经常出现图片路径失效的问题。常见做法是把图片放到项目 webapps 下的静态目录，或者直接存图片的 base64 字符串到数据库。源码里如果用的是本地路径，那你改数据时需要记得上传图片到对应目录，否则后台配置了广告名但小程序端只显示裂图。

评价信息管理是用户端和维修员端交互的收尾。用户对某次维修服务打分并填写文字评价，评价表中记录用户 ID、维修员 ID、维修单 ID、评分内容。管理员在后台能看到全部评价，必要时可以删除异常评价。这个模块是论文里体现“系统完整度”的一个亮点，因为它把用户、维修员、维修单三个实体关联到了一起。

4.4 时间字段与状态机：答辩时最能讲的“技术含量”

整套系统的核心状态流转可以概括成七个阶段：待接单 → 已接单 → 维修中 → 已完成 → 待评价 → 已评价 → 已关闭。虽然源码里的状态字段可能只写了 0、1、2 三个数字状态，但你在论文里可以用枚举或状态机图把它们展开写。时间字段分别落在维修信息表和维修记录表里：提交时间、期望时间、接单时间、完成时间、评价时间，这五个时间点足够画一张完整的业务时序图。

如果你想给源码增加一个不加页面也能体现能力的功能，建议加一个定时任务：每天凌晨扫描超过 24 小时未接单的工单，自动给管理员发站内提醒。具体做法是在启动类上加@EnableScheduling注解，然后写一个带@Scheduled(cron = "0 0 2 * * ?")的方法。这个改动不涉及页面和接口，只加一个类文件就行，但它的工程价值很高，能在答辩时展示出你对真实业务场景的理解。代码量不大，收益却很大，属于典型的花小钱办大事。

5. 避坑指南：复现这套上门维修源码最容易翻车的五个点

5.1 数据库导入报 1273 错误，字符集不兼容

现象：Navicat 执行 SQL 文件时报[Err] 1273 - Unknown collation: 'utf8mb4_0900_ai_ci'，导入过程中断。 原因：这个排序规则是 MySQL8.0 的新默认值，而本地 MySQL 是 5.7，根本不认识它。很多毕设源码的数据库是从 8.0 环境导出的，拿到 5.7 里直接用就会翻车。 解决：用 Notepad++ 或 VS Code 打开 .sql 文件，按 Ctrl+H 把 utf8mb4_0900_ai_ci 全部替换成 utf8mb4_general_ci，保存后重新导入。提醒一句，同步把文件里的 utf8mb4 字符集保留，不要改成 utf8，否则 Emoji 字符会乱码。

5.2 小程序请求 localhost 失败，被微信合法域名拦死

现象：小程序控制台报url not in domain list，所有网络请求全部失败，后端接口明明是通的。 原因：微信开发者工具默认只允许请求配置过的合法域名，localhost 本地调试地址属于开发期豁免项，但豁免开关默认是关着的。 解决：在微信开发者工具右上角点「详情」→「本地设置」→ 勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。如果你要做真机预览，这个开关不生效，必须把 baseURL 改成电脑的局域网 IP，并且让手机和电脑连同一个 Wi-Fi。小程序正式发布时，request 域名必须是备案过的 HTTPS 域名，和代码无关，是微信平台的硬性要求。

5.3 后端接口通了但页面没数据，控制台报 404

现象：Vue 管理端能打开登录页，但登录成功后所有列表都是空的，接口调试工具里请求后端路径返回 404。 原因：前后端分离项目最常见的路径不一致问题。Vue 的 axios 请求地址是 /dev-api/repair/list，但 Java 后端的实际接口路径是 /repair/list，少了前缀 proxy 代理没生效。 解决：打开 vue.config.js，检查 devServer.proxy 的配置。常见做法是把 target 改成 http://localhost:8080，并确保 axios 的 baseURL 是 /dev-api，这样开发环境下所有带 /dev-api 前缀的请求都会被代理转发到后端。原理是 Vue 开发服务器会把 /dev-api 前缀替换成 target 地址再转发，你只需要确认 rewrite 规则里的 ^/dev-api 被替换成了空字符串。

5.4 登录成功但角色权限不对，维修员看到用户菜单

现象：用维修员账号登录后，小程序端依然显示用户端的菜单和功能，比如能看到“我的收藏”，而维修员端没有这个功能。 原因：小程序端通常是同一套代码做多角色，菜单的显隐由本地缓存的 role 字段控制。如果登录接口返回的数据里没有 role 字段，或者前端拿到后没存缓存，菜单就会默认走用户端逻辑。后端虽然有接口权限拦截，但前端菜单控制是完全独立的，两者不同步。 解决：先在小程序开发者工具的 Storage 面板里查看登录后有没有存 userInfo、role 这类 key。没有的话，去登录接口的返回值里找角色字段，找到后在登录成功的回调里执行wx.setStorageSync('role', res.data.role)，然后在菜单渲染时加 if 判断。如果登录接口根本没返回角色，去后端去补这个字段。

5.5 npm install 老报错，node-sass 在 Windows 上编译失败

现象：执行 1-install.bat 或 npm install 时出现大量gyp ERR! stack Error: Can't find Python executable，安装无法继续。 原因：管理端 Vue 工程如果有 node-sass 依赖，它需要本地有 Python 和 C++ 编译工具链。很多 Windows 机器上根本没装这些，于是 npm install 在编译天然翻车。 解决：优先看 package.json 里的 node-sass 版本。老项目配新 Node 极易出错，建议安装 Node12 或 Node14。如果不想换 Node，可以在项目里把 node-sass 卸载掉，改用 sass 或 dart-sass，但这个过程很敏感，替换后可能还要改样式文件里的导入语法。我的一般习惯是看这个工程是否是纯开发模式，如果是，直接装对应 Node 版本最省事，python 路径可以放到环境变量里。

6. 答辩前夜：用演示数据和脚本把毕设讲到能过

距离答辩还有三五天时，功能代码基本定型，最能拉高印象分的是演示数据和演示脚本。我会做三件事。第一，在数据库里准备一套“看起来真实”的数据：5 个用户、3 个维修员、10 条维修工单、5 条评价记录，工单状态覆盖待接单、已接单、已完成、已评价四种，这样你点开任何列表都有内容可看。第二，把管理员后台的关键页面截图出来，按“菜单导航 + 列表页 + 编辑页 + 登记页”的顺序贴进论文，每张图配合一两句操作说明，比空讲功能完整度有说服力得多。

第三，准备一套 3 分钟的演示脚本。我通常按这个流程演：管理员在后台发布一条广告信息 → 用户端小程序首页出现这条广告 → 用户提交一个报修工单 → 维修员端看到待接单并接单 → 维修员回填维修记录 → 用户端确认完成并评价。每走一步，在数据库里都能对应到一条状态变更，评委问到哪一步你都能切到对应的页面。这套脚本走完，数据流、状态流、三端协作全部覆盖，基本挑不出大毛病。

如果你还有富余时间，可以在演示结束前加一个小小的加分动作：打开数据库图形化界面，现场把维修信息表里的 status 字段从 1 改成 2，刷新维修员端页面，状态同步变化。这个操作直观但不做作，能证明你对数据表和业务逻辑是真正理解，而不是照着稿子念。从那以后我每次拿到新的项目源码，第一步永远先看数据库表结构，把每张表对应的业务场景写在一张纸上，再去看代码和接口，这个顺序帮我躲开了很多“界面正常但数据对不上”的坑。希望这个习惯能帮到你的答辩。

愿你拿着这套源码，顺利把项目讲清楚，也拿到该拿的分数。

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