SpringBoot+Uniapp剧本杀小程序：从预约拼车到防超卖的完整设计与实现

临近课程设计或毕业设计选题的时候，“剧本杀系统”这类题目经常会让同学犹豫：它到底只是普通增删改查，还是能做出真正有技术含量的项目？一个基于SpringBoot+Uniapp的剧本杀游玩一体化平台微信小程序，会不会被老师当成“页面堆砌”？

我自己的判断是：这类题目选得好不好，关键在于你能不能把一个完整的线下消费场景翻译成线上系统。剧本杀平台不是“问卷系统”那种一页CRUD的东西，它背后有剧本分类、场次管理、拼车余位、预约状态流转、订单评价，甚至并发情况下如何防止同一场次超卖。做完整一轮之后，你会明显感觉自己的后端设计和前端联调能力都被打磨了一遍。

这篇文章不是抄代码的流水账，而是把整个项目的思路完整复盘出来。包括最初怎么拆需求、后端为什么这样搭、数据库的表为什么这么设计、小程序端怎么和接口联调，以及最后交材料、准备答辩时容易忽略的几个坑。只要你正在做或准备做同类课题，按这套思路走一遍，至少能少走半个月弯路。

1. 定制业务地图：从剧本杀线下场景推导平台功能

1.1 先按用户路径把功能翻译成需求列表

很多同学拿到“一体化平台”这种题目，第一反应是去网上看别人的系统有什么菜单，然后照搬。这样写出来的需求文档看起来很全，但做起来非常虚。我更推荐从线下玩剧本杀的路径倒推。

想象一个用户打开这个小程序后发生了什么：

1. 进入首页，看到轮播图和热门剧本推荐。
2. 进入剧本列表，按题材、人数、难度筛选。
3. 点进详情页，看剧本简介、角色配置、时长、价格，同时看到近期可预约的场次。
4. 选择场次，填写预约人数和联系方式；如果人数不够，看到当前已有几人“上车”，这就是拼车信息。
5. 提交预约后，在“我的预约”里跟踪订单状态，从待确认到已完成。
6. 体验结束后，对这次预约对应的剧本和场次写评价。
7. 管理员在小程序之外（或后台页面）维护剧本、分类、轮播图、场次信息。

把这串流程翻译成后端模块，就是用户模块、剧本模块、场次模块、预约拼车模块、订单评价模块。这样的模块划分是直接从真实场景里长出来的，而不是靠背。需求文档里画用例图的时候，也只需要围绕这几个模块展开，每个模块三四个用例就够，不要贪多。

1.2 角色权限只拆两套：普通用户和管理员

课设和毕设阶段，我最不建议在角色上做太多层级。有人一上来就设计“玩家、店长、主持人、超级管理员”四个角色，结果权限拦截器写了一半，就把自己绕晕了。

正确做法是先收敛成两类：普通用户和管理员。普通用户登录小程序，完成浏览、预约、评价、收藏这些操作；管理员负责维护剧本和场次，同时对预约记录做管理。如果你担心“店长”和“主持人”体现不出来，可以在管理员上增加一个role_code字段，或者放在菜单权限里做区分，但不要为此建一套独立角色表。这样既能在答辩时说清楚“不同的角色权限边界”，又不会因为过度设计耽误开发进度。

1.3 把“状态机”提前画出来，比编码更重要

我见过太多同学后端接口写完了，才发现预约单没有状态变更，场次满员后依然能被点击。归根结底是没有提前画状态流程。

剧本杀平台的核心状态有两条线：

• 场次状态：可预约 -> 已满员 -> 已开场 -> 已结束
• 预约单状态：待确认（如果有支付环节） -> 已预约 -> 已取消 -> 已完成 -> 已评价

