企业官网建设流程全解析

简介：面向毕业设计学生的微信小程序家政项目完整源码包，基于Java后端+微信小程序前端+MySQL数据库架构，覆盖管理员后台与用户端完整业务闭环。管理员可管理个人中心、用户、家政人员、家政服务、咨询信息与回复、家政预约、留言板及系统配置；用户端支持在线咨询和预约家政人员，适合学习完整前后端交互流程并直接二次开发。资源共1212个文件，16.27MB，包含119个Java后端源码、134个Vue管理端页面、175个JavaScript逻辑文件、86个WXML与88个WXSS微信小程序页面文件，另有JSON配置、PNG图标、SQL数据库脚本和部署脚本，目录结构完整、环境说明清晰，可按文档在eclipse/IDEA、Tomcat7及微信开发者工具中运行。已有67人学习浏览，可用于课设/毕设演示与答辩。从中可掌握Java接口开发、MySQL表设计、小程序页面渲染与管理端Vue组织方式，为快速搭建家政服务类项目提供完整参考。

1. 家政毕设小程序到底能给你什么：先搞清楚它是不是你要的那个

每年毕业设计旺季，总会有人拿着“微信小程序毕业设计：家政项目小程序源码（java+小程序+mysql+LW）.zip”来问：这能不能跑？这个包对应完整的三层结构：微信小程序做前端，Java 提供接口，MySQL 存数据，LW 目录里装论文和答辩材料。对相关专业同学来说，最大价值不是抄代码，而是把前端、后端、数据库、文档一次配齐，短时间内就有能完整演示的系统。

但拿到包和跑起来是两回事。家政项目看着只是下单、派单、评价，实际要处理三个角色和订单完整生命周期，这正是答辩评委最爱追问的地方。如果只会点“编译”，后端起不来、数据库没导入、接口全超时，答辩就是翻车现场。接下来按启动顺序，把落地路径、坑位和亮点一次讲清楚。

2. 把技术账算明白：Java + 小程序 + MySQL 的选型和项目骨架

“跑通”这件事，八成的成败在拿到压缩包的第一个小时。家政项目看起来只是几个页面，但它要同时支撑用户下单、家政员接单、管理员核单三个角色，任何一个环节脱节，整个系统就立不住。这一章先把选型逻辑讲清楚，再讲启动顺序，最后落到后端怎么从零跑通。

2.1 为什么这个项目偏偏是 Java + 原生小程序 + MySQL

先回到业务本身。家政服务的核心链路是：用户选服务、提交预约、家政员接单、上门服务、回填结果、用户评价。这条链路决定了系统最少要有用户表、服务表、订单表、家政员表，以及围绕订单状态的一组枚举。小程序端要服务的是 C 端用户，后端要管的是 B 端流程，数据库要保证订单数据不丢，三者天然形成前后端分离结构。

Java 在一众后端语言里，几乎是毕业设计最保险的选择。学校开这门课，就业市场也认这个栈，答辩评委闭着眼睛都能接住。具体到实现方式，现在大多数源码已经站在 Spring Boot 这一代，而不是十年前的 SSM 手动配置。Spring Boot 内置 Tomcat，开发阶段一个 mvn spring-boot:run 就能把服务拉起来，不需要额外部署 war 包；配上 MyBatis 操作数据库，SQL 写在 mapper 文件里，答辩被问到“这条数据怎么查出来的”，直接把 mapper 翻出来讲就行，比在 Service 里拼 JDBC 清晰得多。

为什么不用更“高级”的中间件？这是我要泼冷水的地方。有些同学拿到源码第一反应是要不要加 Redis 缓存订单列表、用消息队列做派单，我会反问一句：你这个系统的并发是多少？单机演示场景下，Redis 和 MQ 带来的不是加分，而是答辩时一串答不上来的追问。毕设选型的原则是能完整演示、能清楚解释，技术栈不是越杂越好。家政项目单应用、单数据库的架构，恰恰是它作为毕设最成熟的形态。

MySQL 则是这一整套里最不需要纠结的环节：免费、课设必教、可视化工具多。真正要注意的是建表和字符集。订单、用户、服务项这三张核心表必须单独建，索引可以先不加，但外键关系要能在 ER 图里说清楚；字符集建议直接上 utf8mb4，家政场景里的地址备注、用户昵称可能带表情符号，老 utf8 存 4 字节字符会报错或变问号。

2.2 拿到 .zip 别急着解压：目录结构、脚本与启动顺序的“约定”

解压之后，我会先花十分钟做一次“目录巡游”，而不是直接点开 README 就冲。常见的结构是四块：小程序前端目录、Java 后端工程目录、SQL 脚本，再加上 LW（论文/文档）目录。LW 目录我会第一个打开，因为里面一般会有任务书、开题报告、论文正文和答辩 PPT 的框架，它决定了你要不要改代码、改哪里。先读文档再动代码，省掉的不是十分钟，是半天。

