企业官网建设流程全解析

简介：一套面向微信小程序毕业设计的家用上门维修系统源码，整合Java后端、小程序前端和MySQL数据库，可直接作为计算机专业毕业设计、课程设计或小程序开发练手项目。系统分为用户、维修员、管理员三个角色：用户可在小程序端浏览首页、广告和新闻资讯，并管理自己的维修信息、维修记录、评价及收藏；维修员可查看和受理维修任务、填写维修记录并处理评价；管理员则在后台统一管理用户、维修员、维修信息、维修记录、评价、广告和系统设置。压缩包共1249个文件，大小26.02MB，主要包含vue/js前端逻辑、java后端代码、png/svg图标与页面素材、wxml/wxss小程序页面，以及sql数据库脚本等。已有87人学习，随附完整环境说明（JDK1.8、MySQL5.7、Tomcat7、微信开发者工具等），导入后即可运行调试。整套代码结构清晰，便于完成论文、答辩和二次功能扩展。

1. 微信小程序上门维修系统：一套 Java+MySQL 能跑的完整毕业设计

解压这份微信小程序上门维修系统源码包，第一眼看到的是满屏.vue.bak备份文件和1-install.bat这类 Windows 脚本，很多人会以为发错了资源。其实这正是 Java + MySQL 毕业设计最常见的交付形态：小程序端负责用户和维修员的操作入口，管理后台做数据兜底，后端按 SSM 的常见做法打包成 war 跑在 Tomcat 7 上。它解决的是「家里电器水管坏了找人上门修」的场景：用户发布维修需求，维修员接单并填写维修记录，用户再评价，管理员在后台管人和内容。适合做 Java 方向毕业设计、课程设计的学生，也适合想快速搭一套维修 O2O 演示项目的从业者。这套工程的核心价值是三端闭环完整，能让人在半小时内把论文里的功能描述变成可点击的页面。

2. 系统拆解：三个角色、三条业务线，数据先在数据库转一圈

上手一套新源码，第一件事不是急着配环境，而是先把三条角色线理清楚。这套系统的角色划分非常典型：用户负责发起，维修员负责执行，管理员负责兜底。三条线共享同一批业务表，但每个角色看到的菜单和操作权限完全不同。读源码时你会发现，小程序端三个 tab 页面反复出现「我的」入口，真正的差异都在登录后的数据过滤条件里——用户只查自己发布的报修，维修员只查自己接的单，管理员则是全量列表加删除权限。

2.1 用户端：首页、资讯、我的，维修从这里发起

用户端是小程序里页面最多的部分。首页展示广告轮播、新闻资讯和快捷入口，广告信息由管理员在后台维护，对应的是ad相关表；新闻资讯则是固定栏目，通常挂在后端的资讯管理里。用户在「我的」页面能进入维修信息管理，把自己的维修需求填成一张报修单：故障类型、联系人、地址、期望时间，这些字段会落进维修信息表，状态默认是「待接单」。

这里最容易混淆的是「维修信息」和「维修记录」两张表。维修信息描述的是需求本身，维修员一旦接单，系统才生成对应的维修记录，记录里写入上门时间、维修内容、更换配件、收费金额这些执行层面的数据。用户端还包含我的收藏，收藏对象是资讯或广告位里的商品，这一块单独建关联表，和维修业务不耦合，二次开发时可以直接抽走复用。

2.2 维修员端：接单之后，维修记录才是关键资产

维修员端同样有首页、广告、资讯、我的四个入口，但业务重心完全不同。维修员看到的维修信息列表是所有待接单的报修单，接单动作本质上是一次状态流转：把维修信息表里的status从待接单改成已接单，同时在建维修记录表插一行记录。这个设计比「单独建一张订单表」更贴合上门维修的场景，因为一次报修可能被多个维修员查看，但最终只有一个接单人。

维修记录表是整套系统的核心资产。它至少应该包含维修员 ID、维修信息 ID、维修内容、材料费、人工费、维修时间、完成状态这几个字段。论文里描述「维修记录管理」，实际看的就是这张表的增删改查。评价信息表再挂到维修记录上，用户完成维修后打分写评语，评价状态默认对外可见，管理员在后台可以隐藏违规评价。从数据库表数量上估算，这套工程大概有八到十张表，属于本科毕业设计里最舒服的量级——不多到讲不清，也不少到撑不起章节。

2.3 管理员端：账号、内容、评价，系统闭环的兜底

管理后台承担的是传统后台管理功能，用户管理、维修员管理、维修信息、维修记录、评价信息、广告信息、系统管理七大模块，对应一份典型的管理员权限清单。它在业务上只做一件事：保证前端流转的所有数据都是可控的、可审核的、可删除的。比如用户投诉某条评价不实，管理员可以直接在评价信息管理里下线；广告位要换活动图，也不用改小程序代码，后台传一张图就行。

