简介该资源为基于微信小程序的驾校预约管理系统毕业设计配套答辩PPT面向计算机相关专业准备毕业设计答辩的本科生尤其适合以小程序、信息管理系统为选题的同学。内容围绕系统首页、个人中心、学员与教练管理、驾校信息与车辆管理、教练预约、考试信息与预约考试管理、系统管理等模块展开并涵盖课题背景、研究现状、功能结构图、各角色界面展示与总结等答辩必备环节可直接用于梳理汇报思路、对照自身系统查漏补缺。压缩包共1个文件为ppt格式大小约1.79MB体积轻便便于携带与修改。目前已有93人学习下载可作为答辩模板与选题参考。读者可从中获得完整的答辩页面组织框架、功能模块划分逻辑以及管理员、学员、教练三类角色的权限设计思路对撰写论文与准备讲解均有实际帮助。1. 驾校预约的难点不在「预约」在「时段」驾校预约这件事表面看是信息展示真正难的是时间。一个教练一天只有几个可约时段一辆教练车同一时刻只能带一个学员学员点下「预约」按钮那一刻系统要判断的是这个时段还在不在、这辆车有没有被占、这个人有没有爽约记录而不是把一张申请表塞进数据库就算完。这份基于微信小程序的驾校预约管理系统答辩PPT连同配套源码与论文围绕的正是这条主线把驾校、教练、车辆、考试这几类资源收进一套有角色、有状态、有冲突校验的流程里。它适合正在准备计算机毕业设计、需要一份能把「为什么这么设计」讲清楚的人也适合带课程设计、想给学生一个可复用骨架的老师。下面按需求、架构、数据、实现、避坑、验收的顺序拆开讲。2. 技术选型与总体架构小程序端加 Web 后台的双端结构2.1 为什么学员端是微信小程序管理端却回到网页选型这一步最容易被答辩老师追问而很多人的回答只有一句「小程序方便」。方便在哪要说得具体。学员用这套系统的频次其实很低报名前看驾校信息、报名后一周约两三次车为一个低频场景装一个 App卸载率会高得离谱小程序搜一下、扫一下就能进登录走微信授权拿 openid连注册表单都省了这是它最实在的价值。教练端同理他一天要做的动作只有「看今天谁约了我」和「确认或驳回」手机上一屏能放下放小程序里正合适。但管理端不能这么做。管理员要批量导入学员名单、按日期导出预约记录、对照车辆维修状态改可约时段这些操作在六寸屏上是灾难。所以这套系统是双端的学员和教练在小程序里管理员在 PC 浏览器里的 Web 后台两边共用同一套后端接口和同一个 MySQL 库也就是原文说的 B/S 结构。后端语言原文没有硬性规定通常的做法是 Java 那套Spring Boot 或 SSM 都行配 MySQL接口返回 JSON小程序用wx.request调后台页面用 Ajax 调换成 PHP 或 Python 也只是换一层皮表结构和状态机是不动的。提示答辩时说「双端」比说「小程序」更稳。老师问「为什么不全做成小程序」答案不是技术做不到而是管理动作的信息密度和屏幕不匹配。2.2 三层结构下三类角色的权限边界整体是标准三层表现层管页面渲染和交互业务层管预约校验、状态流转、名额扣减数据层管表和 SQL。真正需要写进 PPT 的是权限这一层因为原文明确说了「管理员、学员、教练能看到及操作的信息不一样」这句话背后是一张权限矩阵而不是三个不同的登录页。模块管理员学员教练驾校信息增删改查只读、收藏只读教练管理增删改查只读选教练只能改自己的资料与时段车辆管理增删改查只读看车型只读看自己绑定的车教练预约全量查看、强制取消创建、取消自己的确认、驳回、完成自己的考试信息发布场次、设名额只读只读预约考试全量查看报名、取消自己的无系统管理公告、管理员账号无无这张表要落到代码里不能只落到 PPT 上。常见的翻车做法是前端把没权限的按钮hidden掉接口却谁调都通答辩时老师用 Postman 直接打一个删除接口就露馅了。正确的做法是后端加一层拦截器从 token 里取出角色比对当前请求路径需要的角色不匹配直接返回 403。// 角色拦截器路径前缀 - 允许的角色集合 public class RoleInterceptor implements HandlerInterceptor { private static final MapString, SetString RULES new HashMap(); static { RULES.put(/api/admin/, Set.of(ADMIN)); // 后台管理接口只允许管理员 RULES.put(/api/coach/, Set.of(COACH, ADMIN)); // 教练操作接口 RULES.put(/api/student/,Set.of(STUDENT, ADMIN));// 学员操作接口 } Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws IOException { String role (String) req.getAttribute(role); // 由登录拦截器提前解析 token 写入 String uri req.getRequestURI(); for (Map.EntryString, SetString e : RULES.entrySet()) { if (uri.startsWith(e.getKey()) !e.getValue().contains(role)) { resp.setStatus(403); // 越权直接拒绝不返回业务数据 resp.getWriter().write({\code\:403,\msg\:\no permission\}); return false; } } return true; } }这段代码的关键在RULES这张静态表它把「路径前缀」和「角色集合」绑死新增接口时只要路径落在约定前缀下权限自动生效不依赖开发者记得加注解。role从哪来是登录成功后写进 token 的载荷登录拦截器解析完放进request属性两个拦截器一前一后顺序不能反。ADMIN在学员和教练前缀里都出现是因为管理员需要能代操作这一点在权限矩阵里没体现但代码里必须留口子否则后台的「代学员取消预约」做不了。2.3 功能结构图怎么画才经得起追问原文列了十个模块首页、个人中心、学员管理、教练管理、驾校信息管理、驾校车辆管理、教练预约管理、考试信息管理、预约考试管理、系统管理。十个方块平铺在一页 PPT 上看着整齐其实讲不出逻辑。我的做法是按「信息展示—预约事务—后台维护」分三组每组对应一条业务线结构图从上到下三层一页放得下讲的时候也有顺序。信息展示组解决「不知道去哪学」首页轮播与公告、驾校信息详情、教练列表与教练详情、车辆展示。预约事务组解决「约不上、约重了」教练预约、预约考试这两个是系统里唯一会产生状态变更的模块也是数据库设计的主战场。后台维护组解决「谁来管」学员、教练、车辆、考试场次、公告和管理员账号的增删改查。分组之后结构图上的连线就有了含义——信息组是只读的事务组要读写状态维护组控制前两组的输入。注意结构图里的每个方框都要能在后面的界面截图和代码目录里找到对应物。找不到的直接删掉别为了图好看硬加。3. 数据库设计九张表撑起「人、车、场、考」四条线3.1 核心表与字段取舍这个系统的数据实体其实就四类人学员、教练、管理员、车教练车、场教练的可约时段、考考试场次与报名。落到表上我一般会建九张student、coach、admin、vehicle、school_info、coach_booking、exam_info、exam_booking、notice。九张表不算多但每张的字段要想清楚尤其是状态字段和冗余字段。学员表除了基本信息必须有一个openid字段做唯一索引它是小程序的登录凭据比手机号可靠——学员换号很常见openid 不会变。subject记录当前考到科目几这个字段看着没用其实决定了教练列表的过滤逻辑科目二的学员不该看到只教科目的教练。教练表里car_id是外键指向车辆一辆车绑一个教练这样查「这个教练今天开哪辆车」不用再关联。预约表的字段设计是重点。coach_booking里我把日期和时间拆成book_dateDATE、start_timeTIME、end_timeTIME三个字段而不是存两个 DATETIME。原因是冲突判定要按「同一天同一时段」比对拆开之后索引能直接用SQL 写起来也直观如果存成一整段 DATETIME判定时要写一堆范围比较索引还容易失效。-- 教练预约表日期与时段拆开存便于冲突判定和索引命中 CREATE TABLE coach_booking ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL COMMENT 学员ID, coach_id BIGINT NOT NULL COMMENT 教练ID, vehicle_id BIGINT NOT NULL COMMENT 分配的教练车, book_date DATE NOT NULL COMMENT 预约日期, start_time TIME NOT NULL COMMENT 开始时间按30分钟对齐, end_time TIME NOT NULL COMMENT 结束时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待确认 1已确认 2已完成 3已取消 4爽约, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, -- 同一位教练、同一天、同一开始时间只能有一条有效记录 UNIQUE KEY uk_coach_slot (coach_id, book_date, start_time), KEY idx_student (student_id, book_date), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_coach_slot这个唯一索引是整个系统最便宜的一道防线。它保证同一个教练在同一天的同一个开始时间上数据库层面只可能存在一条记录不管前端怎么点、接口怎么被并发调用。idx_student服务于学员端「我的预约」列表idx_status服务于教练端「待我确认」的筛选这两个索引不加数据量稍微上来一点列表就开始转圈。字段类型上status用 TINYINT 不用 VARCHAR省空间也方便用status 1这种条件走索引。3.2 时段冲突唯一索引加事务两道锁一起上冲突判定是这个系统里唯一有技术含量的地方也是答辩时最值得展开讲的一段。要做到「一个教练一个时段只能被约一次」光靠前端把已约时段置灰是不够的两个人同时打开页面看到的是同一份空闲列表同时点提交两条请求打到后端谁先谁后全看运气。这时候靠的就是数据库。第一道是唯一索引。上面的uk_coach_slot会在插入时直接抛DuplicateKeyException捕获之后返回「该时段已被预约」业务层连查都不用查。第二道是事务加行级锁用于考试报名这种有名额扣减的场景后面第 4 章会展开。两道防线的关系是唯一索引兜底事务保证业务一致性前者防重复后者防超卖。-- 查询某教练某天的可约时段已被占用的时段直接排除 SELECT t.slot_start FROM coach_slot_template t -- 教练的排班模板表存固定可约时段 WHERE t.coach_id #{coachId} AND t.week_day DAYOFWEEK(#{bookDate}) -- 按星期几取排班 AND NOT EXISTS ( SELECT 1 FROM coach_booking b WHERE b.coach_id t.coach_id AND b.book_date #{bookDate} AND b.start_time t.slot_start AND b.status IN (0, 1, 2) -- 待确认/已确认/已完成 都算占用 ) ORDER BY t.slot_start;这段 SQL 有两个容易写错的地方。一是status IN (0,1,2)这个条件取消3和爽约4的记录不能算占用否则一个时段被约了又取消就永远放不出来了这是最典型的一类 bug。二是排班模板必须单独建表如果直接按「早八点到晚六点每半小时一格」硬编码生成教练请假、车辆维修这些情况就无从表达系统会显得很假。模板表按coach_id week_day存教练在小程序端改自己的排班管理员在后台能覆盖两层控制刚好。3.3 预约状态机与取消规则状态字段最怕没人管谁都能改最后数据库里全是status 1。这套系统里我给教练预约定了五个状态和固定的流转方向学员提交后是「待确认」教练在小程序端点确认变「已确认」或驳回变「已取消」学员练完车教练点完成变「已完成」学员没到场则记「爽约」。管理员有强制取消的权限但要留操作日志。当前状态触发动作操作者流转到待确认(0)教练确认教练已确认(1)待确认(0)教练驳回 / 学员取消教练 / 学员已取消(3)已确认(1)教练标记完成教练已完成(2)已确认(1)学员取消需提前2小时学员已取消(3)已确认(1)超时未到系统定时任务爽约(4)「提前两小时才能取消」这条规则要写在业务层不能只写在前端提示里。实现方式是在取消接口里比对book_date start_time与当前时间小于两小时直接拒绝。爽约状态的自动流转用一个定时任务扫每天凌晨扫一遍昨天已确认但未完成的记录改成爽约。这个定时任务在答辩时是个加分项因为它说明你想过「没人操作的时候系统该做什么」。4. 核心模块实现从选时段到落库的完整链路4.1 首页与驾校信息低频场景下的加载策略首页是学员进来看到的第一屏它要回答三个问题这个驾校靠不靠谱、我该找哪个教练、我之前约的课还在不在。对应四个区块顶部轮播和公告中间驾校信息卡片下面教练推荐列表最底下是「我的最近预约」。公告和轮播从notice表取按时间倒序取前五条不要一次把全表拉下来这是新手最常见的性能坑。驾校信息详情页的图片是大头一个驾校放八九张训练场照片很常见。小程序端必须做懒加载和尺寸限制modeaspectFill配合固定高度不然列表滚动会卡成幻灯片。原文提到「页面调用方式」和「页面设计美化程度」是系统的短板其实短板不在美化在图片没有压缩、列表没有分页。分页参数统一用page和pageSize默认一页十条后端用LIMIT拼前端用onReachBottom触发下一页。// pages/school/list.js —— 驾校列表分页加载 Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onLoad() { this.fetchList(); }, onReachBottom() { // 触底加载下一页 if (!this.data.hasMore || this.data.loading) return; // 防止重复请求 this.setData({ page: this.data.page 1 }); this.fetchList(); }, fetchList() { this.setData({ loading: true }); wx.request({ url: ${getApp().globalData.baseUrl}/api/school/list, data: { page: this.data.page, pageSize: this.data.pageSize }, success: (res) { const rows res.data.data || []; this.setData({ list: this.data.list.concat(rows), // 追加而非覆盖 hasMore: rows.length this.data.pageSize // 返回条数不足一页说明到底了 }); }, complete: () this.setData({ loading: false }) }); } });hasMore的判断依据是「本次返回条数是否等于 pageSize」这个写法比让后端返回总数简单缺点是最后一页刚好满页时会多请求一次空列表。如果要精确可以让后端在响应里带total前端算page * pageSize total。loading这个标志位不能省onReachBottom在快速滑动时会连续触发好几次没有它就会出现重复数据和页码错乱这个坑我在早期项目里踩过不止一次。4.2 教练预约三段选择到一次落库教练预约的交互是一条直线选教练 → 选日期 → 选时段 → 填备注 → 提交。前两步是纯查询第三步依赖教练排班和已有预约算出来的空闲列表第四步才是写。很多毕设把这一段做成「选完教练直接弹出日期选择器」看起来省事实际学员根本不知道哪天有车选完发现全满体验极差。正确的顺序是先看教练的排班日历有空的日期高亮点进去再看具体时段。提交时的接口设计要注意两点一是把coachId、bookDate、startTime一起传后端不要去信任前端算出来的endTime时长由教练的排班模板决定前端传什么都是参考二是接口必须幂等同一个学员重复点击提交应该返回「您已有该时段的预约」而不是插两条。// pages/booking/create.js —— 提交预约 submit() { const { coachId, bookDate, startTime } this.data.form; if (!coachId || !bookDate || !startTime) { return wx.showToast({ title: 请选择完整时段, icon: none }); } wx.showLoading({ title: 提交中 }); wx.request({ url: ${getApp().globalData.baseUrl}/api/booking/coach, method: POST, header: { Authorization: wx.getStorageSync(token) }, // 登录态 data: { coachId, bookDate, startTime, remark: this.data.form.remark }, success: (res) { if (res.data.code 200) { wx.showToast({ title: 预约成功等待教练确认 }); wx.navigateBack(); // 返回上一页列表在 onShow 里刷新 } else if (res.data.code 409) { wx.showToast({ title: 该时段刚被约走换一个吧, icon: none }); this.loadSlots(); // 冲突时立即重新拉取可约时段 } else { wx.showToast({ title: res.data.msg || 提交失败, icon: none }); } }, complete: () wx.hideLoading() }); }这段代码里code 409的分支是精髓。用户在这一页停留几分钟很正常期间时段被别人约走是必然会发生的事遇到冲突不能只弹一句「失败」要把可约列表重新拉一遍让用户当场换一个而不是退出去重来。Authorization头带 token 是后端识别学员身份的依据取不到就直接 401前端统一跳登录不要在每个页面里各写一套判断。后端接住这个请求之后动作顺序是校验学员状态有没有被拉黑、有没有未处理的爽约→ 查教练排班确认这个时段合法 → 查车辆占用 → 插入记录 → 捕获唯一键冲突 → 返回。中间任何一步失败都要回滚所以方法上要加事务注解。插入成功之后可以顺手发一条订阅消息给教练这一步在小程序里用wx.requestSubscribeMessage拿授权虽然毕设里经常省略但写进 PPT 的「流程完整度」里很占便宜。4.3 考试预约和教练预约完全是两套逻辑很多人在答辩时把教练预约和考试预约讲成一回事这是要扣分的。两者的资源模型不同教练预约是「一个教练一个时段一个人」互相独立考试预约是「一个场次 N 个名额先到先得」存在名额竞争。前者靠唯一索引解决后者必须靠行锁扣减。-- 考试报名先扣名额扣成功再插报名记录两条语句在同一个事务里 START TRANSACTION; UPDATE exam_info SET remain remain - 1 WHERE id #{examId} AND remain 0; -- 条件里带 remain 0防止扣成负数 -- 影响行数为 0 说明名额已抢完业务层直接回滚并返回「名额已满」 -- 影响行数为 1 才继续插入报名记录 INSERT INTO exam_booking (exam_id, student_id, status, book_time) VALUES (#{examId}, #{studentId}, 0, NOW()); COMMIT;WHERE remain 0这个条件是防超卖的关键它把「判断」和「扣减」合并成了一条原子语句不需要先SELECT查一遍再UPDATE。数据库在这个 UPDATE 上会加行锁两个并发请求排队执行第二个执行时remain已经是 0条件不成立影响行数为 0直接失败。如果先查后改中间的空隙足够另一个请求插进来两个人就都报名成功了这就是典型的超卖。原文提到系统在执行效率上有欠缺、考虑过存储过程其实这个场景用不着存储过程一条带条件的 UPDATE 就够了。对比项教练预约考试预约资源单位教练 × 时段考试场次 × 名额冲突维度同一教练同一时段不可重复全场次名额共享核心手段唯一索引条件 UPDATE 行锁取消影响释放时段他人可约名额回加remain 1谁发布教练排班模板管理员发布场次4.4 后台管理三套菜单背后的数据范围后台是小程序之外的另一半管理员登录后看到的是全量数据教练登录后只能看到自己名下的学员和预约。实现上有两种做法一是写两套页面二是同一套页面按角色渲染不同菜单、接口按角色过滤数据范围。我选后者因为维护成本低而且答辩演示时切换账号就能展示权限差异效果直接。数据范围的控制放在业务层的查询条件里不是在 SQL 里写死。做法是从登录态里取coachId如果当前角色是教练就给查询条件加上AND coach_id #{currentCoachId}管理员不加这个条件。这个判断放在 Service 层的一个方法里统一处理不要在每个 Mapper 里各写一遍否则迟早有一条漏掉。菜单渲染则是后端返回一个权限码数组前端按码决定显示哪几项但正如前面说的这层只是展示真正的拦截在接口。车辆管理这个模块容易被做薄。原文提到「驾校车辆管理对驾校车辆信息进行管理包括车辆的状态和预约情况」状态至少要有「可预约、使用中、维修保养」三种维修中的车不能被排进教练的可约时段。这个联动如果没做系统就只是个增删改查的壳子做了之后才算有点业务味道。做法是在教练排班查询那一步关联车辆表过滤掉维修状态的车。5. 避坑与常见问题排查五个最容易在答辩现场翻车的点5.1 现象两个学员约上了同一个教练同一时段原因基本只有一种冲突判定放在了前端或者后端判了但没加唯一索引。前端置灰只能防君子两个人同时打开页面拿到的都是「空闲」的旧数据一起提交就都成功了。还有一种更隐蔽的情况判定用了SELECT COUNT(*)再if判断中间没有事务隔离并发下照样穿过去。解决分三层一起做。数据库层加uk_coach_slot唯一索引这是最后的保险业务层把「查—判—插」包进一个事务插入时捕获DuplicateKeyException接口层对这类冲突返回明确的 409 状态码前端拿到 409 就刷新时段列表。三层做完即使有人拿工具压测也穿不过去。答辩时如果老师问「你怎么保证不重复预约」把这三层说出来比说「我加了判断」有说服力得多。5.2 现象学员提交成功了教练端一片空白先查状态字段。最常见的是插入时status默认值设成了 0待确认而教练端的列表查询条件写的是status 1两边对不上数据在库里躺着但谁也看不见。第二种是日期格式book_date存的是 DATE前端传的是2024-05-01字符串后端如果没做转换可能被当成2024-05-01 00:00:00查询时用和比较就漏了。排查顺序我一般是这样先在数据库里SELECT * FROM coach_booking ORDER BY id DESC LIMIT 5看记录到底进没进进了就看status和coach_id对不对都对就去看教练端接口打印的 SQL 条件十有八九是条件多写了一个。这类问题不要在前端调前端只能告诉你「没数据」真相永远在服务端日志里。注意调试期把 MyBatis 的 SQL 日志打开logging.level.xxx.mapperdebug能看到最终执行的语句和参数比盲猜快十倍。5.3 现象一进页面就 401或者登录后过一会又掉线小程序端的登录态是自己维护的wx.login拿到的 code 要发给后端换 openid后端生成 token 返回来前端存进wx.setStorageSync。三个环节都可能断code 只能用一次重复用会失败token 存了但请求头没带token 过期了没有续期机制。处理办法是封装一个统一的请求方法所有接口都走它在里面统一加Authorization头统一拦 401401 就清掉本地 token 重新走登录。最忌讳的是每个页面自己写wx.request加头的地方漏一个那个页面就永远是 401。另外wx.login的调用时机也要注意放在app.js的onLaunch里别放在页面onLoad否则每进一个页面都登一次。5.4 现象时间显示差八小时或者跨天时段算错这个坑非常经典。数据库存的是DATETIMEJava 里用Date接JSON 序列化默认按 UTC 输出小程序端new Date()一解析就少了八小时。表面看是时区问题实际是序列化配置没设。解决办法是在配置文件里把时区固定住Jackson 加spring.jackson.time-zoneGMT8和日期格式JDBC 连接串里加serverTimezoneAsia/Shanghai两头对齐。跨天时段是另一个坑。如果教练排班允许晚上十点到十一点这种时段book_date记的是开始那天start_time是 22:00判断「是否已过期」时直接拿book_date和今天比就会出错。稳妥的做法是查询时把两个字段拼成完整时间再比或者干脆在表里冗余一个start_datetime字段专供比较用用空间换清晰。5.5 现象演示当天数据全乱或者服务起不来答辩现场最怕的不是功能少是演示不了。数据乱通常是前几天测试时反复增删留下的脏数据预约表里全是状态为 0 的记录列表一打开就是几十条待确认。服务起不来多半是数据库没起、端口被占、或者配置文件里的连接串还是本地局域网的 IP。我的习惯是准备一份init.sql里面包含建表语句和一批干净的演示数据三个教练、五辆车、两个学员、一个管理员预约记录留两条待确认的。演示前把库 drop 掉重新跑一遍脚本三十秒恢复到已知状态。另外准备一份离线录屏网络断了或者投影出问题就放录屏别在台上跟环境较劲。6. 验收与答辩把 PPT 讲成一份可被追问的方案答辩 PPT 不是界面截图的堆砌它要证明你走过一遍完整的工程流程。十一页左右刚好页序我一般这么排封面、选题背景与痛点、角色与需求分析、功能结构图、技术选型与架构、数据库设计E-R 加核心表、核心流程教练预约的时序、界面展示、难点与解决、不足与改进、结束页。每页只讲一句话这句话必须是你想让老师记住的那句。页序内容这一页要说的一句话1封面系统名、姓名、学号、指导教师2背景与痛点传统电话约车信息不透明时段冲突靠人工记3角色与需求三类角色权限边界在接口层而非按钮层4功能结构图十个模块分三组只有预约组会改状态5技术选型学员教练用小程序管理员用 Web 后台6数据库设计九张表预约表用唯一索引防重复7核心流程从选时段到落库冲突返回 409 并刷新8界面展示选三张最能体现流程的不要放九宫格9难点与解决并发重复预约、名额超卖、登录态10不足与改进多管理员账号、消息通知、页面性能11结束页致谢不写「请老师批评指正」以外的废话第 10 页要主动说不足这一点很多人不敢做其实反着来更稳。原文自己就列了问题数据库存储过程用得不够、页面美化程度一般、窗口刷新有问题、不能添加多个管理员账号。把这些摆出来再补一句「如果要继续做我会先做消息通知和多管理员」老师就没得问了因为他想问的你已经自己说了。主动暴露问题的答辩比全程完美的演示更让人信服。现场演示走最短路径五个动作管理员登录后台 → 新增一个教练并绑定车辆 → 切到学员端小程序预约这个教练 → 切到教练端确认 → 回后台看预约记录变成已确认。整条链路两分钟内走完比逐个模块点一遍强得多。每个动作做完停一秒让老师看清楚页面变化别急着往下点。如果时间允许再补一个「重复预约被拦截」的反向演示效果比正向演示还好。高频问题就那么几个为什么不用 App、为什么不全做成小程序、数据库为什么这么设计、并发怎么处理、你的工作量在哪。前四个前面几章都有答案第五个最好提前准备好说辞——工作量不在页面数量在于把一套没有状态的信息展示系统改造成了有角色、有状态、有冲突校验的流程系统。这句话说出来基本就稳了。从那以后我每次带人做这类毕设都强制他们先跑一遍「登录到确认」的最短路径跑通了再谈美化和扩展跑不通就先别动界面。这个顺序反过来后面全是返工。希望帮到你。本文还有配套的精品资源点击获取
简介该资源为基于微信小程序的驾校预约管理系统毕业设计配套答辩PPT面向计算机相关专业准备毕业设计答辩的本科生尤其适合以小程序、信息管理系统为选题的同学。内容围绕系统首页、个人中心、学员与教练管理、驾校信息与车辆管理、教练预约、考试信息与预约考试管理、系统管理等模块展开并涵盖课题背景、研究现状、功能结构图、各角色界面展示与总结等答辩必备环节可直接用于梳理汇报思路、对照自身系统查漏补缺。压缩包共1个文件为ppt格式大小约1.79MB体积轻便便于携带与修改。目前已有93人学习下载可作为答辩模板与选题参考。读者可从中获得完整的答辩页面组织框架、功能模块划分逻辑以及管理员、学员、教练三类角色的权限设计思路对撰写论文与准备讲解均有实际帮助。1. 驾校预约的难点不在「预约」在「时段」驾校预约这件事表面看是信息展示真正难的是时间。一个教练一天只有几个可约时段一辆教练车同一时刻只能带一个学员学员点下「预约」按钮那一刻系统要判断的是这个时段还在不在、这辆车有没有被占、这个人有没有爽约记录而不是把一张申请表塞进数据库就算完。这份基于微信小程序的驾校预约管理系统答辩PPT连同配套源码与论文围绕的正是这条主线把驾校、教练、车辆、考试这几类资源收进一套有角色、有状态、有冲突校验的流程里。它适合正在准备计算机毕业设计、需要一份能把「为什么这么设计」讲清楚的人也适合带课程设计、想给学生一个可复用骨架的老师。下面按需求、架构、数据、实现、避坑、验收的顺序拆开讲。2. 技术选型与总体架构小程序端加 Web 后台的双端结构2.1 为什么学员端是微信小程序管理端却回到网页选型这一步最容易被答辩老师追问而很多人的回答只有一句「小程序方便」。方便在哪要说得具体。学员用这套系统的频次其实很低报名前看驾校信息、报名后一周约两三次车为一个低频场景装一个 App卸载率会高得离谱小程序搜一下、扫一下就能进登录走微信授权拿 openid连注册表单都省了这是它最实在的价值。教练端同理他一天要做的动作只有「看今天谁约了我」和「确认或驳回」手机上一屏能放下放小程序里正合适。但管理端不能这么做。管理员要批量导入学员名单、按日期导出预约记录、对照车辆维修状态改可约时段这些操作在六寸屏上是灾难。所以这套系统是双端的学员和教练在小程序里管理员在 PC 浏览器里的 Web 后台两边共用同一套后端接口和同一个 MySQL 库也就是原文说的 B/S 结构。后端语言原文没有硬性规定通常的做法是 Java 那套Spring Boot 或 SSM 都行配 MySQL接口返回 JSON小程序用wx.request调后台页面用 Ajax 调换成 PHP 或 Python 也只是换一层皮表结构和状态机是不动的。提示答辩时说「双端」比说「小程序」更稳。老师问「为什么不全做成小程序」答案不是技术做不到而是管理动作的信息密度和屏幕不匹配。2.2 三层结构下三类角色的权限边界整体是标准三层表现层管页面渲染和交互业务层管预约校验、状态流转、名额扣减数据层管表和 SQL。真正需要写进 PPT 的是权限这一层因为原文明确说了「管理员、学员、教练能看到及操作的信息不一样」这句话背后是一张权限矩阵而不是三个不同的登录页。模块管理员学员教练驾校信息增删改查只读、收藏只读教练管理增删改查只读选教练只能改自己的资料与时段车辆管理增删改查只读看车型只读看自己绑定的车教练预约全量查看、强制取消创建、取消自己的确认、驳回、完成自己的考试信息发布场次、设名额只读只读预约考试全量查看报名、取消自己的无系统管理公告、管理员账号无无这张表要落到代码里不能只落到 PPT 上。常见的翻车做法是前端把没权限的按钮hidden掉接口却谁调都通答辩时老师用 Postman 直接打一个删除接口就露馅了。正确的做法是后端加一层拦截器从 token 里取出角色比对当前请求路径需要的角色不匹配直接返回 403。// 角色拦截器路径前缀 - 允许的角色集合 public class RoleInterceptor implements HandlerInterceptor { private static final MapString, SetString RULES new HashMap(); static { RULES.put(/api/admin/, Set.of(ADMIN)); // 后台管理接口只允许管理员 RULES.put(/api/coach/, Set.of(COACH, ADMIN)); // 教练操作接口 RULES.put(/api/student/,Set.of(STUDENT, ADMIN));// 学员操作接口 } Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws IOException { String role (String) req.getAttribute(role); // 由登录拦截器提前解析 token 写入 String uri req.getRequestURI(); for (Map.EntryString, SetString e : RULES.entrySet()) { if (uri.startsWith(e.getKey()) !e.getValue().contains(role)) { resp.setStatus(403); // 越权直接拒绝不返回业务数据 resp.getWriter().write({\code\:403,\msg\:\no permission\}); return false; } } return true; } }这段代码的关键在RULES这张静态表它把「路径前缀」和「角色集合」绑死新增接口时只要路径落在约定前缀下权限自动生效不依赖开发者记得加注解。role从哪来是登录成功后写进 token 的载荷登录拦截器解析完放进request属性两个拦截器一前一后顺序不能反。ADMIN在学员和教练前缀里都出现是因为管理员需要能代操作这一点在权限矩阵里没体现但代码里必须留口子否则后台的「代学员取消预约」做不了。2.3 功能结构图怎么画才经得起追问原文列了十个模块首页、个人中心、学员管理、教练管理、驾校信息管理、驾校车辆管理、教练预约管理、考试信息管理、预约考试管理、系统管理。十个方块平铺在一页 PPT 上看着整齐其实讲不出逻辑。我的做法是按「信息展示—预约事务—后台维护」分三组每组对应一条业务线结构图从上到下三层一页放得下讲的时候也有顺序。信息展示组解决「不知道去哪学」首页轮播与公告、驾校信息详情、教练列表与教练详情、车辆展示。预约事务组解决「约不上、约重了」教练预约、预约考试这两个是系统里唯一会产生状态变更的模块也是数据库设计的主战场。后台维护组解决「谁来管」学员、教练、车辆、考试场次、公告和管理员账号的增删改查。分组之后结构图上的连线就有了含义——信息组是只读的事务组要读写状态维护组控制前两组的输入。注意结构图里的每个方框都要能在后面的界面截图和代码目录里找到对应物。找不到的直接删掉别为了图好看硬加。3. 数据库设计九张表撑起「人、车、场、考」四条线3.1 核心表与字段取舍这个系统的数据实体其实就四类人学员、教练、管理员、车教练车、场教练的可约时段、考考试场次与报名。落到表上我一般会建九张student、coach、admin、vehicle、school_info、coach_booking、exam_info、exam_booking、notice。九张表不算多但每张的字段要想清楚尤其是状态字段和冗余字段。学员表除了基本信息必须有一个openid字段做唯一索引它是小程序的登录凭据比手机号可靠——学员换号很常见openid 不会变。subject记录当前考到科目几这个字段看着没用其实决定了教练列表的过滤逻辑科目二的学员不该看到只教科目的教练。教练表里car_id是外键指向车辆一辆车绑一个教练这样查「这个教练今天开哪辆车」不用再关联。预约表的字段设计是重点。coach_booking里我把日期和时间拆成book_dateDATE、start_timeTIME、end_timeTIME三个字段而不是存两个 DATETIME。原因是冲突判定要按「同一天同一时段」比对拆开之后索引能直接用SQL 写起来也直观如果存成一整段 DATETIME判定时要写一堆范围比较索引还容易失效。-- 教练预约表日期与时段拆开存便于冲突判定和索引命中 CREATE TABLE coach_booking ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL COMMENT 学员ID, coach_id BIGINT NOT NULL COMMENT 教练ID, vehicle_id BIGINT NOT NULL COMMENT 分配的教练车, book_date DATE NOT NULL COMMENT 预约日期, start_time TIME NOT NULL COMMENT 开始时间按30分钟对齐, end_time TIME NOT NULL COMMENT 结束时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待确认 1已确认 2已完成 3已取消 4爽约, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, -- 同一位教练、同一天、同一开始时间只能有一条有效记录 UNIQUE KEY uk_coach_slot (coach_id, book_date, start_time), KEY idx_student (student_id, book_date), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_coach_slot这个唯一索引是整个系统最便宜的一道防线。它保证同一个教练在同一天的同一个开始时间上数据库层面只可能存在一条记录不管前端怎么点、接口怎么被并发调用。idx_student服务于学员端「我的预约」列表idx_status服务于教练端「待我确认」的筛选这两个索引不加数据量稍微上来一点列表就开始转圈。字段类型上status用 TINYINT 不用 VARCHAR省空间也方便用status 1这种条件走索引。3.2 时段冲突唯一索引加事务两道锁一起上冲突判定是这个系统里唯一有技术含量的地方也是答辩时最值得展开讲的一段。要做到「一个教练一个时段只能被约一次」光靠前端把已约时段置灰是不够的两个人同时打开页面看到的是同一份空闲列表同时点提交两条请求打到后端谁先谁后全看运气。这时候靠的就是数据库。第一道是唯一索引。上面的uk_coach_slot会在插入时直接抛DuplicateKeyException捕获之后返回「该时段已被预约」业务层连查都不用查。第二道是事务加行级锁用于考试报名这种有名额扣减的场景后面第 4 章会展开。两道防线的关系是唯一索引兜底事务保证业务一致性前者防重复后者防超卖。-- 查询某教练某天的可约时段已被占用的时段直接排除 SELECT t.slot_start FROM coach_slot_template t -- 教练的排班模板表存固定可约时段 WHERE t.coach_id #{coachId} AND t.week_day DAYOFWEEK(#{bookDate}) -- 按星期几取排班 AND NOT EXISTS ( SELECT 1 FROM coach_booking b WHERE b.coach_id t.coach_id AND b.book_date #{bookDate} AND b.start_time t.slot_start AND b.status IN (0, 1, 2) -- 待确认/已确认/已完成 都算占用 ) ORDER BY t.slot_start;这段 SQL 有两个容易写错的地方。一是status IN (0,1,2)这个条件取消3和爽约4的记录不能算占用否则一个时段被约了又取消就永远放不出来了这是最典型的一类 bug。二是排班模板必须单独建表如果直接按「早八点到晚六点每半小时一格」硬编码生成教练请假、车辆维修这些情况就无从表达系统会显得很假。模板表按coach_id week_day存教练在小程序端改自己的排班管理员在后台能覆盖两层控制刚好。3.3 预约状态机与取消规则状态字段最怕没人管谁都能改最后数据库里全是status 1。这套系统里我给教练预约定了五个状态和固定的流转方向学员提交后是「待确认」教练在小程序端点确认变「已确认」或驳回变「已取消」学员练完车教练点完成变「已完成」学员没到场则记「爽约」。管理员有强制取消的权限但要留操作日志。当前状态触发动作操作者流转到待确认(0)教练确认教练已确认(1)待确认(0)教练驳回 / 学员取消教练 / 学员已取消(3)已确认(1)教练标记完成教练已完成(2)已确认(1)学员取消需提前2小时学员已取消(3)已确认(1)超时未到系统定时任务爽约(4)「提前两小时才能取消」这条规则要写在业务层不能只写在前端提示里。实现方式是在取消接口里比对book_date start_time与当前时间小于两小时直接拒绝。爽约状态的自动流转用一个定时任务扫每天凌晨扫一遍昨天已确认但未完成的记录改成爽约。这个定时任务在答辩时是个加分项因为它说明你想过「没人操作的时候系统该做什么」。4. 核心模块实现从选时段到落库的完整链路4.1 首页与驾校信息低频场景下的加载策略首页是学员进来看到的第一屏它要回答三个问题这个驾校靠不靠谱、我该找哪个教练、我之前约的课还在不在。对应四个区块顶部轮播和公告中间驾校信息卡片下面教练推荐列表最底下是「我的最近预约」。公告和轮播从notice表取按时间倒序取前五条不要一次把全表拉下来这是新手最常见的性能坑。驾校信息详情页的图片是大头一个驾校放八九张训练场照片很常见。小程序端必须做懒加载和尺寸限制modeaspectFill配合固定高度不然列表滚动会卡成幻灯片。原文提到「页面调用方式」和「页面设计美化程度」是系统的短板其实短板不在美化在图片没有压缩、列表没有分页。分页参数统一用page和pageSize默认一页十条后端用LIMIT拼前端用onReachBottom触发下一页。// pages/school/list.js —— 驾校列表分页加载 Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onLoad() { this.fetchList(); }, onReachBottom() { // 触底加载下一页 if (!this.data.hasMore || this.data.loading) return; // 防止重复请求 this.setData({ page: this.data.page 1 }); this.fetchList(); }, fetchList() { this.setData({ loading: true }); wx.request({ url: ${getApp().globalData.baseUrl}/api/school/list, data: { page: this.data.page, pageSize: this.data.pageSize }, success: (res) { const rows res.data.data || []; this.setData({ list: this.data.list.concat(rows), // 追加而非覆盖 hasMore: rows.length this.data.pageSize // 返回条数不足一页说明到底了 }); }, complete: () this.setData({ loading: false }) }); } });hasMore的判断依据是「本次返回条数是否等于 pageSize」这个写法比让后端返回总数简单缺点是最后一页刚好满页时会多请求一次空列表。如果要精确可以让后端在响应里带total前端算page * pageSize total。loading这个标志位不能省onReachBottom在快速滑动时会连续触发好几次没有它就会出现重复数据和页码错乱这个坑我在早期项目里踩过不止一次。4.2 教练预约三段选择到一次落库教练预约的交互是一条直线选教练 → 选日期 → 选时段 → 填备注 → 提交。前两步是纯查询第三步依赖教练排班和已有预约算出来的空闲列表第四步才是写。很多毕设把这一段做成「选完教练直接弹出日期选择器」看起来省事实际学员根本不知道哪天有车选完发现全满体验极差。正确的顺序是先看教练的排班日历有空的日期高亮点进去再看具体时段。提交时的接口设计要注意两点一是把coachId、bookDate、startTime一起传后端不要去信任前端算出来的endTime时长由教练的排班模板决定前端传什么都是参考二是接口必须幂等同一个学员重复点击提交应该返回「您已有该时段的预约」而不是插两条。// pages/booking/create.js —— 提交预约 submit() { const { coachId, bookDate, startTime } this.data.form; if (!coachId || !bookDate || !startTime) { return wx.showToast({ title: 请选择完整时段, icon: none }); } wx.showLoading({ title: 提交中 }); wx.request({ url: ${getApp().globalData.baseUrl}/api/booking/coach, method: POST, header: { Authorization: wx.getStorageSync(token) }, // 登录态 data: { coachId, bookDate, startTime, remark: this.data.form.remark }, success: (res) { if (res.data.code 200) { wx.showToast({ title: 预约成功等待教练确认 }); wx.navigateBack(); // 返回上一页列表在 onShow 里刷新 } else if (res.data.code 409) { wx.showToast({ title: 该时段刚被约走换一个吧, icon: none }); this.loadSlots(); // 冲突时立即重新拉取可约时段 } else { wx.showToast({ title: res.data.msg || 提交失败, icon: none }); } }, complete: () wx.hideLoading() }); }这段代码里code 409的分支是精髓。用户在这一页停留几分钟很正常期间时段被别人约走是必然会发生的事遇到冲突不能只弹一句「失败」要把可约列表重新拉一遍让用户当场换一个而不是退出去重来。Authorization头带 token 是后端识别学员身份的依据取不到就直接 401前端统一跳登录不要在每个页面里各写一套判断。后端接住这个请求之后动作顺序是校验学员状态有没有被拉黑、有没有未处理的爽约→ 查教练排班确认这个时段合法 → 查车辆占用 → 插入记录 → 捕获唯一键冲突 → 返回。中间任何一步失败都要回滚所以方法上要加事务注解。插入成功之后可以顺手发一条订阅消息给教练这一步在小程序里用wx.requestSubscribeMessage拿授权虽然毕设里经常省略但写进 PPT 的「流程完整度」里很占便宜。4.3 考试预约和教练预约完全是两套逻辑很多人在答辩时把教练预约和考试预约讲成一回事这是要扣分的。两者的资源模型不同教练预约是「一个教练一个时段一个人」互相独立考试预约是「一个场次 N 个名额先到先得」存在名额竞争。前者靠唯一索引解决后者必须靠行锁扣减。-- 考试报名先扣名额扣成功再插报名记录两条语句在同一个事务里 START TRANSACTION; UPDATE exam_info SET remain remain - 1 WHERE id #{examId} AND remain 0; -- 条件里带 remain 0防止扣成负数 -- 影响行数为 0 说明名额已抢完业务层直接回滚并返回「名额已满」 -- 影响行数为 1 才继续插入报名记录 INSERT INTO exam_booking (exam_id, student_id, status, book_time) VALUES (#{examId}, #{studentId}, 0, NOW()); COMMIT;WHERE remain 0这个条件是防超卖的关键它把「判断」和「扣减」合并成了一条原子语句不需要先SELECT查一遍再UPDATE。数据库在这个 UPDATE 上会加行锁两个并发请求排队执行第二个执行时remain已经是 0条件不成立影响行数为 0直接失败。如果先查后改中间的空隙足够另一个请求插进来两个人就都报名成功了这就是典型的超卖。原文提到系统在执行效率上有欠缺、考虑过存储过程其实这个场景用不着存储过程一条带条件的 UPDATE 就够了。对比项教练预约考试预约资源单位教练 × 时段考试场次 × 名额冲突维度同一教练同一时段不可重复全场次名额共享核心手段唯一索引条件 UPDATE 行锁取消影响释放时段他人可约名额回加remain 1谁发布教练排班模板管理员发布场次4.4 后台管理三套菜单背后的数据范围后台是小程序之外的另一半管理员登录后看到的是全量数据教练登录后只能看到自己名下的学员和预约。实现上有两种做法一是写两套页面二是同一套页面按角色渲染不同菜单、接口按角色过滤数据范围。我选后者因为维护成本低而且答辩演示时切换账号就能展示权限差异效果直接。数据范围的控制放在业务层的查询条件里不是在 SQL 里写死。做法是从登录态里取coachId如果当前角色是教练就给查询条件加上AND coach_id #{currentCoachId}管理员不加这个条件。这个判断放在 Service 层的一个方法里统一处理不要在每个 Mapper 里各写一遍否则迟早有一条漏掉。菜单渲染则是后端返回一个权限码数组前端按码决定显示哪几项但正如前面说的这层只是展示真正的拦截在接口。车辆管理这个模块容易被做薄。原文提到「驾校车辆管理对驾校车辆信息进行管理包括车辆的状态和预约情况」状态至少要有「可预约、使用中、维修保养」三种维修中的车不能被排进教练的可约时段。这个联动如果没做系统就只是个增删改查的壳子做了之后才算有点业务味道。做法是在教练排班查询那一步关联车辆表过滤掉维修状态的车。5. 避坑与常见问题排查五个最容易在答辩现场翻车的点5.1 现象两个学员约上了同一个教练同一时段原因基本只有一种冲突判定放在了前端或者后端判了但没加唯一索引。前端置灰只能防君子两个人同时打开页面拿到的都是「空闲」的旧数据一起提交就都成功了。还有一种更隐蔽的情况判定用了SELECT COUNT(*)再if判断中间没有事务隔离并发下照样穿过去。解决分三层一起做。数据库层加uk_coach_slot唯一索引这是最后的保险业务层把「查—判—插」包进一个事务插入时捕获DuplicateKeyException接口层对这类冲突返回明确的 409 状态码前端拿到 409 就刷新时段列表。三层做完即使有人拿工具压测也穿不过去。答辩时如果老师问「你怎么保证不重复预约」把这三层说出来比说「我加了判断」有说服力得多。5.2 现象学员提交成功了教练端一片空白先查状态字段。最常见的是插入时status默认值设成了 0待确认而教练端的列表查询条件写的是status 1两边对不上数据在库里躺着但谁也看不见。第二种是日期格式book_date存的是 DATE前端传的是2024-05-01字符串后端如果没做转换可能被当成2024-05-01 00:00:00查询时用和比较就漏了。排查顺序我一般是这样先在数据库里SELECT * FROM coach_booking ORDER BY id DESC LIMIT 5看记录到底进没进进了就看status和coach_id对不对都对就去看教练端接口打印的 SQL 条件十有八九是条件多写了一个。这类问题不要在前端调前端只能告诉你「没数据」真相永远在服务端日志里。注意调试期把 MyBatis 的 SQL 日志打开logging.level.xxx.mapperdebug能看到最终执行的语句和参数比盲猜快十倍。5.3 现象一进页面就 401或者登录后过一会又掉线小程序端的登录态是自己维护的wx.login拿到的 code 要发给后端换 openid后端生成 token 返回来前端存进wx.setStorageSync。三个环节都可能断code 只能用一次重复用会失败token 存了但请求头没带token 过期了没有续期机制。处理办法是封装一个统一的请求方法所有接口都走它在里面统一加Authorization头统一拦 401401 就清掉本地 token 重新走登录。最忌讳的是每个页面自己写wx.request加头的地方漏一个那个页面就永远是 401。另外wx.login的调用时机也要注意放在app.js的onLaunch里别放在页面onLoad否则每进一个页面都登一次。5.4 现象时间显示差八小时或者跨天时段算错这个坑非常经典。数据库存的是DATETIMEJava 里用Date接JSON 序列化默认按 UTC 输出小程序端new Date()一解析就少了八小时。表面看是时区问题实际是序列化配置没设。解决办法是在配置文件里把时区固定住Jackson 加spring.jackson.time-zoneGMT8和日期格式JDBC 连接串里加serverTimezoneAsia/Shanghai两头对齐。跨天时段是另一个坑。如果教练排班允许晚上十点到十一点这种时段book_date记的是开始那天start_time是 22:00判断「是否已过期」时直接拿book_date和今天比就会出错。稳妥的做法是查询时把两个字段拼成完整时间再比或者干脆在表里冗余一个start_datetime字段专供比较用用空间换清晰。5.5 现象演示当天数据全乱或者服务起不来答辩现场最怕的不是功能少是演示不了。数据乱通常是前几天测试时反复增删留下的脏数据预约表里全是状态为 0 的记录列表一打开就是几十条待确认。服务起不来多半是数据库没起、端口被占、或者配置文件里的连接串还是本地局域网的 IP。我的习惯是准备一份init.sql里面包含建表语句和一批干净的演示数据三个教练、五辆车、两个学员、一个管理员预约记录留两条待确认的。演示前把库 drop 掉重新跑一遍脚本三十秒恢复到已知状态。另外准备一份离线录屏网络断了或者投影出问题就放录屏别在台上跟环境较劲。6. 验收与答辩把 PPT 讲成一份可被追问的方案答辩 PPT 不是界面截图的堆砌它要证明你走过一遍完整的工程流程。十一页左右刚好页序我一般这么排封面、选题背景与痛点、角色与需求分析、功能结构图、技术选型与架构、数据库设计E-R 加核心表、核心流程教练预约的时序、界面展示、难点与解决、不足与改进、结束页。每页只讲一句话这句话必须是你想让老师记住的那句。页序内容这一页要说的一句话1封面系统名、姓名、学号、指导教师2背景与痛点传统电话约车信息不透明时段冲突靠人工记3角色与需求三类角色权限边界在接口层而非按钮层4功能结构图十个模块分三组只有预约组会改状态5技术选型学员教练用小程序管理员用 Web 后台6数据库设计九张表预约表用唯一索引防重复7核心流程从选时段到落库冲突返回 409 并刷新8界面展示选三张最能体现流程的不要放九宫格9难点与解决并发重复预约、名额超卖、登录态10不足与改进多管理员账号、消息通知、页面性能11结束页致谢不写「请老师批评指正」以外的废话第 10 页要主动说不足这一点很多人不敢做其实反着来更稳。原文自己就列了问题数据库存储过程用得不够、页面美化程度一般、窗口刷新有问题、不能添加多个管理员账号。把这些摆出来再补一句「如果要继续做我会先做消息通知和多管理员」老师就没得问了因为他想问的你已经自己说了。主动暴露问题的答辩比全程完美的演示更让人信服。现场演示走最短路径五个动作管理员登录后台 → 新增一个教练并绑定车辆 → 切到学员端小程序预约这个教练 → 切到教练端确认 → 回后台看预约记录变成已确认。整条链路两分钟内走完比逐个模块点一遍强得多。每个动作做完停一秒让老师看清楚页面变化别急着往下点。如果时间允许再补一个「重复预约被拦截」的反向演示效果比正向演示还好。高频问题就那么几个为什么不用 App、为什么不全做成小程序、数据库为什么这么设计、并发怎么处理、你的工作量在哪。前四个前面几章都有答案第五个最好提前准备好说辞——工作量不在页面数量在于把一套没有状态的信息展示系统改造成了有角色、有状态、有冲突校验的流程系统。这句话说出来基本就稳了。从那以后我每次带人做这类毕设都强制他们先跑一遍「登录到确认」的最短路径跑通了再谈美化和扩展跑不通就先别动界面。这个顺序反过来后面全是返工。希望帮到你。本文还有配套的精品资源点击获取