这两条状态线一定要在设计和数据库阶段就写清楚。我在做这个项目的时候，是先在纸上画了一条流程图，标注每个状态允许哪些操作、操作之后跳到哪个状态，然后才去建表。数据库中每个相关表都有status字段，小程序端根据状态渲染按钮：比如状态为“已取消”时，不能点“去评价”；状态为“可预约”但余位不足时，按钮直接置灰。

这个状态机在答辩时非常加分。只要有老师问到“你的订单状态是怎么流转的”，一张图把流程讲清楚，就能压住场子。

2. 技术选型复盘：SpringBoot和Uniapp不能只是“听说好用”

2.1 后端版本“够用就好”：Java 8/11配合SpringBoot 2.7.x

版本选型是这个项目第一个容易踩坑的地方。网上的教程五花八门，但我的建议很明确：课程设计和毕业设计优先用SpringBoot 2.7.x，配合Java 8或Java 11。为什么不用最新的SpringBoot 3.x？因为SpringBoot 3强制要求Java 17以上，而不少教程里常用的MyBatis-Plus旧版本、某些代码生成器、Swagger相关依赖，在新版本环境下会出现兼容性问题。好不容易把项目跑起来了，结果卡在一个莫名其妙的依赖报错上，极其浪费时间。

如果你因为课程要求必须用Java 17或SpringBoot 3.x，也可以，但务必先确认这些依赖都支持新版本：

在实际项目中，我用了SpringBoot 2.7.18、MyBatis-Plus 3.5.3和JDK 8，整套组合几乎没有遇到版本陷阱，这让我把时间都花在业务代码上，而不是排查“为什么注解不生效”。

2.2 MyBatis-Plus让CRUD更轻，也让文档更好写

数据访问层选MyBatis-Plus，不是因为它花哨，而是因为它在最简单的情况下能大大减少重复代码。普通的单表增删改查直接继承BaseMapper<T>，分页用selectPage，条件查询用LambdaQueryWrapper，基本不需要手写XML。在剧本列表这类需要动态拼接条件的场景下，它的价值很明显：

java复制LambdaQueryWrapper<ScriptInfo> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StringUtils.isNotBlank(categoryId), ScriptInfo::getCategoryId, categoryId)
       .like(StringUtils.isNotBlank(name), ScriptInfo::getName, name)
       .eq(StringUtils.isNotBlank(tag), ScriptInfo::getTag, tag)
       .orderByDesc(ScriptInfo::getCreateTime);
Page<ScriptInfo> page = scriptInfoMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);

这段代码逻辑非常直观，条件为空时不参与过滤，名称用模糊搜索，排序按创建时间倒序。答辩时如果老师问“你的搜索分页怎么做的”，直接用这个代码讲就够了。

当然，MyBatis-Plus也不是包治百病。跨表关联查询、统计类SQL，我还是会写原生SQL，比如“按分类统计剧本数量”“查询某场次已预约人数”这类场景，用@Select注解直接写SQL反而更清晰。

2.3 为什么选Uniapp而不是原生微信小程序

原生微信小程序当然能实现这个项目，但Uniapp带来的开发体验完全不同。它基于Vue语法，写过Vue的同学几乎不用额外学新东西，页面结构、数据绑定、组件通信都是熟悉的思路。而且Uniapp最大的隐藏优势是可以多端编译：同一个项目，你既能编译成微信小程序，也能编译成H5。答辩的时候在电脑浏览器里直接打开H5版演示，比让评委一个个掏出手机扫码方便太多。

我在实际开发中也是这么干的：开发阶段主要编译成H5在浏览器里调试，跑通功能后再编译到微信开发者工具里测试小程序端的兼容性。这样不仅调试速度快，还能提前发现H5和小程序端的差异问题。举个例子，uni.request在H5端会存在跨域限制，后端需要配置CORS；但在小程序端没有浏览器同源策略的概念，只要你把域名配到合法请求域名即可。这个差异如果不实际跑一遍，很难意识到。

2.4 中间件能省就省，别为“看起来高级”给自己挖坑