后端工程内部，真正决定能不能启动的就三处：

这三处往往就是启动命令本身。很多人跑来问“启动失败”，我让他把这三样截图发过来，问题基本当场定位：不是密码写错，就是 SQL 没导入，再不然是 pom 里依赖版本和本地 JDK 对不上。所以拿到包之后，第一步不是点运行，而是先确认这三样是不是和你的环境一致。

启动顺序也有一套约定：建库导数据、启动 Java 服务、打开微信开发者工具。反着来必出问题——有人先把小程序跑起来，页面空白就以为是前端代码坏了，查了半天，其实是后端服务没起，所有请求都在超时。记住，小程序只是装了 UI 的空壳，所有数据都靠请求后端喂。

2.3 后端从零跑通：建库、配库、启服务、验接口一步不缺

现在开始动手。先建库导数据，以本地常见的 MySQL 5.7/8.0 为例，命令行操作最直接：

# 创建数据库，执行后会提示输入 root 密码 mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS home_service DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" # 导入 SQL 脚本，路径换成你解压出来的 .sql 实际位置 mysql -u root -p home_service < ~/Desktop/home_service.sql

这个 CREATE DATABASE 的字符集参数不要省略。家政项目里用户昵称、服务备注都可能是 4 字节字符，utf8mb4 才是完整支持表情符号的字符集；如果脚本建的表不是这个字符集，导入时要么报错，要么数据变成乱码问号。顺手用 SHOW TABLES; 看一眼表数量，前后对得上再走下一步。

接着改后端连接。Spring Boot 的配置集中在 application.yml（也可能是 application.properties），我一般只动三个地方：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/home_service?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.homeservice.entity

url 里最怕删掉 serverTimezone。MySQL 8.x 驱动默认走 UTC，不指定时区，启动时报时区异常会让你误判成配置问题。driver-class-name 跟着你的 MySQL 版本走：8.x 用 com.mysql.cj.jdbc.Driver，老版本 mysql-connector-java 5.x 需要换成 com.mysql.jdbc.Driver，这个改错，启动直接 ClassNotFoundException。

启动后端现在很轻：

# 在工程根目录执行，首次运行会拉依赖，耐心等 mvn spring-boot:run

首次运行要是卡在依赖下载，大概率是 Maven 仓库源不通，解决方法是去本地 settings.xml 里换国内镜像仓库，不是换工程代码。看到类似 Started Application in xx seconds 的日志，服务就起来了。验证接口不要等前端，直接用 curl 打一发：

curl -X POST http://localhost:8080/api/user/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}'

如果返回 JSON 里带 token 或 userId，后端链路就通了。返回 404 说明接口路径不是这个，去后端 Controller 里搜 @PostMapping 看真实路径；返回 500 就看后端控制台红色堆栈，最常见的还是 SQL 或数据库连接问题。到这里，“建库、配库、启服务、验接口”四步闭环，后端才算真正可用。

3. 家政小程序前端与后端握手：从登录到预约下单的关键链路

后端通了，真正的活才刚开始。小程序端要做的不是写死几个静态页面，而是把后端接口组织成一套可复用的调用链。这一章从请求封装、订单状态机、联调排查三个角度，讲清楚小程序是怎么“活”起来的。

3.1 页面骨架与统一请求封装：先让所有接口走同一个出口

打开小程序工程，pages 目录下通常按业务拆页：首页、服务列表、服务详情、下单确认、订单列表、我的、登录。目录怎么命名不重要，重要的是这些页面不能各自为战。每个页面都裸写 wx.request 的话，换一次后端地址就要改几十个文件。我拿到工程的第一件事，就是去看有没有一个统一的 request 工具，没有就自己补一个。

// utils/request.js const BASE_URL = 'http://localhost:8080/api'; 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', 'Authorization': wx.getStorageSync('token') || '' }, success: (res) => { // 按后端统一返回结构 { code, message, data } 处理 if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data); } else if (res.statusCode === 401) { // 登录态失效，清 token 回登录页 wx.removeStorageSync('token'); wx.reLaunch({ url: '/pages/login/login' }); reject(new Error('登录已过期')); } else { wx.showToast({ title: res.data.message || '请求失败', icon: 'none' }); reject(res.data); } }, fail: (err) => { // fail 通常是网络层：后端没启、IP 不对、域名没配 wx.showToast({ title: '网络异常，请检查后端服务', icon: 'none' }); reject(err); } }); }); } module.exports = { request, BASE_URL };

