上个月帮一家汽修门店把预约流程搬到微信里做了套基于微信小程序实现汽车预约维修系统。老板最开始的需求很朴素别再整天接电话说“师傅排满了”后来做着做着发现这套系统要管的不只是“一个表单加一个列表”而是用户、车辆、服务项目、时间槽位、订单状态、消息通知加一块的完整业务闭环。如果你是准备拿这个选题做毕业设计或者想练手一套完整的小程序项目它会比商城类系统更合适。它没有复杂的支付和库存但同样能覆盖微信登录、数据请求、表单校验、管理端接口、系统测试这些高频考点也容易写进论文里。下面就把这套系统的业务设计、小程序端实现、后端建模和论文写法一起拆开讲。1. 先把业务链路想清楚预约维修系统到底解决什么问题1.1 用户视角从“打电话碰运气”到“在线约时间”过去车主做维修保养要么翻通讯录找电话要么直接开车到店排队。电话接不通、现场没工位的情况非常常见。对小店来说这是客户流失对车主来说体验也很差。小程序的预约系统首先解决的就是“确定性”把服务项目、价格、时段、门店有没有空位提前暴露给用户用户提交预约后后台可以立刻确认或拒绝。所以首页不能只是一个漂亮的门面至少要有门店信息、服务项目列表和一个醒目的预约入口。用户点预约后依次完成车辆信息、服务项目、时间选择这三个核心步骤。每一步都要让用户明白为什么需要填车型和车牌用于到店核对和配件查询服务项目决定价格和预计工时时间决定他什么时候能来。页面上每个字段都给一句提示文案能大幅降低用户填到一半放弃的概率。1.2 门店视角从纸质登记到可视化排期门店端需要的功能比用户端更重。老板或前台要能查看所有预约并且能按日期、时段统计。常见操作是确认预约、取消预约、标记车辆到店、标记维修中、标记完工。如果门店有多个工位后台还需要给每个时间段设置最大预约数量避免某天所有车挤在同一个上午。这一块在毕设里经常被简化成“管理员后台”很多同学只做了个订单列表结果答辩时被问到“如果时段冲突怎么办”就答不上来。我的建议是哪怕不写完整的管理系统也要把“时段余量”这个概念放进设计文档。它直接决定了预约提交接口怎么实现也是论文里能够写深的地方。把余量规则想清楚了前后端的边界也就清晰了。1.3 核心状态流转订单从预约到完工预约订单不能只有“已提交/已完成”两个状态。实际业务里至少要拆成五个正常状态加一个取消状态。每个状态对应门店的一次操作也对应消息通知的触发点。待确认PENDING用户提交等待门店确认已确认CONFIRMED门店确认提醒车主按时到店已到店ARRIVED车辆到店开始接车检查维修中IN_SERVICE维修进行中可推送进度已完成COMPLETED维修完成通知取车已取消CANCELLED门店或用户取消订单为什么要做状态机因为后面所有统计、消息、权限都围绕它展开。比如订单列表页的“待确认”筛选管理员按钮的“接车”“完工”操作消息通知只在“已确认”“已完成”时触发。状态字段在数据库里可以用int或varchar但在业务代码里最好定义成枚举或常量不要在代码里满天飞“1”“2”“3”这种裸数字否则维护到后面自己都会搞混。2. 小程序端实现目录结构、页面组织和关键交互2.1 项目初始化与目录规划在微信开发者工具里新建项目时我建议选“不使用云开发”。云开发确实省事但预约系统有明确的服务端业务逻辑用自建后端更能讲清楚请求-响应的完整流程在论文里也更好画架构图。如果只是演示云开发也能做但部署和答辩时自建后端会更灵活。目录结构可以这样规划├── app.js # 全局登录态管理 ├── app.json # 页面注册、tabBar配置 ├── utils/ │ ├── request.js # wx.request统一封装 │ └── auth.js # 登录、token存取 ├── pages/ │ ├── index/ # 首页 │ ├── booking/ # 预约表单页 │ ├── order/ # 订单列表页 │ ├── order-detail/ # 订单详情页 │ └── mine/ # 个人中心 └── components/ └── service-card/ # 服务项目卡片页面为什么要这样拆因为它是顺着用户路径走的看到门店服务发起预约查看预约结果等待维修完成。预约表单是核心页订单列表和详情是预约后的留存首页负责引导个人中心放用户信息和“我的预约”入口。这种结构本身就能在论文功能模块图里直接复用。2.2 request请求封装统一处理登录与错误小程序开发第一件事是封装wx.request。不封装的话每个页面都会出现一长串success/fail回调后面改域名、加token、统一报错都会非常痛苦。我习惯用一个Promise化的request模块// utils/request.js const BASE_URL https://api.example.com; function request({ url, method GET, data {}, needAuth true }) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); const header { Content-Type: application/json }; if (needAuth token) { header[Authorization] Bearer token; } wx.request({ url: BASE_URL url, method, data, header, success(res) { if (res.statusCode 200) { resolve(res.data); } else if (res.statusCode 401) { // 登录过期走重新登录流程后面单独说 } else { wx.showToast({ title: res.data.message || 请求失败, icon: none }); reject(res); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request };这段代码虽然简单但把认证、请求、错误提示三件事统一了。后面新增接口时只需要传url、method、data页面代码会干净很多。2.3 首页与服务项目展示数据从哪儿来首页通常放门店横幅、服务项目列表、底部大按钮“立即预约”。服务项目数据不要写死在前端要从后端拉。拿到项目后渲染卡片点击卡片时把id和价格带进预约页。小程序端代码类似这样view classservice-list block wx:for{{serviceList}} wx:keyid service-card item{{item}} bind:taponSelectService / /block /view这里有个小细节点击卡片后如果用户还没登录不要直接跳预约页而是先走一遍wx.login登录流程再跳转。因为后面预约单里要写userId没有登录态订单根本建不起来。2.4 预约表单字段设计与时间选择预约表单是核心字段我建议这样设计姓名、手机号、车牌号、车型、里程数、服务项目、预约日期、时间段、备注。车型和车牌不是可选项因为维修保养要提前查配件和保养手册门店看到车牌往往能直接匹配车辆信息。小程序端要做手机号、车牌号的格式校验后端再做一次。时间选择是整个表单最麻烦的部分。简单用一个picker选日期和具体时刻只能保证“格式合法”不能保证“门店有空”。正确做法是日期picker只允许选择当天或开启预约后到未来7天选定日期后从后端请求该日期的可约时段前端用checkbox或radio渲染不可约的时段置灰。async function getAvailableSlots(date) { const res await request({ url: /appointment/slots, method: GET, data: { date } }); // res.data.slots: [{ label: 09:00-10:00, available: 3 }] this.setData({ slots: res.data.slots }); }按时间段而不是具体时刻还有一个好处门店可以自己配置一个时段允许多少台车能缓解预约集中在同一时刻的问题。这个设计写进论文的需求分析里比干贴几页页面截图有说服力得多。2.5 提交预约与拦截重复操作提交前要做前端校验手机号格式、车牌格式、是否选了服务项和时间段。但前端校验只是体验问题真正的校验必须放在后端再做一遍。前端提交时按钮一定要进入loading状态并加一个submitting标志防止用户连点几下产生一排相同的订单。// booking.js submitBooking() { if (this.data.submitting) return; this.setData({ submitting: true }); // 先做前端校验... request({ url: /appointment, method: POST, data: this.data.form }).then(res { if (res res.id) { wx.redirectTo({ url: /pages/order-detail/order-detail?id res.id }); } }).finally(() { this.setData({ submitting: false }); }); }这里用到的finally可能在某些基础库版本里有兼容问题但整体思路是对的请求结束必须复位按钮状态。真机上快速点击最容易触发这类bug测试时建议在开发者工具里把网络调成慢速再点几次。3. 后端接口与数据库设计把预约系统的心脏打好3.1 登录与用户识别openid不是密码小程序端调wx.login拿到code交给后端code2session接口换取openid和session_key。openid是用户在这个小程序里的唯一标识后端用它在user表里查记录没有就自动创建用户。这里有两个关键点openid绝不能直接返回给前端当身份凭证前端每次请求带的是后端签发的token后端根据token解析出userId。如果项目周期紧可以简化前端把code传到后端后端查完openid后直接生成随机token存到服务端并设置过期时间。要做到体验好一点可以存redis7天过期配合滑动续期。很多预约系统的安全问题追根到底都是登录态没做好所以这块值得多花点时间。3.2 数据库表设计五张核心表就够了预约系统不需要搞几十张表核心就是用户、车辆、服务项目、预约单、门店配置。下面给一个简化版建表SQL字段以够用为前提CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE, nickname VARCHAR(50), phone VARCHAR(20), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE vehicle ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, plate_no VARCHAR(20) NOT NULL, brand VARCHAR(30), model VARCHAR(50), mileage INT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE service_item ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, price DECIMAL(10,2) NOT NULL, duration INT NOT NULL COMMENT 预计工时单位分钟, description VARCHAR(255) ); CREATE TABLE appointment ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, vehicle_id INT NOT NULL, service_item_id INT NOT NULL, appoint_date DATE NOT NULL, time_slot VARCHAR(20) NOT NULL, status TINYINT NOT NULL DEFAULT 0, remark VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE shop_config ( id INT PRIMARY KEY AUTO_INCREMENT, slot_label VARCHAR(20) NOT NULL, slot_limit INT NOT NULL DEFAULT 1, current_count INT NOT NULL DEFAULT 0 );为什么车辆和用户要分开两张表因为一个用户可能有多辆车预约时选车牌还要能带出车型。如果把车辆信息直接塞进user表多车场景全部崩掉。服务项目单独一张表则方便门店调价、加项目不用动历史预约单。预约单里存了service_item_id和vehicle_id查询详情时要join两张表拿项目名称和车牌。为什么不直接把名称存进预约单因为门店改名后历史订单不应跟着变。所以保持关联字段展示时实时查这属于比较规范的做法。3.3 预约创建接口校验、锁、插入三步创建预约的接口是整个系统最重要的接口它必须回答一个问题这个时段还放不放得进车。我的建议是先确认时间段存在再判断该时段当前已约数量是否小于上限如果小于才允许插入。但直接“先查再插”有并发问题。两个用户同时提交都查到余量1结果都插入成功时段就超卖了。毕设项目可以不引入Redis用一个带条件的更新语句解决UPDATE shop_config SET current_count current_count 1 WHERE slot_label ? AND appoint_date ? AND current_count slot_limit;如果更新受影响行数为0说明这个时段已满直接返回“该时段已约满”。再把预约单插入和这个更新放在同一个数据库事务里保证要么都成功要么都失败。这个方案不复杂但能体现你对并发和数据完整性的理解答辩时也是一个加分点。3.4 订单列表与状态查询接口GET /appointment/list返回当前用户的预约列表按状态过滤、按创建时间倒序。状态值前端要维护一套映射0待确认、1已确认、2已到店、3维修中、4已完成、5已取消。前后端最好约定一个共用的状态文字字段后端返回statusText避免前端到处写包一层映射。管理员操作接口可以做成PUT /appointment/{id}/status请求体里带targetStatus。这里必须有权限判断不是所有人都能改订单状态至少要检查请求头里token解析出的用户is_admin是否为true。很多入门项目最容易漏掉的就是这个只用“页面隐藏按钮”代替权限校验这不对。4. 论文说明如何把系统写成一份合格的毕设文档4.1 论文框架不要从百度百科抄起手很多同学写论文喜欢先写小程序历史、B/S结构优势然后被老师打回。正确顺序是从问题出发绪论里讲汽车维修预约现状、电话预约痛点、线上预约的必要性相关技术章节不要太长介绍微信小程序、后端框架、MySQL即可每样控制在一两页。推荐技术栈不唯一常见组合是Spring Boot MyBatis-Plus MySQL小程序用原生开发。写技术选型时要说明为什么这么选比如Spring Boot生态成熟、资料多MyBatis-Plus能减少单表CRUD代码。要敢写“选择理由”别只写“它是什么”老师更想看到的是你的判断过程。4.2 需求分析关键是用例图和用例说明需求分析章节要分用户、管理员两个角色画用例图。用户用例包括注册登录、浏览服务项目、预约维修、查看订单、接收通知管理员用例包括登录、管理服务项目、查看预约、确认或取消预约、维护时段。别只放一张图每个核心用例再写一个用例描述表包括前置条件、基本流程、异常流程。比如“预约维修”用例的基本流程是用户选择日期时段填写车辆信息选择服务项目提交系统校验时段余量生成待确认订单。异常流程是时段已满、用户未登录、日期已过期。把这些写清楚后面系统设计部分只需要照着实现即可答辩也能讲得更踏实。4.3 系统设计架构图、模块图和E-R图这一章至少要有两张图系统架构图和数据库E-R图。架构图可以画用户-小程序-后端-数据库四层并标注HTTPS和JSON交互。数据库E-R图用实体关系表达五张核心表这个图既是论文亮点也会倒逼你把表关系理清。功能模块图可以按“小程序端、服务端、管理端”三个模块展开每个模块下列子功能。图不要用网上抄来的带水印截图会显得态度有问题建议自己用draw.io或ProcessOn画一遍。图里配色不要花哨黑白或统一色系最好打印出来也清楚。4.4 系统测试别只写“系统运行正常”测试章节是最容易凑字数也最容易被看穿的地方。建议列一张完整的测试用例表把功能测试和兼容性测试分开写。下面是一个可以直接抄作业的例子编号测试内容测试步骤预期结果实际结果TC01正常预约选择服务项、填写车辆信息、选时段、提交生成待确认订单通过TC02重复点击提交连续快速点击提交按钮只生成一条预约单通过TC03时段已满选择已被占满的时段提示“该时段已约满”通过TC04未登录访问订单清缓存后进入订单列表跳转登录或自动登录通过TC05管理员确认预约管理员点击确认订单状态变已确认通过TC06用户取消预约待确认状态下取消订单状态变已取消通过TC07网络异常断网提交预约提示网络异常不生成订单通过TC08日期校验选择过去日期无法选择或后端拒绝通过TC09车辆照片上传拍摄照片并上传图片显示在预约详情通过TC10订阅消息提交预约后授权状态变更时收到通知通过性能方面不用编造压测数据但可以提一下主要接口在开发环境下的响应时间比如“预约提交接口平均响应在300毫秒以内”这种结论要有测试工具截图支撑没有就不要写。5. 实测复盘开发中最容易翻车的几个地方5.1 真机调试先从“不校验合法域名”说起开发时在开发者工具里关掉“校验合法域名”后一切正常一上真机所有请求全部失败。这是因为真机上所有wx.request域名必须在小程序后台配置并且必须是HTTPS。如果你还没有正式域名测试阶段可以在开发者工具详情里勾选“不校验合法域名”但真机预览不能靠这个。最省事的办法是先用一个带HTTPS的测试域名后端先用IP加端口跑起来再通过内网穿透或部署到云服务器绑定域名。这个坑每个做小程序的人都会遇到提前知道能少半天时间。域名还需要ICP备案准备时间和提交审核的流程都要预留别拖到最后一周才开始弄。5.2 登录态过期与401重试用户隔天打开小程序token很可能已经过期。如果在request封装里直接提示“登录已过期”体验很差。我建议在401分支里做一次静默重登调用wx.login重新获取code后端重新下发token存到storage然后用新token重发刚才的请求。注意要加一个重试次数限制避免陷入死循环。简化写法可以参考function requestWithRetry(options) { return request(options).catch(err { if (err.statusCode 401 !options._retried) { return relogin().then(() request({ ...options, _retried: true })); } throw err; }); }有了这层处理用户基本感知不到登录过期。想做得更细可以在app.js启动时先检查token是否还在有效期内没登录就静默登录这样整个使用过程会非常顺。5.3 车辆照片上传与压缩预约时可以上传车辆照片或维修凭证。小程序端用wx.chooseMedia选择图片然后用wx.uploadFile走formData上传。这里有两个坑一是chooseMedia基础库版本要求2.10.0老手机可能不支持要降级用wx.chooseImage二是图片原图可能5MB以上上传慢、失败率高。建议先压缩再传。我用canvas方案做压缩把图片画到canvas上再通过wx.canvasToTempFilePath输出压缩后的图片。不需要引入额外SDK小程序原生就能做。上传接口返回图片URL再把URL和其他表单字段一起提交建单。这个流程最好在测试机上多验证不同机型压缩参数会有差异。5.4 订阅消息的设计一次性订阅别乱用预约系统很依赖消息通知预约成功、门店确认、维修完成。小程序订阅消息和公众号模板消息不一样默认用户每次授权只能接收一条。我踩过的坑是在预约页提前让用户授权订阅结果用户授权后没到触发点后面真正要发通知时可用次数已经没了页面却以为已经授权过。正确做法是尽量在关键动作后弹窗授权比如提交预约成功后引导用户点击“允许”然后再调用订阅消息接口。像门店改状态这种需要多次通知的场景要申请长期订阅消息模板或者明确告诉用户每次都得手动订阅。毕设演示时选一个“确认预约”模板把流程打通就行别一次接太多模板容易把自己绕晕。5.5 日期选择与门店时段配置预约日期picker如果直接把过去的日期都放开用户约到昨天就会闹笑话。前端可以在picker的start属性设为今天end设为未来30天。但这还不够后端一样要校验appoint_date不能早于当天。因为前端传的参数可以被直接修改不要相信前端传什么都是合法的。门店时段配置建议做成一张表而不是写死在前端。简单方案是shop_config里存slots字段用JSON格式保存时段信息[09:00-10:00,10:00-11:00,...]。小程序端拿到后渲染成可选标签管理员想临时关闭某个时段直接后台删掉这个时段即可。如果你测试时发现预约日期总是差一天大概率是日期字符串被当成UTC处理了格式化时要显式使用本地时区。做这套系统时我最大的体会是预约维修这个场景难点不在代码量而在把业务约束翻译成数据和接口设计。比如时段余量、订单状态机、登录态每一处都是提前想清楚比事后补bug划算得多。如果你也打算做类似项目建议先把状态流转表和时段余量规则写出来再动工写代码。最后再分享一个小技巧开发阶段把用户反馈收集入口放小程序个人中心里哪怕只是一段联系方式文本后期调优时也能少走很多弯路。