看到很多同学在课设里强行加入Redis缓存、RabbitMQ消息队列、OSS对象存储，最后不但没有为自己的答辩加分，反而因为“缓存和数据库不一致”“消息丢失”“OSS部署失败”这些自己给自己制造的问题被老师追问到怀疑人生。

我的原则是：项目中只保留必要的工程质量组件，比如统一返回结构、全局异常处理、JWT登录校验。这些是体现代码规范性的东西，必须有。而Redis、消息队列这类中间件，除非你的项目有非常明确的业务场景（比如拼车抢座需要并发控制），否则别加。你用Redis存登录态，就得解释为什么不用JWT还要引入外部依赖；你用OSS存图片，就得处理上传失败和防盗链问题。课程设计的重点是项目的完整性、代码的可读性、功能的闭环，而不是微服务架构的规模。

3. 数据库设计推演：拼车场次与防超卖是项目分水岭

3.1 核心表结构怎么看：从主数据到业务流水

数据库是这个项目里最值得花时间的部分，因为所有功能最终都落在表结构上。这里我整理了一份核心表清单，你可以根据自己的需求调整字段。

这个表结构有一个很关键的取舍：script_reserve里冗余了script_name和session_time字段。严格从三范式角度说，这些信息可以通过外键关联查出来，没必要冗余。但我在实际项目中保留了冗余字段，原因很简单：列表页和订单页展示时需要频繁联表查询，冗余之后一条SQL就能拿到历史快照，即使剧本或场次后来被修改，订单里仍然保留用户预约时的原始信息。这种“业务性冗余”在真实系统中非常常见，答辩时主动解释清楚，反而说明你理解了范式理论和实际业务之间的矛盾。

3.2 防超卖设计：条件更新与事务的配合

剧本杀拼车预约最容易出现的问题就是“超卖”。假设一个场次12个座位，当前已预约10个，两个用户同时提交预约，一个订了2人，一个订了3人，如果没有控制，系统会认为两个都能成功，最终该场次预约人数变成15，显然不合理。

解决这个问题最直接的方式，是在更新场次已订人数时带上条件判断：

sql复制UPDATE script_session
SET booked_seats = booked_seats + #{peopleCount}
WHERE id = #{sessionId}
  AND status = 1
  AND booked_seats + #{peopleCount} <= total_seats

这条SQL的关键在于booked_seats + #{peopleCount} <= total_seats这个条件。MySQL执行更新时会对该行加锁，同一时刻只能有一个事务执行成功，另一个事务更新后影响行数为0，我们就可以据此判定“余位不足”，抛出异常并回滚预约单插入。在预约接口中，我用@Transactional整体包裹，先插入预约单，再执行条件更新，如果更新返回0行，就手动抛出异常触发回滚。

这里有一个容易踩坑的细节：如果你只写了“先查询剩余座位数，再判断，再更新”，在高并发场景下依然会超卖，因为两次查询之间可能有别人插入预约。课程设计阶段，只要老师不深入追问并发，先查询后判断也能运行；但如果你能主动说出“我用的是条件更新配合事务，避免并发下的脏更新”，这个点在一众项目中会非常显眼。

3.3 类型、索引与字符集这些容易被忽略的细节

数据库层面的很多小细节，看似不起眼，却能直接影响体验和最终评分：

• 价格字段用decimal(10, 2)，不要用float或double。原因很简单，浮点数在计算时可能产生精度误差，用户交钱和订单金额对不上会非常尴尬。
• 状态字段用tinyint，并配合Java常量类定义。不要直接在代码里写if(status == 1)这种魔法值，而是定义ReserveStatusEnum或常量类，代码可读性会提升一个档次。
• 高频查询字段记得加索引。我的习惯是在外键字段（user_id、script_id、session_id）和order_no上加普通索引。特别注意：order_no应该加唯一索引，因为订单号绝对不能重复。
• 使用MySQL 8.0时，默认字符集是utf8mb4，这本来就应该保留。它不仅能存中文，还能存表情符号，用户昵称里带emoji是常事，用utf8可能会报错。
• 时间字段优先用datetime，不要为了方便把时间存成字符串。虽然字符串也能展示，但后续排序和区间查询会非常痛苦。