这里有几个约定先要说明：BASE_URL 在开发者工具里填 localhost 没问题，但真机预览时要把 localhost 换成电脑的局域网 IP，原因后面排查章节会展开。Authorization 头从本地存储里取 token，这是大多数毕设后端的通用做法，后端用拦截器校验，取不到就返回 401。如果后端的返回结构不是 { code, message, data }，而是直接返回业务对象，那 success 里的判空逻辑就要跟着调——先看后端 Controller 的返回类型再改封装，别硬套。

封装的好处是，页面里调用接口变得很薄，比如登录页：

// pages/login/login.js const { request } = require('../../utils/request.js'); Page({ async handleLogin(e) { const { username, password } = e.detail.value; try { const data = await request('/user/login', 'POST', { username, password }); wx.setStorageSync('token', data.token); wx.setStorageSync('userInfo', data.userInfo); wx.switchTab({ url: '/pages/index/index' }); } catch (err) { console.error('登录失败', err); } } });

只要封装层稳定，页面里基本不会出现第二处 wx.request，这就是“统一出口”的价值：出问题只查一个文件，而不是翻遍整个 pages。

3.2 预约→派单→服务→完成：订单状态机怎么串起三个角色

家政项目最值得写进论文的，不是页面多漂亮，而是订单状态的设计。一张订单从创建到结束，至少要经过这几个状态：

这个状态机最好在前后端各维护一份枚举，后端是真正的裁判，前端只是展示。很多人图省事，在小程序里用 if 写“订单状态显示什么按钮”，后端更新订单时却直接 UPDATE status = 新状态，没有任何前置校验，这就是“状态串台”的根源——两个操作员同时操作同一张单，后执行的覆盖先执行的。

我一般会在后端的更新 SQL 里加一个前置状态条件，这就是个简单的乐观锁：

<!-- 接单操作：只有待接单的订单才能被置为待服务 --> <update id="acceptOrder"> UPDATE t_order SET status = #{newStatus}, update_time = NOW() WHERE id = #{orderId} AND status = #{oldStatus} </update>

oldStatus 从当前订单查出来传进去，如果 UPDATE 影响行数为 0，说明订单已经被别人处理，这时候直接返回“该订单已被接单”。这一条代码，答辩时往“并发控制”上引，效果比你多写两个页面好得多。前端的按钮显示逻辑也要跟着状态字典走，我习惯在 utils/status.js 里放一份映射，而不是在 wxml 里堆一堆 wx:if。

3.3 联调验证：接口没通的时候，先看这五个位置

页面写好了，接口也调了，结果还是白屏、报错、没反应，这种情况我一般按下面五步排查，基本能在五分钟内定位：

第一，打开微信开发者工具的 Network 面板，看请求有没有发出去。如果 request 列表里根本没有这条记录，说明代码逻辑没走到这一步，前端断点打上先查；如果有记录但标红，点开看 statusCode。

第二，看状态码。200 但页面没数据，多半是后端返回结构和封装层没对齐；401 就是 token 失效或没带 Authorization 头；404 是接口路径不对；500 是后端运行时异常。记住，前端看到的 500 永远只是结果，真正原因在后端控制台。

第三，看 BASE_URL。开发者工具里 localhost 能通，真机预览百分之百失败，因为手机上的 localhost 指的是手机自己。这时候把 BASE_URL 改成电脑局域网 IP，例如 http://192.168.1.5:8080/api，手机和电脑连同一个 Wi-Fi。上线则必须走备案域名加 HTTPS，开发阶段可以在开发者工具里勾选“不校验合法域名”跳过检查。

第四，看数据层级。很多后端返回的是 { code, data: { list: [] } } 两层嵌套，前端拿 data.data 还是 data.data.list，少一层就是 undefined，页面渲染出来全是空白。加一行 console.log 看真实结构，再对症下药。

第五，看数据库。下单接口调用成功，但订单列表查不到，别急着改前端，先去数据库 SELECT * FROM t_order WHERE user_id = ?;。数据没落库，问题在后端事务没提交；落了库但列表查不到，再查查询条件参数。接口、代码、库三层，总有一层能揪出问题。

4. 避坑记录：家政毕设跑不起来，九成卡在这几处

这一章集中写调试期最值得写进避坑笔记的几个问题，按环境类和功能类分开，每条按现象、原因、解决三件事说清楚。

4.1 环境类问题：数据库连不上、端口被占、依赖拉不下来

现象一：后端启动报 Access denied for user，或者 Communications link failure。原因：application.yml 里的数据库账号密码和本地不一致，或者 SQL 脚本还没导入，数据库里压根没有 home_service 这个库。解决：先用命令行手动连一次库，mysql -u root -p，能进去再核对库名；账号密码改对之后重试。这类报错指向非常明显，别急着去翻代码，八成是配置没对上。