从代码位置看，管理员端是独立的 Vue 工程，和两个小程序端不公用代码，只共用后端接口。打开压缩包看到的IndexMain.vue.bak、IndexAsideStatic.vue.bak、BreadCrumbs.vue.bak这套文件，是典型的 Vue 管理后台骨架，侧边栏、顶栏、面包屑、主内容区四件套齐全。理解了这个结构，你就能明白为什么压缩包里既有小程序代码又有管理后台代码，还配了一个 Java 后端——三条业务线、三份前端代码、一套 API，这就是整套系统的基本盘。

3. 技术栈与工程结构：SSM 后端、小程序前端与 Vue 管理后台分别是什么

3.1 为什么是 JDK1.8 + MySQL5.7 + Tomcat7：这套老组合的选型逻辑

这套系统的环境组合是 JDK 1.8、MySQL 5.7、Tomcat 7、Maven 3.3，数据库工具用 Navicat 11。乍看全是老版本，但这个组合恰恰是近几年 Java 毕业设计里最稳的搭配，没有之一。原因有三点：第一，JDK 1.8 是目前几乎所有 SSM 教程和开源项目的基准版本，网上随便搜到的报错解决方案都基于它，换成 JDK 11 以上反而会遇到老框架反射警告；第二，MySQL 5.7 和 Navicat 11 的匹配度最好，Navicat 11 连 MySQL 8.0 经常出现 caching_sha2_password 认证插件不兼容，连 5.7 则是完全免配置；第三，Tomcat 7 配 JDK 1.8 是经典组合，容器轻、启动快、报错信息直白。

后端框架层面，这套工程没有用 Spring Boot，而是走了传统的 SSM 路线。区分方法很简单：Spring Boot 打成 jar 包直接java -jar跑，只有传统 SSM 项目才会打 war 包丢进 Tomcat 的 webapps 目录。为什么会选 SSM？因为毕业设计答辩要讲原理，Spring、Spring MVC、MyBatis 三件套每一层都能拆出独立章节，比 Spring Boot 的「自动配置」更适合展示掌握度。从技术学习角度看，这份源码的价值也恰恰在它够传统，Controller、Service、Mapper 三层结构清晰，能让你把「请求怎么进来、SQL 怎么执行、结果怎么返回」这条链路完整读一遍。

3.2 后端 SSM 工程：Controller、Service、Mapper 三层去哪找

后端工程解压后是标准 Maven 目录。src/main/java下面按业务模块分包，常见做法是 controller、service、mapper、entity 四个包，entity 里是对应数据库表的实体类，controller 层用@RestController暴露 JSON 接口给小程序调用。src/main/resources里放着 Spring 配置文件、MyBatis 映射文件和数据库连接配置，数据库的连接信息在一个 properties 文件里，包含 URL、用户名、密码，这是部署时要第一个改动的地方。

MyBatis 的 SQL 都写在 mapper 包对应的 XML 文件里，这是排查业务逻辑最关键的入口。接口层只定义方法名，真正执行的 SQL 语句全部集中在 XML 里。比如查询某个用户的所有维修信息，你要改的是 Mapper XML 里的select语句；要加一个按故障类型筛选的功能，也是在 XML 里加动态 SQL。注意实体类的属性命名和数据库字段的映射，常见配置是开启驼峰转换，数据库下划线字段repair_time会自动对应实体的repairTime，这个机制决定了你写 SQL 返回到实体时不能瞎起别名。

3.3 小程序与 Vue 管理后台：一套压缩包里两套前端

小程序端是这套系统的第一入口。项目说明里写了 HBuilderX 或微信开发者工具都能打开，说明小程序端是基于 uni-app 或其兼容写法交付的。工程结构里至少会有pages（页面目录）、utils（请求封装）、static（静态资源）三个核心目录。接口请求一般统一封装在 utils 下的 request 文件里，baseURL指向后端地址，你在微信开发者工具里打开工程后，第一件要改的事就是把这个地址从开发机的 localhost 换成你自己的。

管理后台则是另一套 Vue 工程，操作入口就是压缩包里那三个 bat 脚本：1-install.bat执行 npm install 装依赖，2-run.bat启动开发服务，3-build.bat打包上线。至于那一堆.vue.bak文件，它们是开发时改版留下的备份文件，.bak后缀意味着「这个文件不参与编译，只是留着后悔药」，真正生效的是没有.bak后缀的同名文件。千万别把.bak改名成.vue放回工程里，那样会导致重复定义组件，构建直接报错。

4. 部署实操：从 JDK 1.8 到 Tomcat 7，把三端跑起来的完整命令

4.1 环境清单：版本对齐，一个都别乱改

部署这套工程之前，先把环境按下面的表对齐，版本偏差是最大的隐形杀手：