4. SpringBoot后端核心链路：统一响应、JWT与预约事务

4.1 统一返回结果与全局异常处理

后端接口规范程度直接决定小程序端的对接效率。我在项目里定义了一个简单的Result<T>对象：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    
    public static <T> Result<T> ok(T data) {
        Result<T> r = new Result<>();
        r.setCode(200);
        r.setMessage("success");
        r.setData(data);
        return r;
    }
    
    public static <T> Result<T> error(String message) {
        Result<T> r = new Result<>();
        r.setCode(500);
        r.setMessage(message);
        return r;
    }
}

配合@RestControllerAdvice做全局异常处理：业务异常统一抛出ServiceException，异常处理器捕获后转为Result.error()；参数校验异常也统一捕获，返回友好提示。这样一来，Controller里就不会出现“try-catch包住一切”的丑陋代码，接口无论成功还是失败，返回给前端的结构始终是{code, message, data}，小程序端只需要解析同一个结构。这个设计在文档里可以作为“系统设计亮点”写进去，篇幅不大但非常实用。

4.2 微信登录与JWT拦截器

小程序端的登录流程是：前端调用uni.login()拿到临时code，传给后端，后端通过jscode2session接口换取用户的openid。有了openid后，系统查用户表：如果不存在就自动注册，如果存在就直接返回登录结果，最后生成一个JWT token返回给前端。

生成token时，我会把userId作为自定义声明放到JWT中：

java复制String token = Jwts.builder()
        .setSubject(userId.toString())
        .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000))
        .signWith(SignatureAlgorithm.HS256, secretKey)
        .compact();

后端写一个拦截器，对所有需要登录的接口（比如预约、收藏、评价）进行拦截。拦截器从请求头获取Authorization: Bearer token，解析token，得到userId后放到ThreadLocal中，业务代码里直接通过UserContext.getUserId()拿到当前用户。这种设计的好处是核心业务代码不用在参数里来回传userId，代码更干净，也更容易统一处理登录失效。

这里要特别提醒：微信接口返回的数据并不总是成功的，网络抖动、code过期都会导致返回错误码。在写代码时一定要先判断微信返回的errcode是否为0，再往下处理，否则很容易出现空指针异常，而且这类问题在测试时特别难查。

4.3 预约接口的完整事务实现思路

预约拼车是整个项目的核心接口。它的逻辑不是简单插入一条订单，而是“订单插入+场次座位更新”两步操作必须同时成功或同时失败。我实现的思路如下：

java复制@Transactional(rollbackFor = Exception.class)
public ReserveResult createReserve(ReserveRequest request) {
    // 1. 校验场次状态
    ScriptSession session = getSessionById(request.getSessionId());
    if (session == null || session.getStatus() != 1) {
        throw new ServiceException("场次不存在或不可预约");
    }
    
    // 2. 校验预约人数是否在合理范围
    if (request.getPeopleCount() <= 0 || request.getPeopleCount() > session.getMaxPlayers()) {
        throw new ServiceException("预约人数不合法");
    }
    
    // 3. 生成预约单
    ScriptReserve reserve = buildReserve(request, session);
    scriptReserveMapper.insert(reserve);
    
    // 4. 条件更新座位数，影响行数为0则说明余位不足
    int rows = scriptSessionMapper.updateBookedSeats(request.getSessionId(), request.getPeopleCount());
    if (rows == 0) {
        throw new ServiceException("该场次余位不足，预约失败");
    }
    
    // 5. 返回预约信息
    return ReserveResult.success(reserve);
}

