微信小程序4S店管理系统源码：Java+MySQL双端试驾保养预约

简介：面向毕业设计的微信小程序4S店管理系统论文文档，围绕传统汽车经销商信息化水平不足、客户维系与预约服务效率偏低等问题展开，适合计算机相关专业学生用作选题参考、论文框架借鉴与系统设计思路梳理。压缩包内共1个doc文件，约2.01MB，内容以论文正文为主，涵盖摘要、绪论、微信小程序端车辆展示与试驾/保养预约、Java后台管理、MySQL数据库表结构设计，以及安全性、维护更新和用户体验等章节，标题中提及的源码与数据库内容以文档形式呈现。已有73人浏览学习。读者可从中获取较完整的毕业设计论述结构、功能模块划分、数据库设计与接口通信思路，也能参考预约流程、权限管理与数据一致性等设计要点，便于快速搭建论文提纲并对照完善自己的系统方案。

1. 项目定位：一套能跑起来的双端 4S 店服务系统

去年帮一个做汽车经销的朋友梳理后台，销售顾问还在用电话本记试驾预约，客户微信里问一句“周末能试驾吗”，他得翻三个群找人确认，最后常常把客户晾到第二天。这套微信小程序 4S 店管理系统源码，冲的就是这个场景：小程序端做车型展示、试驾预约、保养预约和店铺信息展示，Java 后台负责把预约单收口、确认状态、维护车型和店铺资料，数据统一落在 MySQL。它适合两类人——一类是拿着“毕业设计 Java”这个关键词在找完整双端项目的学生，想要一套能演示、能写论文、能答辩的系统；另一类是手里有门店资源、想快速搭个轻量预约工具的开发者。技术栈不花哨，原生小程序加 Java 加 MySQL，资料好找，改起来也不至于陷进去。

2. 技术栈与整体架构：小程序端、Java 服务端、MySQL 的三层分工

先把选型摊开讲。这套系统的骨架很清晰，前端是小程序，中间是 Java 服务端，底下是 MySQL，管理端跑在浏览器里。原文只写了“Java 语言”“MySQL 数据库”“B/S 结构”，没有指定具体框架，所以按这类双端项目的常见做法，服务端一般是 Spring Boot 起步、MyBatis 做持久层，管理端是服务端渲染的页面或者独立的 Web 工程。我按这个思路来拆，你手里如果是别的组合（比如 SSM 手写 Servlet），逻辑也基本对得上。

顺便提醒一句：搜索关键词里还挂着 python，但这份资源的服务端是 Java，数据库是 MySQL，别看到关键词就以为是 Python 项目，拿到手发现跑不起来又是一轮折腾。判断依据看源码目录里有没有 pom.xml 或者 WEB-INF，有就是 Java 体系。

2.1 小程序端：不引框架，四件套直接开工

小程序这层用的是原生开发，每个页面就是 .wxml、.wxss、.js、.json 四个文件，全局配置压在 app.json 里。好处是零构建，微信开发者工具打开目录就能预览，改一行 WXML 保存后模拟器立刻刷新，调试链路最短。代价是组件复用要自己抽，列表页、表单页的加载态、空态、错误态都得手写一遍。

对毕业设计这个体量来说，原生反而更稳。npm 装一堆 UI 库，答辩机器上网络一断就卡住，得不偿失。项目里的请求统一收在 utils/request.js，把 baseUrl、超时、错误提示封一层，页面里只关心业务字段，这个习惯建议保留——后面要换域名或者加 token，改一个文件就够了。

2.2 Java 服务端：Controller、Service、Mapper 三层不要糊在一起

服务端按经典三层切：controller 只做参数接收和返回体包装，service 承担业务规则（比如同一手机号当天不能重复预约同一车型），mapper 只管 SQL。很多同学写课设喜欢把校验、SQL、返回全塞在 Controller 里，一开始快，加第二个入口就开始互相踩。

