汽车维修预约系统最容易被写成“选择时间 + 提交预约”的普通表单项目，但真正决定系统是否好用的，是预约之后发生了什么。维修员有没有确认？维修内容和价格由谁记录？顾客怎么知道进度？临近维修时间谁来提醒？维修完成后能不能评价？如果这些环节没有连起来，APP 只是把电话预约换成了手机表单。
本项目把汽车维修过程拆成技术展示、预约申请、预约审核、维修订单、预约提醒、服务评价和后台运营几个阶段。移动端基于 Android，后端采用 SpringBoot，MySQL 保存顾客、维修员、预约、订单和通知数据，并通过 RESTful API 完成前后端数据交互。
一、先抓住五个核心对象，系统就不再是一堆页面
这套 APP 的业务重点并不在菜单数量，而在五类数据对象如何前后衔接。它们分别承担“展示、申请、执行、提醒、反馈”五种职责。
核心对象 | 作用 | 典型状态/内容 |
技术介绍 | 帮助顾客先判断维修员是否适合自己的车型和维修需求 | 员工工号、擅长车辆、个人介绍、头像、评价 |
预约信息 | 记录顾客发起的维修需求，并等待维修员确认 | 预约日期、车型、顾客资料、审核状态 |
维修订单 | 把已确认预约变成可执行、可跟踪的维修工单 | 维修日期、维修内容、价格、维修进度、完工状态 |
预约提醒 | 在正式维修前把时间和任务再次通知相关人员 | 订单号、维修员、顾客、预约日期、通知内容 |
服务评价 | 维修结束后形成用户反馈 | 评分、评论、违规内容校验 |
图1 系统功能结构图
二、顾客端不是先预约，而是先“选维修员”
顾客进入系统后，可以先浏览维修员的技术介绍。页面展示维修员的专业技能、维修经历、服务评分等信息，使用户不是随机提交维修需求，而是先根据车辆和维修方向选择更合适的维修人员。
图2 维修员技术介绍查看界面
这种设计把“维修员能力”放在预约之前，相当于先建立选择依据，再进入预约。对于汽车维修这类强专业服务，这比单纯展示一个预约时间表更符合实际业务。
三、预约单只负责“提出需求”，维修单才负责“真正执行”
顾客确定维修员后，进入预约信息页面选择日期并提交维修需求。预约提交成功并不代表维修任务已经执行，而是进入等待维修员确认的阶段。维修员可以结合自己的时间安排接受或拒绝预约，审核结果再同步回顾客端。
图3 顾客预约信息界面
这里把“预约信息”和“维修订单”拆成两个阶段非常关键。预约信息更像需求申请，解决“谁、什么车、什么时候想修”；维修订单则解决“什么时候实际维修、修了什么、多少钱、做到哪一步”。两个对象分开后，状态更清楚，也方便后续追踪。
四、一张维修订单要能回答三个问题：修什么、多少钱、到哪一步
预约确认后，维修员可以生成或确认维修订单，并记录维修日期、维修内容、价格等信息。随着维修推进，订单状态继续更新，完工后记录维修情况和完工时间。顾客则在个人中心查看订单详情和最新进度。
图4 顾客维修订单查看界面
图5 维修员维修订单管理界面
这类设计的价值在于把原本口头沟通的维修过程沉淀成结构化记录。顾客能看到费用和进度，维修员也有明确的工作任务与完工状态，后续服务评价也有对应订单作为前置条件。
五、维修员端真正承担的是“接单调度”
维修员后台包含技术介绍管理、预约信息管理、维修订单管理和预约提醒管理。它的核心不是增删改查，而是把自己的可服务能力、接单情况和维修任务组织起来。
技术介绍管理用于维护擅长车辆、个人简介、员工资料等，让前台展示的信息保持准确。
图6 维修员技术介绍管理界面
预约信息管理用于查看顾客提交的预约，维修员可以根据车型、预约时间和自身安排接受或拒绝请求。审核完成后，系统更新预约状态并反馈给顾客。
图7 维修员预约信息管理界面
六、预约提醒把“已确认”变成“不会忘记”
维修订单确认后，系统还设计了预约提醒。提醒内容可以包含预约时间、顾客姓名、车辆信息和维修任务，让维修员提前准备工具和材料，也让顾客减少错过预约的情况。
图8 预约提醒管理界面
数据库中的预约提醒表同时保存订单号、维修人员、顾客、车牌号、车辆类型、预约日期、通知内容和审核状态等字段。也就是说，提醒不是一条脱离业务的消息，而是与具体订单和预约对象关联的业务记录。
七、个人中心的作用：把预约、订单和提醒放回同一个用户视角
顾客在维修过程中会产生多类数据，如果分散在不同入口，很容易出现“提交过预约却找不到进度”的问题。个人中心把历史预约、维修订单、预约提醒等内容统一收拢，用户可以从一个入口持续查看自己的维修服务。
图9 顾客个人中心界面
八、管理员不是替维修员接单，而是保证平台数据可信
管理员侧更偏向平台治理。它负责顾客、维修员等账号信息和权限管理，同时审核或维护维修员技术介绍，避免前台出现不准确的技能信息；另外还负责个人通知和汽车维修资讯等内容发布。
图10 用户管理界面
图11 技术介绍后台维护界面
图12 个人通知管理界面
图13 汽车维修资讯管理界面
这样一来，维修员负责“服务执行”，管理员负责“平台治理”，两者职责不会混在一起。顾客看到的维修员资料、通知和资讯，也都有明确的后台维护入口。
九、Android + SpringBoot：移动端只负责交互，业务状态交给后端
系统前端采用 Android 平台，顾客可以通过移动端完成注册登录、查看维修员、提交预约、查看订单和接收提醒；后端由 SpringBoot 提供业务接口，并通过 RESTful API 与 APP 交换数据；MySQL 负责保存用户、预约记录、维修订单和通知等核心数据。
层次 | 技术 | 主要职责 |
移动端 | Android | 用户交互、预约操作、订单查看、消息展示 |
服务端 | SpringBoot / Java | 身份校验、预约审核、订单状态、业务接口 |
数据层 | MySQL | 保存顾客、维修员、预约、订单、提醒和通知数据 |
登录阶段先校验账号和密码，再根据身份进入不同功能。顾客、维修员和管理员拥有不同的操作范围，避免移动端普通用户直接访问后台管理功能。
图14 用户登录流程图
十、数据库设计：订单号是连接预约提醒与维修任务的重要线索
系统总 E-R 图围绕用户、技术介绍、预约信息、公告资讯和管理员等实体建立关系。结合物理表结构可以看出，顾客用户、技术介绍、预约提醒、维修员和维修订单是维修业务中的关键数据。
图15 系统总 E-R 图
数据表/实体 | 关键内容 |
customer_user | 顾客姓名、联系方式、车牌号、车辆类型、车辆图片等 |
technical_introduction | 维修人员、员工工号、擅长车辆、个人介绍、预约限制次数等 |
appointment_reminder | 订单号、维修员、顾客、车辆信息、预约日期、通知内容、审核状态 |
repairman | 维修员工号、姓名、审核状态、用户 ID |
repair_order | 订单号、维修人员、顾客车辆、维修任务、价格与订单状态等 |
这里最值得学习的不是表数量，而是业务数据之间的连续性：顾客先选择技术介绍中的维修员，预约通过后形成维修任务，维修订单继续记录执行过程，预约提醒再利用订单和用户信息完成通知，维修结束后才能进入服务评价。
十一、测试重点放在“能不能预约”和“能不能评价”两个边界
汽车维修预约的异常情况比普通表单更有业务意义。论文测试覆盖注册、登录、维修员查看、预约维修员和服务评价，其中预约测试重点验证维修员是否可预约、时间是否有效，评价测试则验证订单是否已经完成。
• 预约信息完整、维修员可用时，预约成功并等待维修员确认；
• 未填写预约时间或车型等必填信息时，系统阻止提交；
• 维修员预约已满时，提示当前维修员不可预约；
• 预约时间超出可选范围时，提示时间不可选；
• 维修员拒绝预约时，前台显示预约失败状态；
• 维修未完成时不能提前提交服务评价；
• 评价未填写评分或评论、内容过长或含不当内容时，系统进行相应校验。
测试结果表明，系统能够识别预约信息不完整、维修员不可预约、网络异常和评价内容违规等情况，并返回相应提示。相比只测试“页面能打开”，这些场景更能验证预约、订单和评价之间的状态约束是否正确。
十二、项目总结
汽车维修店预约 APP 的核心并不是一个预约按钮，而是一张维修任务从产生到完工的全过程。顾客先根据技术介绍选择维修员，再提交预约；维修员审核预约并维护维修订单；系统通过提醒保持双方信息同步；维修完成后再进入服务评价；管理员则在后台维护账号、维修员资料、通知和资讯。
从项目学习角度看，这套系统涵盖 Android 移动端、SpringBoot RESTful API、MySQL 数据设计、多角色权限、预约审核、维修订单状态、提醒通知和服务评价等典型业务。后续还可以继续扩展维修报价、车辆历史维修档案、故障诊断和维修资源调度分析等方向。
图16 顾客用户注册界面
图17 顾客用户登录界面
十三、项目源码免费获取
📦 本项目完整源码、MySQL 数据库文件以及相关项目资料已整理，可用于课程设计、毕业设计和 Android + SpringBoot 项目学习参考。
需要完整源码、数据库文件以及项目部署资料的同学，可通过文章末尾资源入口免费获取。项目资料仅供学习交流与二次开发参考。