第4步对应的SQL就是上一章提到的条件更新。把判断逻辑放在SQL层面而不是代码层面，是防超卖的关键。同时注意@Transactional必须指定rollbackFor = Exception.class，否则如果抛出的是自定义运行时异常而事务默认不捕获，数据就会出现“订单插入了但座位没更新”的不一致情况。

关于拼车的展示逻辑，我在场次信息里同时维护了total_seats和booked_seats，前端通过“剩余座位 = total_seats - booked_seats”直接展示。这种冗余设计在查询时非常高效，不用每次通过预约单临时count，但必须保证更新座位时和插入预约单处于同一个事务中，否则数据会错乱。

4.4 剧本列表、分页搜索与后台管理端点

剧本列表除了支持分页，还要支持多条件筛选。我在接口设计中用了「GET /api/script/list」，参数包括pageNum、pageSize、categoryId、tag、name。Controller层只做参数接收，Service层用MyBatis-Plus的LambdaQueryWrapper动态拼接条件，这部分代码前面已经展示过。需要补充的一点是：剧本列表返回给前端时，强烈建议在VO层补充两个字段：totalSeats和bookedSeats，甚至直接返回一个“当前最早可预约场次”的信息。这样小程序端首页就能直接展示“可拼”和“满员”状态，提升体验。