这里要特别提醒：如果电脑上已经装了 MySQL 8.0，又要跑这套 5.7 的 sql 脚本，最省事的办法不是降级数据库，而是新建一个独立 MySQL 实例或者用 Docker 起一个 5.7 容器。直接把 5.7 的 sql 导入 8.0 不是不能跑，但你会在字符集和 sql_mode 上消耗大量时间，这对复现项目没有任何帮助。

4.2 数据库导入：先建库，再导 sql，字符集选 utf8mb4

压缩包的数据库文件在根目录，文件名类似xxx.sql（以实际压缩包为准）。导入之前必须先手动创建数据库，因为 sql 脚本里通常不包含CREATE DATABASE语句，直接用 Navicat 导入会报Unknown database。打开命令行，执行下面的命令：

mysql -uroot -p123456 -e "CREATE DATABASE IF NOT EXISTS repair_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -uroot -p123456 repair_system < D:/repair_system.sql

第一行先建库，IF NOT EXISTS防止重复执行报错，字符集指定utf8mb4而不是utf8，因为小程序端提交的用户昵称可能带 Emoji，只有 utf8mb4 能存。第二行把 sql 文件导入刚建的库，<是命令行重定向，把文件内容喂给 mysql 客户端。如果你更习惯图形界面，在 Navicat 里右键连接 → 新建数据库 → 字符集选 utf8mb4 → 双击打开数据库 → 右键运行 SQL 文件，效果完全一样。

导入完成后，至少能看到用户表、维修员表、维修信息表、维修记录表、评价信息表、广告信息表、资讯表、收藏表这几张核心表。你可以先在用户表里查一下有没有初始账号，很多毕业设计工程会内置一条admin记录，这决定了你第一次登录后台用什么账号。

4.3 后端部署：Maven 打包与 Tomcat 启动

后端工程用 IDEA 或 Eclipse 打开都可以，但强烈建议走命令行先验证工程能否编译通过。在工程根目录打开命令行，执行：

mvn clean package -DskipTests

clean清掉上次编译的残留，package执行打包流程，-DskipTests跳过测试用例，避免因为环境差异导致测试失败中断打包。打包完成后，target目录下会生成一个war文件，文件名字就是后端接口的上下文路径，比如 war 包叫repair-system.war，那启动后接口根地址就是http://localhost:8080/repair-system/。

把 war 文件复制到 Tomcat 的 webapps 目录，然后双击bin/startup.bat启动。Tomcat 启动后会自动解压 war 包，你可以在浏览器直接访问：

http://localhost:8080/repair-system/api/ping

如果这个地址有响应，说明后端已经起来了。Tomcat 默认端口是 8080，如果你本机已经装了别的服务占用 8080，改 Tomcat 的conf/server.xml，把Connector节点的port改成 8081，小程序端的baseURL也要同步改。

4.4 小程序端运行：工具导入、改接口地址与编译

打开微信开发者工具，选择「导入项目」，目录选到小程序端那一层（能直接看到pages目录的那个文件夹），AppID 可以选测试号。导入成功后，先打开utils/request.js或项目里封装的接口文件，把baseURL改成你的后端地址：

// utils/request.js const BASE_URL = 'http://127.0.0.1:8080/repair-system'; // 真机调试时改成局域网 IP

这段代码是把所有接口请求的公共前缀抽到一个常量里，后端地址一改，全项目接口自动生效。在开发者工具里初次编译，大概率会遇到request:fail或不在以下合法域名列表中的报错，这是微信的域名校验机制。本地调试最省事的方式是点开发者工具右上角「详情」→「本地设置」→勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。注意这是调试期做法，正式发布必须换成备案过的 HTTPS 域名。

真机预览是另一套逻辑。手机和小电脑要在同一个局域网，把BASE_URL里的127.0.0.1换成电脑的局域网 IP，比如192.168.1.100:8080，同时关闭电脑防火墙或者允许 Java 进程通过。这一步是毕业设计演示现场翻车的高发区，建议提前在答辩教室用自己的手机连热点试一遍。

5. 避坑手册：五个能让评审现场翻车的问题

5.1 小程序端一直 request fail：问题可能不在代码

现象：微信开发者工具编译成功，页面正常渲染，但所有列表都是空的，控制台报request:fail，或者点击登录后没有任何反应。原因：小程序是互联网应用，默认只允许请求 HTTPS 域名，本机的http://127.0.0.1不是合法域名，微信校验直接拦截；真机预览时更是如此，手机上的127.0.0.1指向手机自己而不是电脑。解决：开发者工具里勾选「不校验合法域名」，真机调试时把接口地址改成电脑的局域网 IP，并确认后端监听端口没有被防火墙拦。这三步按顺序走一遍能解决九成以上的连接问题。

5.2 个人主体小程序调用 getPhoneNumber 获取手机号失败

