企业官网建设流程全解析

简介：该资源为基于微信小程序的驾校预约管理系统毕业设计配套答辩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 Map<String, Set<String>> 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.Entry<String, Set<String>> 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_date（DATE）、start_time（TIME）、end_time（TIME）三个字段，而不是存两个 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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

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。这套系统里我给教练预约定了五个状态和固定的流转方向：学员提交后是「待确认」，教练在小程序端点确认变「已确认」或驳回变「已取消」，学员练完车教练点完成变「已完成」，学员没到场则记「爽约」。管理员有强制取消的权限，但要留操作日志。

「提前两小时才能取消」这条规则要写在业务层，不能只写在前端提示里。实现方式是在取消接口里比对book_date + start_time与当前时间，小于两小时直接拒绝。爽约状态的自动流转用一个定时任务扫，每天凌晨扫一遍昨天已确认但未完成的记录，改成爽约。这个定时任务在答辩时是个加分项，因为它说明你想过「没人操作的时候系统该做什么」。

4. 核心模块实现：从选时段到落库的完整链路

4.1 首页与驾校信息：低频场景下的加载策略

首页是学员进来看到的第一屏，它要回答三个问题：这个驾校靠不靠谱、我该找哪个教练、我之前约的课还在不在。对应四个区块：顶部轮播和公告，中间驾校信息卡片，下面教练推荐列表，最底下是「我的最近预约」。公告和轮播从notice表取，按时间倒序取前五条，不要一次把全表拉下来，这是新手最常见的性能坑。

驾校信息详情页的图片是大头，一个驾校放八九张训练场照片很常见。小程序端必须做懒加载和尺寸限制，mode="aspectFill"配合固定高度，不然列表滚动会卡成幻灯片。原文提到「页面调用方式」和「页面设计美化程度」是系统的短板，其实短板不在美化，在图片没有压缩、列表没有分页。分页参数统一用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 就够了。

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.mapper=debug，能看到最终执行的语句和参数，比盲猜快十倍。

5.3 现象：一进页面就 401，或者登录后过一会又掉线

小程序端的登录态是自己维护的，wx.login拿到的 code 要发给后端换 openid，后端生成 token 返回来，前端存进wx.setStorageSync。三个环节都可能断：code 只能用一次，重复用会失败；token 存了但请求头没带；token 过期了没有续期机制。

处理办法是封装一个统一的请求方法，所有接口都走它，在里面统一加Authorization头，统一拦 401，401 就清掉本地 token 重新走登录。最忌讳的是每个页面自己写wx.request，加头的地方漏一个，那个页面就永远是 401。另外wx.login的调用时机也要注意，放在app.js的onLaunch里，别放在页面onLoad，否则每进一个页面都登一次。

5.4 现象：时间显示差八小时，或者跨天时段算错

这个坑非常经典。数据库存的是DATETIME，Java 里用Date接，JSON 序列化默认按 UTC 输出，小程序端new Date()一解析就少了八小时。表面看是时区问题，实际是序列化配置没设。解决办法是在配置文件里把时区固定住，Jackson 加spring.jackson.time-zone=GMT+8和日期格式，JDBC 连接串里加serverTimezone=Asia/Shanghai，两头对齐。

跨天时段是另一个坑。如果教练排班允许晚上十点到十一点这种时段，book_date记的是开始那天，start_time是 22:00，判断「是否已过期」时直接拿book_date和今天比就会出错。稳妥的做法是查询时把两个字段拼成完整时间再比，或者干脆在表里冗余一个start_datetime字段专供比较用，用空间换清晰。

5.5 现象：演示当天数据全乱，或者服务起不来

答辩现场最怕的不是功能少，是演示不了。数据乱通常是前几天测试时反复增删留下的脏数据，预约表里全是状态为 0 的记录，列表一打开就是几十条待确认。服务起不来多半是数据库没起、端口被占、或者配置文件里的连接串还是本地局域网的 IP。

我的习惯是准备一份init.sql，里面包含建表语句和一批干净的演示数据：三个教练、五辆车、两个学员、一个管理员，预约记录留两条待确认的。演示前把库 drop 掉重新跑一遍脚本，三十秒恢复到已知状态。另外准备一份离线录屏，网络断了或者投影出问题就放录屏，别在台上跟环境较劲。

6. 验收与答辩：把 PPT 讲成一份可被追问的方案

答辩 PPT 不是界面截图的堆砌，它要证明你走过一遍完整的工程流程。十一页左右刚好，页序我一般这么排：封面、选题背景与痛点、角色与需求分析、功能结构图、技术选型与架构、数据库设计（E-R 加核心表）、核心流程（教练预约的时序）、界面展示、难点与解决、不足与改进、结束页。每页只讲一句话，这句话必须是你想让老师记住的那句。

第 10 页要主动说不足，这一点很多人不敢做，其实反着来更稳。原文自己就列了问题：数据库存储过程用得不够、页面美化程度一般、窗口刷新有问题、不能添加多个管理员账号。把这些摆出来，再补一句「如果要继续做，我会先做消息通知和多管理员」，老师就没得问了，因为他想问的你已经自己说了。主动暴露问题的答辩，比全程完美的演示更让人信服。

现场演示走最短路径，五个动作：管理员登录后台 → 新增一个教练并绑定车辆 → 切到学员端小程序预约这个教练 → 切到教练端确认 → 回后台看预约记录变成已确认。整条链路两分钟内走完，比逐个模块点一遍强得多。每个动作做完停一秒，让老师看清楚页面变化，别急着往下点。如果时间允许，再补一个「重复预约被拦截」的反向演示，效果比正向演示还好。

高频问题就那么几个：为什么不用 App、为什么不全做成小程序、数据库为什么这么设计、并发怎么处理、你的工作量在哪。前四个前面几章都有答案，第五个最好提前准备好说辞——工作量不在页面数量，在于把一套没有状态的信息展示系统，改造成了有角色、有状态、有冲突校验的流程系统。这句话说出来，基本就稳了。

从那以后我每次带人做这类毕设，都强制他们先跑一遍「登录到确认」的最短路径，跑通了再谈美化和扩展，跑不通就先别动界面。这个顺序反过来，后面全是返工。希望帮到你。

本文还有配套的精品资源，点击获取