统一返回体是必须的，小程序端判断成功与否只看一个 code 字段，比解析 HTTP 状态码省事得多：

// 统一响应体，code=200 表示业务成功，前端只认这个字段 public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> fail(String msg) { Result<T> r = new Result<>(); r.code = 500; r.msg = msg; // 直接把可读的失败原因透给前端弹 toast return r; } }

code 用 200/500 这种业务码而不是 HTTP 状态码，是因为小程序的 wx.request 在 4xx、5xx 时也会进 success 回调，不判断容易把报错当成功渲染。msg 字段要写人话，"预约时间不能早于当前时间"比 "IllegalArgumentException" 有用得多。

2.3 管理端走 B/S：浏览器打开就能用，不占客户端硬盘

后台管理系统用的是 B/S 结构，管理员输网址、登录、进主界面，左边一级菜单挂预约试驾、维修保养、车辆管理、店铺设置，点开再出二级菜单（今日预约、预约记录、车辆信息、车型信息）。原文特意强调“不占用客户端硬盘空间”“在浏览器中就能实现登录”，落到实现上就是服务端渲染页面或者一套静态页面加接口，两种都能用，前者省一个前端工程。

菜单结构最好在数据库里存一份或者用配置写死，别在 JSP/HTML 里复制粘贴五遍。后面加一个“客户管理”菜单，你就知道疼了。

2.4 一次预约请求的完整数据流

把链路走一遍，心里就有图了：用户在预约试驾页填完姓名、手机号、意向车型、到店时间，点提交 → 小程序 wx.request POST 到 /api/testdrive/add → Controller 接 JSON 转成表单对象 → Service 校验必填项、校验时间不能早于今天、查重 → Mapper 插一条 test_drive 记录，status 默认 0（待确认）→ 返回 Result.ok → 小程序 toast “预约成功，顾问会尽快联系您”。

后台那边，管理员打开预约记录页，GET /api/testdrive/page?page=1&size=10&keyword=138 → 列表出数据，点“确认”按钮走 PUT /api/testdrive/confirm/{id}，把 status 从 0 改成 1 并写确认时间。整条链路没有异步、没有消息队列，MySQL 单表就扛得住，这就是课设体量该有的样子——别为了显得高级硬上 Redis。

3. 目录结构与跑通流程：从导入 SQL 到模拟器出首页

拿到源码先别急着双击，先看目录。这类双端项目一般是两个工程并列，一个小程序目录、一个服务端目录，外加一份 .sql 脚本。结构认清楚了，配置改哪几个文件心里才有数。

3.1 工程目录一览

4s-miniprogram/ 小程序端 ├── app.js 全局逻辑，挂 baseUrl ├── app.json 页面路由 + tabBar 配置 ├── app.wxss 全局样式 ├── pages/ │ ├── index/ 首页（轮播、店名、四大入口、推荐车型） │ ├── carlist/ 全部车型列表 │ ├── cardetail/ 车型详情 │ ├── testdrive/ 预约试驾表单 │ ├── maintain/ 维修保养预约表单 │ ├── shop/ 店铺简介 │ └── mine/ 个人中心 ├── utils/request.js 请求封装（baseUrl、超时、错误提示） └── images/ 静态图 4s-server/ 服务端 ├── src/main/java/com/demo/ │ ├── controller/ 接口层 │ ├── service/ 业务层 │ ├── mapper/ DAO 接口 │ ├── entity/ 实体与表单对象 │ └── config/ 跨域、拦截器、文件上传配置 ├── src/main/resources/ │ ├── application.yml 数据源、端口、上传路径 │ └── mapper/ MyBatis XML └── pom.xml 4s.sql 建库建表 + 初始数据

看到 pages 下这七个目录，功能边界基本就清楚了：前端只有展示和提交，所有写操作都落到两个预约表单上。后台功能则集中在车辆、预约、店铺三块，跟论文里的功能模块图一一对应。

3.2 数据库导入与配置修改