现象：点击微信手机号快捷登录，回调里的errCode是40001，拿不到用户手机号。原因：微信官方规定，getPhoneNumber手机号快速验证组件仅对企业主体开放，个人主体小程序调用会直接报错。这一点对个人开发者极其不友好，很多教程不会提前说。解决：毕业设计里最常见的做法是改用wx.login获取 code，由后端调微信接口换 openid，用 openid 作为用户唯一标识，手机号做成选填逻辑由用户手动输入。这套降级方案不依赖企业认证，演示效果也不打折。

5.3 管理后台 npm install 报 OpenSSL 错误

现象：双击1-install.bat安装依赖，控制台输出digital envelope routines::unsupported，Node.js 直接退出。原因：老 Vue 项目基于 webpack 4，它依赖的 OpenSSL 算法和新版 Node.js（17 以上）不兼容。解决：两个办法，一是安装 Node 14 或 16 并用它来跑这个项目，二是保留高版本 Node，在命令行设置兼容参数：

set NODE_OPTIONS=--openssl-legacy-provider npm run serve

NODE_OPTIONS是 Node 运行时参数，--openssl-legacy-provider会切回旧版 OpenSSL 提供器，webpack 4 就能正常编译。这个参数不适合生产构建，只用于本地开发调试。

5.4 数据库导入报 Unknown database 或中文乱码

现象：Navicat 直接运行 sql 文件，第一步就报Unknown database；或者导入成功，但小程序里显示的中文全是问号。原因：sql 脚本里的USE语句通常被注释掉了，脚本不知道要往哪个库导，属于「建库漏了」；乱码则是导入连接选了默认的latin1字符集，中文存进去就成了问号。解决：先手动建库再导 sql，建库语句里显式声明DEFAULT CHARACTER SET utf8mb4，导入时在 Navicat 的「高级」选项里把字符集选成65001 (UTF-8)。如果已经导乱了，删库重建再导一次，比手动改数据稳得多。

5.5 Tomcat 启动不了：8080 端口被占用

现象：双击startup.bat后黑窗口一闪而过，浏览器访问localhost:8080完全没有响应，查看日志报Failed to initialize end point associated with ProtocolHandler ["http-bio-8080"]。原因：8080 端口被其他程序占用，Tomcat 绑定失败。解决：先看谁占了端口：

netstat -ano | findstr 8080 taskkill /PID 4456 /F

netstat查出占用 8080 的 PID，taskkill强制结束对应进程。如果你装的开发软件里有别的服务固定占 8080，或者干脆不想杀进程，就改 Tomcat 的conf/server.xml，把端口挪到 8081。改完记得同步小程序端的BASE_URL，否则后端地址全对不上。

6. 进阶：闭环验证清单与导航栏适配的两个落点

6.1 按角色跑一遍闭环验证

拿到一套能跑的源码后，不要一上来就改代码，先按三条业务线把闭环走通，确认数据在表之间流转正常。我的习惯是准备一个临时账号，按下面的清单逐项验证：

这一套走下来，论文里的功能描述就全部落到真实数据上了。验证过程中多留意列表页的数据过滤条件：用户端只能看到自己的报修单，维修员端只能看到未接单的报修单，这些条件都写在对应查询 SQL 的where里，是你答辩时最能讲出细节的地方。

6.2 自定义导航栏高度适配与二次开发落点

小程序端要兼容不同机型的顶部状态栏高度，如果你在源码里看到写死44px的导航栏样式，建议改成动态计算。微信小程序的胶囊按钮位置是获取适配参数的最佳锚点：

const menuBtn = uni.getMenuButtonBoundingClientRect(); const sysInfo = uni.getSystemInfoSync(); const navBarHeight = menuBtn.height + (menuBtn.top - sysInfo.statusBarHeight) * 2 + sysInfo.statusBarHeight;

这段代码先拿胶囊按钮的宽高和位置，再拿系统状态栏高度，两者相减再乘 2，得到胶囊上下各留的间距，最后加上按钮自身高度，就是自定义导航栏的总高度。statusBarHeight在 Android 和 iOS 上数值不同，这套计算方式能让顶部区域在不同机型上保持一致，是面试里很加分的细节。

二次开发想加新功能时，优先看两个落点：后端 Mapper 的 XML 文件里加自定义查询，然后在对应 Controller 补一个接口方法；小程序端在pages下复制一个现有页面结构，改模板内容并新增接口请求。这份源码的页面组件是拆开的，IndexMain、IndexHeader都是独立文件，改一套界面样式不会波及业务代码，这也是它适合作为毕设底稿的原因。从那以后我每次拿到这种三端项目，都强制先走一遍角色闭环验证，再动任何代码，这个习惯帮我躲过了至少三次答辩现场的尴尬，希望帮到你。

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