汽车维修预约系统最容易被写成“选择时间 提交预约”的普通表单项目但真正决定系统是否好用的是预约之后发生了什么。维修员有没有确认维修内容和价格由谁记录顾客怎么知道进度临近维修时间谁来提醒维修完成后能不能评价如果这些环节没有连起来APP 只是把电话预约换成了手机表单。本项目把汽车维修过程拆成技术展示、预约申请、预约审核、维修订单、预约提醒、服务评价和后台运营几个阶段。移动端基于 Android后端采用 SpringBootMySQL 保存顾客、维修员、预约、订单和通知数据并通过 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维修员工号、姓名、审核状态、用户 IDrepair_order订单号、维修人员、顾客车辆、维修任务、价格与订单状态等这里最值得学习的不是表数量而是业务数据之间的连续性顾客先选择技术介绍中的维修员预约通过后形成维修任务维修订单继续记录执行过程预约提醒再利用订单和用户信息完成通知维修结束后才能进入服务评价。十一、测试重点放在“能不能预约”和“能不能评价”两个边界汽车维修预约的异常情况比普通表单更有业务意义。论文测试覆盖注册、登录、维修员查看、预约维修员和服务评价其中预约测试重点验证维修员是否可预约、时间是否有效评价测试则验证订单是否已经完成。• 预约信息完整、维修员可用时预约成功并等待维修员确认• 未填写预约时间或车型等必填信息时系统阻止提交• 维修员预约已满时提示当前维修员不可预约• 预约时间超出可选范围时提示时间不可选• 维修员拒绝预约时前台显示预约失败状态• 维修未完成时不能提前提交服务评价• 评价未填写评分或评论、内容过长或含不当内容时系统进行相应校验。测试结果表明系统能够识别预约信息不完整、维修员不可预约、网络异常和评价内容违规等情况并返回相应提示。相比只测试“页面能打开”这些场景更能验证预约、订单和评价之间的状态约束是否正确。十二、项目总结汽车维修店预约 APP 的核心并不是一个预约按钮而是一张维修任务从产生到完工的全过程。顾客先根据技术介绍选择维修员再提交预约维修员审核预约并维护维修订单系统通过提醒保持双方信息同步维修完成后再进入服务评价管理员则在后台维护账号、维修员资料、通知和资讯。从项目学习角度看这套系统涵盖 Android 移动端、SpringBoot RESTful API、MySQL 数据设计、多角色权限、预约审核、维修订单状态、提醒通知和服务评价等典型业务。后续还可以继续扩展维修报价、车辆历史维修档案、故障诊断和维修资源调度分析等方向。图16 顾客用户注册界面图17 顾客用户登录界面十三、项目源码免费获取 本项目完整源码、MySQL 数据库文件以及相关项目资料已整理可用于课程设计、毕业设计和 Android SpringBoot 项目学习参考。需要完整源码、数据库文件以及项目部署资料的同学可通过文章末尾资源入口免费获取。项目资料仅供学习交流与二次开发参考。