先把 4s.sql 导进 MySQL，建库、建表、插演示数据一步到位。命令行方式比图形工具稳，报错信息也看得清：

# 建库并导入，-u 用户名 -p 回车后输密码 mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS car4s DEFAULT CHARSET utf8mb4;" mysql -u root -p car4s < 4s.sql # 导入后确认表和数据都在 mysql -u root -p car4s -e "SHOW TABLES; SELECT COUNT(*) FROM car_info;"

字符集一定要 utf8mb4，别用 utf8。车型名称里带个生僻字或者用户备注里打个表情，utf8 直接截断报错，这是最经典的翻车点之一。

建库成功后改服务端配置，主要是三处：数据库连接、服务端口、图片上传目录。

# application.yml 关键片段 server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/car4s?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver upload: path: D:/upload/ # 本地绝对路径，上线换成服务器目录

url 里那个 serverTimezone=Asia/Shanghai 不能省。少了它，Java 的 Date 和 MySQL 的 datetime 之间会差 8 小时，后台看到的预约时间全是凌晨，排查起来很费劲。

3.3 启动服务端并验证接口

用 Maven 起，或者直接在 IDE 里跑主类：

cd 4s-server mvn clean package -DskipTests java -jar target/4s-server-1.0.jar

启动日志里看到 Tomcat started on port 8080 就算起来了。别急着开小程序，先用浏览器或者 curl 打一个只读接口，确认数据库通、SQL 没写错：

# 查车型列表，正常应返回 JSON，code 为 200 curl "http://localhost:8080/api/car/list?page=1&size=6"

返回 500 就去看控制台堆栈，八成是表名或字段名跟实体对不上；返回空数组说明表建好了但没插数据，把 4s.sql 里的 insert 语句单独跑一遍。

3.4 小程序端配置与预览

小程序这边要改两处：app.js 里的 baseUrl，和开发者工具的“不校验合法域名”开关。

// app.js App({ globalData: { // 本机调试用 localhost 或 127.0.0.1；真机预览要换成电脑局域网 IP baseUrl: 'http://localhost:8080', userInfo: null } })

改完打开微信开发者工具，导入 4s-miniprogram 目录，AppID 选测试号即可。编译后首页应该能看到轮播图、店名、营业时间、四个功能入口和推荐车型。如果首页一片空白但控制台没报错，先看 app.json 里 pages 数组第一项是不是 index，页面栈入口配错了就是白屏。

真机预览时 localhost 必然连不上，得把 baseUrl 换成电脑的局域网 IP，比如 http://192.168.1.20:8080，并且手机和电脑在同一个 Wi-Fi 下。这一步踩过的人不少，改完还是连不上就检查电脑防火墙有没有拦 8080。

3.5 联调验收清单

跑通的标准不是“首页能看”，而是整条业务链路闭环。按这个顺序过一遍：

1. 首页车型能正常渲染，点进详情页价格、缩略图不空白。
2. 提交一条试驾预约，数据库 test_drive 表多一条 status=0 的记录。
3. 后台预约记录页能查到这条数据，关键字搜手机号能命中。
4. 点“确认”后 status 变 1，确认时间有值。
5. 提交一条保养预约，车牌号、行驶里程、保养项目都完整落库。
6. 后台改一条车型价格，刷新小程序详情页能看到新价格。

六条全过，这套源码就算真正跑起来了。哪一条断掉，问题一定在对应那一层，不用满世界找。

4. 核心模块拆解：车型渲染与预约落库的完整链路

跑通之后就该看代码了。这套系统的核心其实就两块：读（车型和店铺信息怎么送到小程序）和写（预约单怎么安全落库、后台怎么确认）。把这两条链路吃透，剩下的页面都是换皮。

4.1 车型列表接口：分页、分类、推荐位一次讲清