现象二：Tomcat 启动到一半直接退出，控制台写着 Port 8080 was already in use。原因：本地某个进程占了 8080。解决：两个方向，要么杀掉占用进程，要么改 server.port 换成 8081 或 9090。我习惯顺手改配置而不是去杀进程，毕竟你也不知道占端口的那个程序是不是正在用的。改完端口，记着小程序那边的 BASE_URL 也要同步改，漏了就是另一个玄学问题。

现象三：mvn spring-boot:run 启动后长时间卡在 Downloading，或者直接报无法解析依赖。原因：Maven 默认中央仓库在国内访问不稳定，依赖拉不下来。解决：找到 Maven 安装目录 conf/settings.xml，把 mirror 指向国内镜像仓库，这个动作只需要改一次，之后所有工程都受益。改完重启终端再试，基本能解决。

现象四：开发者工具报“url not in domain list”或“不在合法域名列表中”。原因：小程序平台安全策略，默认只允许请求已备案的 https 域名。解决：开发调试阶段，在开发者工具右上角“详情→本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，然后重新编译。注意这只是本地调试开关，上传体验版时真机还是要配 https 域名，除非你开了调试模式。

4.2 功能类问题：登录反复失效、订单状态串台、真机请求失败

现象五：小程序登录成功后，过几分钟又自动跳回登录页。原因：后端返回的 token 有效期太短，或者后端每次重启都重新生成签名密钥，旧 token 直接失效。解决：两个思路，一是把后端的 token 过期时间调长，比如 7 天；二是检查前端有没有在请求头正确带 Authorization。如果重启后立竿见影地全部失效，那多半是后端把 token 存在了内存里而不是用固定密钥签名，毕设项目建议用固定密钥签名，重启不掉线，答辩演示更稳。

现象六：两个家政员同时点接单，都被提示成功，但订单状态和操作人不一致。原因：后端更新订单时只写了 UPDATE SET status = 新状态，没有 WHERE 条件限制旧状态。解决：用前面写的乐观锁 SQL，更新时带上 AND status = #{oldStatus}，更新行数为 0 就返回失败。这一条不仅是避坑，还是答辩时的“并发控制”加分点。

现象七：真机预览时，首页能打开，但列表永远加载中。原因：BASE_URL 还是 localhost，手机访问到的是自己，后端根本连不上。解决：把 BASE_URL 改成电脑的局域网 IP，例如 http://192.168.1.5:8080/api；同时确认手机和电脑在同一 Wi-Fi 下，防火墙允许 8080 端口放行。Windows 上记得检查防火墙弹窗有没有允许 Java 进程，不然手机还是访问不了。

现象八：页面空白不报错，控制台只有一个 undefined is not a function。原因：后端返回的数据结构和前端预期不一致，常见于数组和对象搞混，比如 orderList 实际是个对象不是数组，页面 for 循环直接爆炸。解决：在 onLoad 里 console.log(this.data.orderList)，对照 Network 面板返回的 JSON，把数据拆到正确的层级再赋值。

以上问题有一个共同点：错误信息其实已经在控制台里写得很明白，只是着急的时候不看。调试的第一步永远是读日志，不是改代码。

5. 从“跑通”到“能答辩”：最后一周还能做的三件事

如果系统已经能完整演示，先别躺在“能跑”上，最后一周还有三件事，投入产出比都不低。

第一件：加一个管理端统计接口。家政项目的论文写到“管理员模块”，最没说服力的就是一张订单列表。加一个简单的统计接口，返回今日订单数、待接单数、累计用户数，前端用卡片或柱状图展示，后端一行 SQL 就能完成：

SELECT COUNT(*) AS total_orders, SUM(CASE WHEN status = '待接单' THEN 1 ELSE 0 END) AS pending_orders FROM t_order WHERE create_time >= CURDATE();

第二件：把答辩演示脚本写下来。给自己列一张 A4 纸：先演示用户端下单，再切管理员视角看订单状态变化，最后打开数据库表展示数据落库。每个操作对应一个可能的提问，比如“下单后状态存在哪张表”“家政员怎么看到新订单”。演示时最忌临场发挥，写脚本能锻炼把系统讲成“设计”而不是“操作”。

第三件：准备好“为什么这样设计”的回答口径。选型、状态机、统一请求封装、乐观锁更新，这四个点每一个都能展开讲三分钟。我习惯把接口清单打印出来，在方法名旁边用笔标注“对应需求文档哪一节”，答辩评委一追，能直接翻到证据。

最后说一个自己的习惯：每次启动后端，我从不跳过控制台前二十行日志——数据库连接、项目启动成功、接口注册，扫一眼只要三秒。这个习惯帮我挡掉了大量“刚才还能跑，现在怎么不行了”的翻车。这套家政项目，跑通只是及格线，状态设计、并发控制、文档齐全才是拉开差距的地方。希望帮到你。

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