后台管理接口我统一放在/admin/api/**前缀下，并通过拦截器只校验这个前缀的登录状态。管理端需要的功能主要是维护剧本表、分类表、场次表，以及对订单进行查看与状态调整。这些接口都是典型的增删改查，没有额外复杂度，但要注意：管理员的密码不要明文存储到数据库，至少用BCryptPasswordEncoder做一次加密哈希。很多课设项目把密码明文写在SQL脚本里，这在答辩时容易被老师一眼看出问题。

5. Uniapp小程序端：从请求封装到拼车预约交互

5.1 创建项目和manifest配置里的关键点

Uniapp项目创建方式有两种：HBuilderX可视化创建，或者用CLI创建。课程设计阶段，我建议直接使用HBuilderX创建，因为配置管理、运行调试都更直观，而且内置的“运行到小程序模拟器/浏览器”功能对新手非常友好。

创建项目后，manifest.json是第一个需要关注的配置文件。这里要配置微信小程序的appid，没有真实appid时可以使用测试号，但测试号会限制一些能力。页面权限声明也在这里完成，比如需要地理位置权限时，要在mp-weixin节点下配置permission。开发阶段如果只是用模拟器，可以不申请真实appid，但如果你要真机预览，就必须换成自己的AppID。

5.2 封装uni.request，别让页面里到处是请求

如果每个页面都直接写uni.request，代码会变得非常零散，而且token注入、错误处理逻辑都要重复写。我通常在utils/request.js里封装一个请求模块：

javascript复制const BASE_URL = 'http://localhost:8080/api';

const request = (path, method = 'GET', data = {}) => {
  return new Promise((resolve, reject) => {
    uni.request({
      url: BASE_URL + path,
      method,
      data,
      header: {
        'Content-Type': 'application/json',
        'Authorization': uni.getStorageSync('token') ? 'Bearer ' + uni.getStorageSync('token') : ''
      },
      success: (res) => {
        if (res.statusCode === 401) {
          uni.removeStorageSync('token');
          uni.navigateTo({ url: '/pages/login/login' });
          reject(res.data);
          return;
        }
        if (res.data.code === 200) {
          resolve(res.data.data);
        } else {
          uni.showToast({ title: res.data.message, icon: 'none' });
          reject(res.data);
        }
      },
      fail: (err) => {
        uni.showToast({ title: '网络请求失败', icon: 'none' });
        reject(err);
      }
    });
  });
};

export const get = (path, data) => request(path, 'GET', data);
export const post = (path, data) => request(path, 'POST', data);

这个封装主要解决三件事：全局注入token、统一处理401跳转登录、根据后端业务码统一弹出提示。之后页面里调用就是post('/reserve', {...})，逻辑非常清爽。这里有一个需要注意的细节：不能把baseURL写成https://localhost或者http://127.0.0.1然后直接真机测试，手机访问不到你电脑上的localhost。开发阶段在微信开发者工具里开启“不校验合法域名”可以正常访问，但要真机预览，还得把后端部署到局域网服务器，并把baseURL改成电脑的局域网IP。

5.3 登录态处理与微信基础库的新变化

小程序登录是一个看起来简单但细节很多的功能。新版微信基础库中，uni.getUserProfile或直接获取用户昵称头像的授权逻辑已经变更，不能像老教程那样一进页面就弹窗获取用户信息。正确流程是：用户点击“微信登录”按钮，触发uni.login()获取code，后端用code换openid并创建会话返回token，之后用户点击“完善资料”时，再通过button的open-type="chooseAvatar"收集头像昵称。这个流程也是当前微信平台的合规方案。

我在页面里具体这样处理：pages/login/login.vue里放置一个登录按钮，点击后调用uni.login，获取code后请求后端/api/auth/login，后端返回token。登录成功后把token存到uni.setStorageSync('token', token)，再跳转到首页或回跳页。至于用户头像昵称，在个人中心页面用button引导用户填写，这些信息再通过PUT /api/user/profile同步到后端。

这个细节在答辩时如果老师问“小程序怎么获取用户信息”，你可以直接解释清楚“当前推荐的方式是通过button组件引导用户授权，而不是页面加载时直接弹窗”，既体现你对微信平台规则的了解，也说明你用的是最新思路。

5.4 首页筛选、列表分页与状态刷新

小程序端的列表页是用户感知最直接的模块。我实现剧本列表时，页面结构是：顶部搜索框 + 分类tab栏 + 列表区域。分类tab用横向滚动，切换时重新请求第一页数据；滚动到底部后用onReachBottom触发加载下一页。

这里有一个常见坑：Uniapp页面滚动到底部触发的是onReachBottom，而不是scroll-view的@scrolltolower，两者混淆会导致“滚动加载不生效”或“每次都加载一页数据”。如果你用的是页面原生滚动，就在onReachBottom里判断；如果你用scroll-view包裹列表，就要在@scrolltolower里处理。我最终选用了原生页面滚动加onReachBottom，原因是简单，且不用额外处理scroll-view的高度问题。

在数据层，我维护了三个字段：

javascript复制data() {
  return {
    list: [],
    pageNum: 1,
    pageSize: 10,
    hasMore: true,
    loading: false
  };
},

请求成功后，第一页直接赋值，后续页面使用this.list = this.list.concat(res.records)。如果返回记录数少于每页数量，就把hasMore置为false，停止加载。这个逻辑虽然基础，但演示价值很高，老师看到你能处理分页加载而不是一次把数据全部返回，会对项目的规范性有不错判断。

5.5 预约表单与订单中心的联动

从剧本详情页进入预约页是拼车流程的关键转折。用户选择场次后，需要填写参与人数、联系电话和备注。参与人数可以用uni-steps或简单的步进器组件控制，同时实时显示“该场次剩余座位X人”。如果剩余座位数小于用户选择的人数，提交按钮直接禁用，阻止无效提交。

提交预约成功后，跳转订单列表页。这里有个体验细节：订单列表页要从详情页返回时刷新数据。我用的方案是在订单列表页的onShow生命周期里重新拉取数据。这种做法比用事件通知更简单，尤其是在多页面跳转场景下，onShow每次进入页面都会触发，数据基本上不会过期。注意不要只在onLoad里拉取数据，因为从详情页返回时onLoad不会再次执行，数据会停留在旧状态。

订单列表里，每一条预约单都展示状态标签。已取消的置灰，已完成但未评价的显示“去评价”按钮，点击后进入评价页，提交后刷新订单列表。这套交互链跑通后，整个预约闭环才算真正完成。

6. 交项目前的“最后一公里”：SQL脚本、文档与答辩准备

6.1 交付级数据库脚本怎么整理

很多同学在提交项目时，直接把自己开发过程中随手导出的SQL发过去，里面充满了测试残留、字符集混乱、表结构依赖顺序不明确。这类问题在验收时非常吃亏。

交付级的init.sql脚本至少要做到三件事：

1. 开头明确CREATE DATABASE并指定utf8mb4字符集，然后USE该库。
2. 建表语句按依赖顺序编排：先建用户表、分类表，再建剧本表、场次表，最后建预约单、评论表。外键约束如果没打算加，就不要在脚本里硬加，保持逻辑清晰更重要。
3. 初始数据要能支撑演示：至少准备10个剧本、3个分类、若干场次、1个管理员账号。演示时如果数据库全是空表，老师很难判断系统功能是否真实可用。

管理员初始密码我建议设置简单一点，比如admin/123456，同时在文档开头提示“项目启动后请立即修改初始密码”。虽然这是一句套话，但对项目安全意识和交付规范性都是加分项。

6.2 “万字文档”不是堆字数，是覆盖这些模块

项目标题里写着“附万字文档”，很多同学一听万字就头大，以为要从零开始凑字数。实际上，一个结构正常的课设文档写满一万字并不难，关键是内容要从需求到测试覆盖完整链路。我常用的文档结构如下：

其中最容易水字数的是数据库设计部分，每个字段写一句含义都能写好几页；最有含金量的是测试用例表。我强烈建议把核心功能做成表格，包含“测试项、操作步骤、预期结果、实际结果、是否通过”五列。这份表格在答辩时能直接回应“你这个系统测试过吗”的问题，比口头说“我测过”有力得多。

另外，文档中不要放无意义的源码大段粘贴，而是挑2-3个核心方法（比如预约接口、条件更新SQL）讲解，体现你对代码的理解。老师看文档时更关注逻辑是否通顺，而不是代码总量。

6.3 答辩会被追问的几个点，提前想好答案

最后是答辩环节。围绕这个项目，老师大概率会问这几个问题，提前想清楚就行：

• “为什么用JWT而不用Session？”答：无状态认证，服务端不需要存储会话，适合前后端分离和小程序多端接入，扩展性好。
• “如何防止拼车超卖？”答：预约单插入和场次座位更新放在一个事务里，更新时用带余位条件的SQL，更新影响行数为0则回滚，保证不会超过座位上限。
• “两台手机同时发起预约，真的不会超卖吗？”答：当前设计用了行锁+条件更新，同一时刻只有一个事务能更新成功。如果要进一步提升性能，可以引入Redis分布式锁或乐观锁，但在课程设计场景下当前方案已经满足正确性要求。
• “如果要把支付功能加进来，你的表结构怎么改？”答：在预约单表中增加支付流水字段，或在预约后补充一笔支付订单记录，支付回调成功后修改预约单状态。
• “这个系统有什么创新点？”答：相比传统的剧本展示类网站，本系统围绕预约拼车做了完整的业务闭环，包括拼车余位判断、场次状态流转、订单与评价联动，且采用Uniapp实现了跨端快速部署。

这类问题回答的要点不在于多，而在于你确实理解自己的代码。如果某个方向没做，就坦诚说明“这是后续可扩展点”，不要硬编。

在我实际完成这个项目后，最大的体会是：一个技术难度中等的题目，只要把业务逻辑做到闭环，把状态流转理清楚，就已经能超过很多人。因为很多人做项目不是被技术卡住的，而是被“想不清楚业务到底怎么走”卡住的。如果你现在正准备开题，我的建议很直接：不要急着写代码，先把预约的流程、状态的变化、表的关联关系在纸上画明白。画明白了，后面的开发只是时间问题；画不明白，写再多的代码都会被推倒重来。