“这届毕设选汽车保养系统的人我见过太多了一个班里少说三四个。我刚带完的这个项目就是基于微信小程序的汽车保养系统平台选题已经被机械、车辆、计算机几个专业的学生做得快包浆了但说实话真正把逻辑理清楚、把代码和论文搭得能看的十个人里面不超过两个。这个项目好就好在微信小程序是当前毕业生做C端应用最顺手的载体汽车保养又是一个业务链路完整、需求明确、不靠拍脑袋编场景的领域你的车辆管理、保养提醒、记录查询、预约服务都能落成真实可用的功能既有技术深度又有业务闭环答辩的时候非常好讲。这篇文章我直接把整个项目的思路、架构、核心实现、论文组织、避坑点全拆开讲拿去做毕设也好拿去做练习项目也好你能少走特别多弯路。”1. 项目全貌拆解这个毕设到底做了什么1.1 标题背后需求的真实含义很多毕业生一开始被“汽车保养系统”这个名字带偏以为要做的是一个类似4S店后台管理的系统一上来就去设计工单管理、配件库存、财务结算结果做了两个月发现根本做不完答辩还被老师追问“微信小程序端在哪”。这个题目真正的核心是车主通过微信小程序完成“绑定车辆—查看保养计划—记录保养历史—接收保养提醒—预约保养服务”的完整闭环。管理端可以简单甚至可以是一个跑在服务器上的接口服务加一个简易的Web后台但小程序端必须功能齐全演示顺畅。说白了老师想看到的是一个能“用起来”的C端产品而不是一个只有后台的ERP。和宠物寄养、旅游预约这类同类型小程序项目相比汽车保养系统最大的优势在于它的数据模型非常清晰车辆信息、保养项目、保养周期、保养记录、门店信息、预约订单六张表就能撑起全部核心业务非常适合在毕设周期内保质保量完成。同时它的业务逻辑带一点“计算性”比如按里程或时间自动计算下次保养时间这种规则型逻辑在论文里很好写也好做测试用例展示。1.2 用户视角的功能清单项目做出来之后我把小程序端功能整理成了一张清单方便你对照检查自己的需求分析有没有遗漏。微信登录授权使用微信用户的openid作为唯一标识静默登录减少用户操作成本。车辆管理添加车辆信息包括车牌号、品牌型号、车架号选填、当前里程数、上次保养时间和里程。保养计划与计算根据车辆型号和保养项目机油、机滤、空气滤芯等自动生成保养建议按照里程间隔和时间间隔两种维度计算。保养记录管理用户每次做完保养后填写记录包括保养项目、花费金额、保养里程、保养门店、备注信息。保养提醒订阅通过微信订阅消息在车辆即将达到保养条件时给用户推送提醒。门店查询与预约展示合作保养门店的列表和详情用户可以选择门店、选择时间提交预约。个人中心查看我的车辆、保养历史、预约记录、消息列表。你对比一下就会发现这个清单围绕的核心就是“一台车从买来到定期保养的所有信息闭环”。后台管理端只需要维护保养项目库、门店信息、预约单状态不需要做复杂的人事、财务模块。1.3 业务规则的前置梳理在写第一行代码之前我建议你把业务规则想清楚尤其是保养周期的计算逻辑。汽车保养行业有一个通用规则小保养一般每5000公里或6个月进行一次大保养一般在20000公里或2年左右做一次以先到者为准。不过不同车型、不同机油类型会存在差异全合成机油可以撑到10000公里。这个规则直接决定了你的数据模型不能在代码里写死。我把保养项目表设计成了可配置的每个保养项目都有一个“保养周期里程”和“保养周期时间”在做车辆保养判断的时候遍历该车辆适用的保养项目以“当前里程数”和“上次保养时间”作为基准计算出哪些项目已到期、哪些即将到期再用状态标识展示出来。这块是整个系统最有技术含量的地方也是论文里可以重点展开的部分。2. 技术选型与架构设计为什么这么搭2.1 前端为什么选微信小程序原生开发毕设项目里面前端技术栈无非三种选择微信小程序原生、基于uni-app开发、纯Web页面套壳。我这次选了原生微信小程序。选择原生而不选uni-app核心原因有三条。第一原生小程序语法结构简单直接就是WXML、WXSS、JS、JSON四个文件组成一个页面没有框架层的二次封装出问题了查资料又准又快。很多同学用uni-app踩到生命周期不触发、组件兼容性问题排查半天发现是框架版本导致非常耽误进度。第二毕业设计答辩现场一般要求直接扫码演示微信开发者工具直接上传体验版就行uni-app打包流程多一道现场容易出岔子。第三原生小程序的底层API、订阅消息、云开发等功能都是直接对接微信生态的不需要额外适配。顺便说一句如果你考虑跨端比如同一个项目以后还要发布APP和H5那uni-app确实有优势。但就毕设来说时间紧、任务重、求稳原生是最优先的选择。我在项目里也严格遵循了小程序的页面栈规范五个Tab页用自定义TabBar二级页面通过路由跳转进入。2.2 后端框架与数据库选型后端部分我选的是Spring Boot加MyBatis Plus数据库用MySQL 8.0接口文档用Swagger自动生成。这套组合在今天看来虽然有点“烂大街”但好处是资料多、报错好解决、面试也好聊。如果你不熟悉Java也可以选Node.js的Express或Koa或者Python的Flask都可以。但我建议不要换成一门你完全没写过的语言毕设的意义是把你已经掌握的东西用完整项目串起来而不是现场学一个新语言。数据库设计是这类系统的重头戏我先把核心表结构列出来你照着设计基本不会出大问题用户表userid、openid、昵称、头像、手机号、创建时间。openid设置唯一索引。车辆表vehicleid、user_id、车牌号、品牌、型号、当前里程数、购买日期、上次保养里程、上次保养时间。user_id建立索引。保养项目表maintenance_itemid、名称、类别小保养/大保养/常规检查、周期里程、周期时间、适用车型关键字、说明。这是系统配置表。保养记录表maintenance_recordid、vehicle_id、保养项目编号、保养里程、保养时间、金额、门店、备注、创建时间。门店表storeid、名称、地址、联系电话、营业时间、评分、封面图。预约表appointmentid、user_id、store_id、vehicle_id、预约日期、时间段、状态待确认/已完成/已取消、创建时间。六张表不要贪多。我看到很多同学喜欢加一张“管理员表”再拉一个用户角色字段其实没必要。管理员直接用另一个小程序后台接口去操作后台加上简单的登录校验就可以。毕设的评分点在于功能的清晰度不在表多表少表少反而更好写论文的ER图和数据字典。2.3 前后端接口设计的几个细节前后端交互统一走HTTPS接口现在微信小程序强制要求域名必须备案并且配置合法域名开发阶段可以在开发者工具里勾选“不校验合法域名”临时跑通上线前再绑定自己的域名。我做接口设计时统一返回格式类似于{ code: 0, message: success, data: {} }这样小程序端做网络请求封装就非常简单全局只需要写一个request函数处理loading、错误提示、401跳转登录这些通用逻辑每个页面只用关注业务数据。包括小程序端的请求封装我把baseURL集中放在app.js的globalData里每个需要用到接口的页面自己引入避免所有页面复制一份URL地址改起来想哭。3. 核心功能实现代码级拆解3.1 登录授权和车辆绑定怎么落地微信小程序登录现在最推荐的做法是使用wx.login获取code发送到后端后端拿到code调用微信的code2Session接口换取openid。要注意现在的小程序已经没法直接把用户手机号静默拿到了手机号必须通过button组件配合getPhoneNumber授权获取这个改动影响了很多老项目模板。我在做的时候把手机号绑定做成用户主动触发的操作放在个人中心里不作为登录登录的必选条件。车辆绑定是用户第一次进入系统后的关键操作也是整个保养计算的数据来源。从交互上我先让用户填车牌号然后前端根据车牌自动识别车辆品牌。这里识别逻辑其实很简单用一个简单的品牌前缀映射表比如“京A”和车型没关系真正判断还是靠用户选择品牌型号。不过这里有个体验优化的点我用了一个车型选择器品牌选择后二级联动出型号列表数据从后端接口获取。这样避免用户手动输入乱七八糟的内容后面做保养项目匹配时就依赖这个型号字段。车辆绑定的关键代码如下简化的是后端保存时需要同时校验车牌号和里程数public ResultVoid bindVehicle(RequestBody VehicleBindDTO dto) { // 校验同一用户下车牌号不能重复 Long count vehicleMapper.selectCount( new LambdaQueryWrapperVehicle() .eq(Vehicle::getLicensePlate, dto.getLicensePlate()) .eq(Vehicle::getUserId, currentUserId())); if (count 0) { return Result.error(该车牌已绑定); } // 校验当前里程数不能小于上次保养里程 if (dto.getCurrentMileage() dto.getLastMaintenanceMileage()) { return Result.error(当前里程数不能小于上次保养里程); } Vehicle vehicle new Vehicle(); BeanUtil.copyProperties(dto, vehicle); vehicle.setUserId(currentUserId()); vehicleMapper.insert(vehicle); return Result.ok(); }这段代码在答辩时可以被问到一个经典问题为什么绑定车牌号时要做重复校验因为车辆是用户的核心资产数据一辆车重复绑定会导致保养记录、提醒全部错乱。这个细节体现了你做事是否有数据一致性意识。3.2 保养计划自动计算的核心算法这个功能是整个项目的灵魂我花了最多时间在上面。保养计划的计算逻辑分为两步第一步根据用户的车型匹配出所有适用的保养项目第二步对每个保养项目判断当前车辆状态是否到期或即将到期。第二步的判断逻辑用一个简单的规则引擎来实现我定义了一个维护计划计算类输入是车辆实体和当前日期输出是到项目列表、即将到期列表和正常列表。每个保养项目都有一个保养周期里程和保养周期时间计算方式为判断是否到期当前里程数减去上次保养里程大于等于周期里程或者上次保养时间加上周期时间天数小于等于当前日期即视为到期。判断是否即将到期上述两个差值达到阈值的80%以上即视为即将到期。这里有个坑一定要提小保养的“上次保养时间”和“上次保养里程”应该只参考同等级的保养记录。比如全合成机油建议10000公里更换那对应的保养记录应该是“机油更换”这条记录而不是上一次做大保养的时间。很多毕设作者图省事直接取整台车的最近一次保养时间和里程这样计算出来的结果是不准的。我去做这个逻辑的时候在保养项目表里加了一个“依赖项目编号”字段比如“空调滤芯更换”依赖“常规保养”的记录没有就默认拿车辆的初始数据。计算代码的核心部分public MaintenanceCheckResult check(ListMaintenanceItem items, Vehicle vehicle) { LocalDate today LocalDate.now(); ListMaintenanceItem dueItems new ArrayList(); ListMaintenanceItem upcomingItems new ArrayList(); for (MaintenanceItem item : items) { // 获取上次执行该项目的记录 MaintenanceRecord lastRecord getLastRecord(vehicle.getId(), item.getId()); LocalDate lastDate lastRecord ! null ? lastRecord.getMaintenanceDate() : vehicle.getBuyDate(); BigDecimal lastMileage lastRecord ! null ? lastRecord.getMaintenanceMileage() : vehicle.getInitialMileage(); BigDecimal mileageGap vehicle.getCurrentMileage().subtract(lastMileage); long daysSince ChronUnit.DAYS.between(lastDate, today); boolean due mileageGap.compareTo(item.getCycleMileage()) 0 || daysSince item.getCycleDays(); boolean upcoming !due ( mileageGap.compareTo(item.getCycleMileage() * 0.8) 0 || daysSince item.getCycleDays() * 0.8); if (due) { dueItems.add(item); } else if (upcoming) { upcomingItems.add(item); } } return new MaintenanceCheckResult(dueItems, upcomingItems); }这段代码很有心思注意我乘0.8用的是“乘以0.8”在大数据量场景下应该改用BigDecimal的multiply方法上面代码为了简洁用了乘法运算符实际项目里我封装了计算工具类统一处理答辩时可以主动提到这个细节很加分。3.3 保养记录录入与订阅消息提醒保养记录录入页面是用户使用频次最高的部分我设计了四个必填字段保养项目、保养里程、保养时间、保养金额选填字段是备注和图片凭证。这里有一个交互坑保养里程只能大于上次保养里程时间不能早于购买时间也不能晚于今天。后端做校验的同时前端也做了校验避免用户提交一堆无效数据。提醒功能我用的是微信的订阅消息。这里需要特别注意订阅消息的用户授权是一次性的每次发送都需要用户在前端通过wx.requestSubscribeMessage授权一次。所以你在诱导用户授权的位置上要和业务结合好比如在用户添加保养记录、提交预约的时候顺带弹出订阅授权请求用户同意后你才保存订阅关系。服务端通过调用微信的subscribeMessage.send接口发送提醒。// 小程序端确认保养记录后请求订阅授权 wx.requestSubscribeMessage({ tmplIds: [your_template_id], success(res) { if (res[your_template_id] accept) { wx.showToast({ title: 提醒开启成功, icon: success }); } } });后端在定时任务中每天扫描一次用户的车辆数据把三日内到期保养的车辆查询出来通过预约表里的预约用户通知发送消息。一个细节发送内容里的关键词要精确匹配模板的字段要求比如“保养内容”“车辆名称”“到期日期”写错任何一个字段名都会报错。3.4 门店查询与预约模块的实现思路门店查询比较简单就是在地图上展示门店标记点点击弹出距离和详情。这里我用的是微信的map组件和腾讯位置服务SDK可以拿到经纬度和计算距离。预约模块则涉及一个状态机待确认、已完成、已取消。用户在门店详情页选择预约日期和时间段后端检查该时间段是否已被占用然后生成预约记录。状态机这块我建议使用一个简单的枚举类定义三个状态和允许的转换路径避免用户取消已完成订单这种bug出现public enum AppointmentStatus { PENDING(0, 待确认), COMPLETED(1, 已完成), CANCELLED(2, 已取消); }门店M端也需要简单的列表和详情页面所有数据都来自身后的API。这部分功能样式上不追求复杂重点是业务流程能走通。4. 论文与答辩让毕业设计更完整4.1 论文结构的组织方式论文不要按代码的行文来写要按系统的层次来写。我推荐的目录结构是绪论、相关技术概述、系统需求分析、系统设计、系统实现、系统测试、总结与展望。很多同学在写需求分析时只会罗列管理员和普通用户的功能没有分析用例图也没有画业务流程活动图这样“需求分析”就变成了“功能列表”老师一看就知道你没动过脑子。正确做法是在需求分析阶段先用用例图展示两类角色的所有用例再画一个车主从绑定车辆到完成预约保养的活动图把核心业务流转写清楚。到系统设计阶段重点画数据库ER图和核心计算流程图尤其要把保养周期判断流程图画出来。韦恩图和时序图不是必须的但一张好的活动图能帮你的论文提升一个档次。4.2 测试用例展示中容易被忽视的地方系统测试部分不能只写“功能正常”“页面显示正常”要有具体用例。我建议你在论文里放一张测试用例表格包含字段用例编号、测试模块、操作步骤、预期结果、实际结果。至少要覆盖以下核心用例新用户登录绑定车辆、绑定重复车牌号提示失败、录入保养记录后下次保养判断更新、订阅消息授权后推送通知、门店预约时间冲突提示、取消已预约订单。这里有一个答辩技巧测试数据要选得精妙不要只测正常流程。比如你把一辆车的当前里程设为9980公里保养周期10000公里刚好差20公里系统应该显示“即将到期”而不是跳过计算或显示超期。这比测10000公里本身更有说服力因为能体现你对边界值的思考。4.3 答辩现场的追问应对思路老师针对这类项目常问的问题我提前整理了应对思路你心里先有个底。第一个高频问题“你的微信登录是怎么识别用户的”答前端调用wx.login获取临时code后端用code加AppSecret调用微信接口获取openidopenid在小程序应用内是用户唯一标识存储到用户表中。第二个高频问题“如果用户换手机了他的车辆数据还在吗”答数据都在服务器端以openid为维度存储任何设备登录同一个微信号看到的都是同一份数据。第三个问题“保养周期为什么不直接写死在代码里”答不同车型、不同机油对保养周期的要求不同写在代码里会增加耦合改成数据库配置项后运营人员可以直接调整不需要重新发布小程序。这三个问题答顺了基本就能覆盖大部分质疑。5. 项目落地过程中的避坑指南与扩展方向5.1 我踩过的几个比较隐蔽的坑第一个坑是微信小程序的rpx换算。iPhone的375px设计稿里1rpx等于0.5px但到部分安卓大屏手机上rpx会自动放大导致个别按钮看起来特别大。这其实是正常的rpx的基准是整个屏幕宽度是750rpx所以不要纠结像素计算按设计稿写就可但要注意文字大小和边距不要全部用rpx有些地方用px做反而是对的例如1px的边框。第二个坑是地图组件的poi点击和自定义标记点冲突。我一开始用了map组件的markers属性和callout气泡设置callout的display为BYCLICK后发现点击后响应偶尔失效。后来改成用canvas绘制门店列表和地图上的覆盖物做视觉呈现问题就解决了。这个不讲清楚会让你在联调时浪费很多时间。第三个坑是后端时间字段类型和前端日期的序列化格式不一致。Spring Boot返回LocalDate默认是ISO格式小程序端new Date(2024-05-20)在iOS上是可以解析的但如果你用的是LocalDateTime默认输出是“2024-05-20T10:30:00”直接new Date它在iOS上会返回NaN然后页面显示一片空白。解决方式是统一在接口层把时间格式化为String“yyyy-MM-dd HH:mm:ss”前端按字符串处理再也不会有兼容问题。5.2 这个项目未来还能怎么扩展基础功能完成后如果你想往前再走一步有几个方向性价比非常高。第一个方向是做车辆保养费用统计和图表分析用小程序的echarts组件展示用户每年在保养上的花费趋势技术上会用到数据聚合论文里也能再补一层数据分析的内容。第二个方向是做预约提醒的自动电话或者短信通知但是需要接入第三方短信平台价格不需要担心毕设阶段用免费的订阅消息就够。第三个方向是把保养项目库接一个通用的车型适配规则解析用户车辆VIN码自动识别车型这样用户的绑定流程会变成扫一个行驶证体验提升很大。这个项目的天花板其实很高从“车辆保养记录工具”往上做可以变成一个“用车全生命周期服务平台”后续加油、洗车、年检、保险提醒都可以往里面加模块。但反过来如果你只有两周时间就死磕我前面说的六张表和一条保养计算逻辑把演示跑顺把论文写透分数照样不会低。最后再多说一句。从带毕设的视角看我见过太多人在项目管理上翻车一上来就非要做个门户网站加管理系统加小程序三端最后一个月全部崩溃。记住毕业设计的核心不是代码量而是你把它讲成一个完整的故事用户痛点、系统方案、技术实现、测试验证这四段讲明白就已经很成功了。代码只是把这个故事变成能运行的作品而已。