@RestController @RequestMapping("/api/car") public class CarController { @Autowired private CarService carService; /** * 小程序车型列表 * @param cateId 分类 id，可为空，空则查全部（卧车 / SUV） * @param page 页码，从 1 开始，默认 1 * @param size 每页条数，首页推荐传 6，列表页传 10 */ @GetMapping("/list") public Result<List<CarVO>> list(@RequestParam(required = false) Integer cateId, @RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size) { if (page < 1) page = 1; // 防御：前端传 0 会导致 offset 为负 if (size > 50) size = 50; // 防御：防止一次拉全表 List<CarVO> list = carService.pageList(cateId, (page - 1) * size, size); return Result.ok(list); } }

参数说明：cateId 对应汽车分类表的主键，前端点“卧车”“SUV”标签时传对应值；page 和 size 直接决定 SQL 的 limit offset。两个 if 是必要的边界保护——小程序端翻页组件偶尔会传 0，不拦下来 SQL 直接抛异常。CarVO 里除了车型基本信息，还要带分类名称和图片完整 URL，让前端少一次请求，也避免前端自己拼路径拼错。

对应的 SQL 在 XML 里，按分类动态拼 where：

<select id="pageList" resultType="com.demo.entity.CarVO"> SELECT c.id, c.car_name, c.price_min, c.price_max, c.month_sales, c.cover_img, t.type_name FROM car_info c LEFT JOIN car_type t ON c.type_id = t.id <where> c.is_deleted = 0 <if test="cateId != null"> AND c.type_id = #{cateId} </if> </where> ORDER BY c.sort_no ASC, c.id DESC LIMIT #{offset}, #{size} </select>

is_deleted = 0 是软删除标记，后台“删除车型”只改标记不物理删，因为预约单里存着车型 id，物理删了后台预约记录就查不到车名了。这个设计面试时能讲，答辩时也是加分点。

4.2 小程序首页：一次 onLoad 拉完三份数据

首页要展示轮播图、店铺信息、推荐车型三块数据，常见写法是在 onLoad 里并发发起，各自 setData，不要串行 await，否则首屏白屏时间翻倍。

// pages/index/index.js const app = getApp(); Page({ data: { banner: [], shop: {}, cars: [], loading: true }, onLoad() { this.loadShop(); this.loadBanner(); this.loadCars(); }, // 推荐车型，首页只取前 6 条 loadCars() { wx.request({ url: app.globalData.baseUrl + '/api/car/list', data: { page: 1, size: 6 }, success: (res) => { if (res.data.code === 200) { this.setData({ cars: res.data.data }); } else { wx.showToast({ title: res.data.msg || '加载失败', icon: 'none' }); } this.setData({ loading: false }); }, fail: () => { // 网络层失败，多半是 baseUrl 错或者服务端没起 wx.showToast({ title: '网络异常', icon: 'none' }); this.setData({ loading: false }); } }); }, // 点击拨号，open-type 之外的第二条路 callShop() { wx.makePhoneCall({ phoneNumber: this.data.shop.phone }); }, // 点击地址，拉起内置地图 openMap() { wx.openLocation({ latitude: Number(this.data.shop.lat), longitude: Number(this.data.shop.lng), name: this.data.shop.shopName, address: this.data.shop.address }); } })

这段的关键在两点。第一，success 里必须先判 code，网络通不代表业务通，很多人只写 fail 分支，结果后端抛异常返回 500 码，前端照样渲染空列表，用户以为店里没车。第二，openLocation 的经纬度必须转 Number，数据库里存的是 varchar，直接传字符串在部分机型上会静默失败，这种问题在模拟器上永远复现不了。

4.3 预约试驾提交：校验放在服务端才算数

前端表单校验只是体验，真正的防线在 Service。这块代码最能体现“课设系统”和“能用的系统”的差距。

@Service public class TestDriveService { @Autowired private TestDriveMapper mapper; public void add(TestDriveForm form) { // 1. 必填校验，前端绕过也能拦住 if (StringUtils.isBlank(form.getPhone()) || form.getCarId() == null) { throw new BizException("请填写手机号和意向车型"); } if (!form.getPhone().matches("^1[3-9]\\d{9}$")) { throw new BizException("手机号格式不正确"); } // 2. 预约时间不能早于今天（按天比较，不比到秒） LocalDate bookDate = form.getBookTime().toLocalDate(); if (bookDate.isBefore(LocalDate.now())) { throw new BizException("预约时间不能早于今天"); } // 3. 同一手机号 + 同一天 + 同一车型，只允许一条待确认记录 int exist = mapper.countSameDay(form.getPhone(), bookDate, form.getCarId()); if (exist > 0) { throw new BizException("你已提交过该车型的预约，请等待顾问联系"); } form.setStatus(0); // 0 待确认，1 已确认，2 已到店 form.setCreateTime(new Date()); mapper.insert(form); } }

逻辑说明：校验顺序按“便宜的先做”排，字符串判空最便宜，查库最贵，放在最后。日期比较用 LocalDate 而不是 Date，避免用户选今天但时间早于当前时刻被误判。查重条件带上 carId 很重要——用户想同时试两款车是合理需求，只按手机号和日期查重会把正常用户拦在门外。

参数说明：status 字段是预约单的状态机核心，后台“确认”按钮改 1，“到店”改 2，不要用删除表示完成，历史记录留着才能统计。create_time 由服务端写，绝不接受前端传时间，这是最基本的安全意识。

4.4 保养预约与后台状态流转

保养预约比试驾多几个字段：车牌号、行驶里程、保养项目、备注。保养项目在库里一般存字符串（用户勾选的“更换机油、四轮定位”拼起来），不建关联表——这个体量下没必要，真想规范，加一个以逗号分隔的 id 串也够用。

后台确认就是一个带条件的更新，条件里带旧状态能防并发重复点击：

-- 只有待确认(0)的单子才能改成已确认(1)，重复点不会重复写 UPDATE maintain_order SET status = 1, confirm_time = NOW(), confirm_by = #{adminId} WHERE id = #{id} AND status = 0;

Mapper 返回受影响行数，Service 判断如果等于 0 就抛“该预约已被处理，请刷新列表”。这个小技巧能挡掉管理员手抖连点两下的问题，也挡住了两个后台账号同时操作同一单的脏写。

5. 避坑与常见问题排查：联调、编码、时区的血泪经验

这一章是我实际折腾这类项目时踩过的坑，按“现象 → 原因 → 解决”列出来，照着对号入座能省大半天。

5.1 现象：小程序报“request:fail url not in domain list”

原因：微信开发者工具默认校验合法域名，本地 http://localhost:8080 不在白名单里，真机更是完全不允许 http。

解决：开发阶段在工具右上角“详情 → 本地设置”勾上“不校验合法域名、web-view、TLS 版本以及 HTTPS 证书”。真机预览时把 baseUrl 换成电脑局域网 IP，手机和电脑同网段，并且关掉电脑防火墙对 8080 的拦截。上线才需要备案域名加 HTTPS，课设演示不用折腾。

5.2 现象：后台录入的车型名、用户备注存进库变成问号

原因：数据库、表、连接串三处字符集不一致。常见是建库时用了默认 latin1，或者连接串写了 characterEncoding=utf8 而库里是 utf8mb4。

解决：三步统一。建库语句显式写 DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci；建表同样指定；连接串写 characterEncoding=utf8mb4。已经建好的表用 ALTER TABLE car_info CONVERT TO CHARACTER SET utf8mb4; 转一次。改完记得重启服务端，连接池里的旧连接还带着老字符集。

5.3 现象：后台看到的预约时间比用户填的早 8 小时

原因：JDBC 连接的 serverTimezone 没配，或者配成了 UTC，Java 的 Date 在写入和读取时各转一次时区。

解决：连接串加 serverTimezone=Asia/Shanghai，实体里的时间字段统一用 java.util.Date 或 LocalDateTime，别一个类用 Date 一个类用 LocalDateTime 混着来。数据库字段类型选 datetime 而不是 timestamp，timestamp 会随服务器时区自动转换，排查时更绕。

5.4 现象：后台传了车型图片，小程序端显示裂图，浏览器直接访问图片地址 404

原因：上传目录配的是相对路径，服务端工作目录一变就找不到；或者只存了文件名，前端拼路径时少了前缀。

解决：上传路径在 application.yml 里写绝对路径，并且配一个静态资源映射，把 /upload/** 映射到该目录。数据库里只存相对文件名，返回给前端时由服务端拼成完整 URL，这样换域名、换端口都不用改库。别在数据库里存 http://localhost:8080/upload/xxx.jpg，上线第一件事就是全表 update。

5.5 现象：同一个人点两次提交，后台出现两条一模一样的预约单

原因：前端按钮没做防重复点击，用户网络慢时连点两下；服务端也没有幂等校验。

解决：前端在提交前置一个 submitting 标记，回调结束再放开，按钮同时加 disabled 样式。服务端按 4.3 里的查重逻辑兜底，同一手机号同一天同一车型只允许一条待确认单。两层都做才叫稳，只做前端，抓包重放一样能刷。

5.6 现象：改了车型价格，小程序端还是旧数据

原因：小程序页面栈缓存，返回上一页时 onLoad 不会再触发。

解决：列表页在 onShow 里刷新，或者在详情页改完数据后用 getCurrentPages 拿到上一页实例直接 setData。开发阶段可以顺手在工具里清缓存，但别指望用户会清，代码里得处理。

6. 二次开发改造：从单店模板到多门店与预约提醒

这套系统默认是单店模型——店铺信息表只有一行，车型不分门店，预约单也没有门店字段。要拿去做真实业务，第一个改造点就是多门店。我的做法是加一张 store 表，在 car_info、test_drive、maintain_order 三张表各加一个 store_id 字段，后台登录时把 store_id 塞进 session，所有查询强制带上这个条件。改动量不大，但能立刻把一个演示项目变成可交付的东西。

-- 多门店改造：三张业务表加门店维度 ALTER TABLE car_info ADD COLUMN store_id BIGINT NOT NULL DEFAULT 1; ALTER TABLE test_drive ADD COLUMN store_id BIGINT NOT NULL DEFAULT 1; ALTER TABLE maintain_order ADD COLUMN store_id BIGINT NOT NULL DEFAULT 1; -- 联合索引，门店 + 状态 + 时间，后台列表页的主要查询路径 CREATE INDEX idx_store_status_time ON test_drive (store_id, status, create_time);

第二个改造点是预约提醒。现在用户提交完只能等电话，体验断层。最轻的做法是加一个定时任务，每分钟扫一遍 test_drive 里 status=0 且 create_time 在 5 分钟前的单子，调短信或者小程序订阅消息推给顾问。定时任务别用 @Scheduled 在主线程里跑重查询，单独开线程池，否则高峰期会把接口拖慢。

第三个容易忽略的是权限。现在后台只有一个管理员账号，加了门店之后至少要区分“总部管理员”和“门店顾问”，顾问只能看自己门店的预约。别图省事在 Controller 里写 if 判断角色，用一个拦截器统一处理，注解标在方法上，后面加角色只改注解。

验证改造有没有成功，我一般不看页面，直接看 SQL 日志：打开 MyBatis 的日志输出，跑一遍后台列表页，确认每条查询都带上了 store_id 条件。带上了才算真隔离，只在前端过滤等于没做。

血泪经验是：第一次改这类项目，我图快直接在原表上加字段、在原接口上加参数，改到第三个模块发现前面两处漏了门店条件，数据串得没法回滚。从那以后我每次动表结构，都先把所有涉及该表的 SQL 语句 grep 一遍列成清单，改完逐条打勾，再跑一轮全链路回归。这套笨办法救过我至少三次。希望帮到你。

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