每年这个时候，朋友圈就会冒出一批被毕设折磨到凌晨三点的人。如果你正在做基于微信小程序的影院购票管理系统毕业设计，或者身边有朋友在找这类源码，那这篇东西应该能帮到你。我会从选题思路、技术选型、数据库设计、核心接口、小程序端实现到答辩问答题，尽量把一条完整链路讲清楚。这不是一篇只贴几个页面的“伪教程”，而是把毕设从零到一怎么搭、为什么这么搭、踩了哪些坑，全部拿出来晒一晒。不管你后端用 Java 还是 PHP、前端用原生还是 uniapp，核心逻辑都是通用的。
先说清楚这个系统能做什么：用户在小程序里浏览电影、查看影厅场次、选座下单、模拟支付，还能查订单、退票；管理员在后台维护影片信息、排片、查看营收数据。对一个毕业设计来说，功能量不大不小，演示效果好，技术点也够讲。更重要的是，微信登录、手机号授权、组件化页面、RESTful 接口、事务一致性、状态机这些点，都是答辩时能拿出来撑场面的东西。如果你正愁选题，这个方向比纯管理系统要好看得多，也比纯商城更容易讲透。
1. 项目概述与整体设计思路
1.1 为什么选微信小程序做影院购票
影院购票这种业务，天然适合小程序而不是 App 或网页。用户买票不是高频操作，不可能为了看电影专门下载一个 App；网页又需要打开浏览器、输入网址，路径太长。小程序“用完即走”的属性，和购票场景非常匹配，也符合现在大多数人的使用习惯。
站在毕业设计角度，小程序还有一个特别现实的好处：前端展示效果很容易出彩。首页轮播图、电影卡片、影厅座位图、倒计时支付，这些界面做出来视觉冲击力强，答辩演示时一页一页滑过去，老师能直观看到页面交互。相比之下，传统的 JSP 管理系统页面再规范，也很难让外行感受到“工作量”。
更重要的是，小程序本身带了很多微信生态能力，比如 wx.login 登录、手机号快捷填充、订阅消息、分享朋友圈。你把这些能力用起来，系统的“科技感”一下子就上来了，而且每一块都能在答辩时单独拿出来作为创新点。用我指导过学生的原话说：“同样的 CRUD，包了一层小程序皮，就比纯网页值钱。”这话虽然有点糙，但在本科毕设场景里，确实是这样。
1.2 系统角色与功能模块拆解
先把系统切成两条线：用户端小程序，管理端后台。绝大多数毕设，做这两个端就够了，再加一个后端接口服务。
用户端功能列表：
- 微信授权登录，获取用户 openid，绑定手机号
- 首页轮播图展示热门影片，电影列表按热度/上映时间排序
- 电影详情页展示海报、简介、演员、上映日期、影片时长
- 选择场次：根据日期和影片查询影厅排片，展示放映时间、影厅、票价
- 在线选座：渲染座位矩阵，已售座位置灰，选中座位高亮，显示票价合计
- 创建订单：座位锁定、订单生成、跳转模拟支付
- 订单列表：待支付、已支付、已取消、已完成四种状态切换
- 取消订单：待支付状态的订单可取消并释放座位
管理端功能列表：
- 管理员登录（账号密码，或管理员手机号授权）
- 影片管理：新增、编辑、上下架影片，上传海报
- 影厅管理：维护影厅名称、座位总数、座位排布
- 排片管理：为影片安排场次，设置开始时间、影厅、票价
- 订单管理：查看全部订单、按状态筛选、手动退款
- 数据概览：今日票房、总订单数、热门影片排行（可选，图表展示更佳）
有人可能会问，为什么管理员不也做成小程序页面？做是能做，但管理员操作都在电脑上，小程序在电脑上体验很差，而且会增加小程序包体积。所以毕设通常把管理端做成 Web 系统，后端接口一套复用。这个设计思路放到答辩时也可以讲：前端多端复用同一套业务接口，体现了系统分层思想。
1.3 技术选型的权衡：用什么后端、什么前端
后端我首推Spring Boot + MyBatis-Plus + MySQL。Spring Boot 是当前企业使用率最高的 Java 框架，毕业后简历写这一条不亏；MyBatis-Plus 能省掉大量单表 CRUD 代码，让咱们把精力放在购票流程、事务处理这类核心逻辑上；MySQL 则是通用性最强的数据库，答辩场地大概率不会因为你用 MySQL 而跑不起来。
如果对 Java 不熟，也可以选 Node.js + Express 或 Python + Flask/Django + MySQL。关键逻辑、表结构、接口设计都是通用的，只是换一种语法实现。我不太推荐用 PHP，不是说 PHP 不行，而是现在新项目用 PHP 的比例明显下降，你拿着 PHP 毕设去面试，容易被追问“为什么不用主流方案”，反而给自己挖坑。
小程序端有两条路：原生和 uni-app。原生微信小程序（WXML + WXSS + JS）对毕设来说其实更合适，因为不需要引入额外的编译框架，代码结构透明，遇到问题网上答案一堆。uni-app 的优势是能一套代码编译到 App、H5、小程序，但如果你只需要小程序，多这一层框架反而增加了调试成本。我见过不少学生用 uni-app 踩到编译环境的坑，折腾两天才发现是框架版本问题，非常挫败。所以如果没有跨端需求，别犹豫，直接原生。
2. 核心细节解析与实操要点
2.1 微信登录与手机号获取：最容易翻车的地方
小程序端登录流程现在主流的做法是 wx.login 拿到临时 code，传给后端，后端调用微信接口jscode2session换取 openid 和 session_key。openid 是用户在小程序里的唯一身份标识，相当于用户的“身份证号”，你用 openid 关联用户表，就完成了注册/登录的第一步。
代码大概是这样的：
// 小程序端 wx.login({ success: (res) => { const code = res.code wx.request({ url: 'https://your-server.com/api/user/login', method: 'POST', data: { code }, success: (response) => { const { token, userInfo } = response.data wx.setStorageSync('token', token) // 后续请求带上token } }) } })后端拿到 code 后发起请求：
// Spring Boot 后端，伪代码 String url = "https://api.weixin.qq.com/sns/jscode2session" + "?appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; // 用 HttpUtils 发起GET请求，解析返回的 openid这里有两个坑必须提醒你：
- appid 和 secret 一定要放在后端，不要写在小程序代码里。小程序前端代码可以被任何人反编译，直接暴露 secret 等于把账号交给别人。即便是毕业设计，也要养成这个习惯。
- wx.login 的 code 只能使用一次，过期或者重复使用都会报错。如果出现“invalid code”，多半是前端调了两次 login。
手机号获取这块，很多学生一开始就想做“获取用户手机号”，结果小程序的getPhoneNumber组件要求小程序必须通过企业认证，个人主体用不了。如果你是用自己的个人小程序账号演示，要么换管理员手机号手动录入，要么就做一个“授权手机号”的按钮，点击后跳转到填写页面。部分毕设源码里会内置一个“微信一键登录”加“绑定手机号”的组合，后台能通过接口主动录入手机号，这种方法最稳。答辩时你可以说：“受限于个人主体未开放手机号接口，系统采用手动绑定方式，企业认证后即可切换为微信手机号快速填充。”这个回答既诚实，又展示了你知道这两个方案的差异。
2.2 影院排片与场次数据模型
影院购票的核心数据模型，其实就是四张表：影片表、影厅表、场次表、座位表。难点不在表多，而在字段设计。
影片表（film）至少要有：id、影片名称、海报图片、影片简介、导演、主演、上映日期、时长（分钟）、状态（0下架/1热映/2即将上映）。
影厅表（hall）至少要有：id、影厅名称、座位行数、座位列数、座位总数。注意座位排布，我建议在影厅表里存 row 和 col，这样前端渲染座位图时可以直接双层循环，不用每场次都去查座位定义。
场次表（session）至少要有：id、影片ID、影厅ID、放映日期、开始时间、结束时间、票价。结束时间可以在新增时自动根据影片时长算，也可以人工维护。这里有个小细节：同一影厅同一时段不能排两场电影，否则座位会“打架”。你在后端写排片接口时，务必检查时间段重叠：
SELECT COUNT(*) FROM session WHERE hall_id = #{hallId} AND show_date = #{showDate} AND ( (#{startTime} >= start_time AND #{startTime} < end_time) OR (#{endTime} > start_time AND #{endTime} <= end_time) )这套冲突判断逻辑一定要写到代码里，而不是只靠人工约束。答辩时老师大概率会问“如果同一影厅排了两场重叠电影怎么办”，你就可以理直气壮说已经做了时间冲突检测。
座位表（seat）是系统设计的重头戏。常见有两种设计思路：
- 方案A：座位表只记录“已售/锁定”状态，座位本身由影厅的行列自动生成。每次选座时，后端根据行列号生成一个临时座位 ID。
- 方案B：每场次预先在座位表中生成所有座位，每个座位带 session_id + row + col + status。
推荐用方案B，因为它在并发控制、订单关联、状态查询上都更直观。座位表字段：id、session_id、row、column、status（0可用/1锁定/2已售）、order_id（冗余订单号，方便查）。
2.3 选座、锁座与并发扣减
这是整个系统最值得讲的部分，也是很多“半吊子”源码最容易翻车的地方。
购票并发问题的本质是：同一场次只剩最后一张票，两个用户同时点选，系统只能卖给你其中一个人，不能超卖。很多学生的做法是：先查询座位状态，如果为 0 就更新为 1，然后创建订单。这在高并发下就是错的——“先查后改”在并发没有加锁的情况下，两次请求都可能查到状态为 0。
推荐的做法是使用数据库原子更新作为兜底：
UPDATE seat SET status = 1, order_id = #{orderId} WHERE id = #{seatId} AND status = 0这条 SQL 只有一行，但它是整个并发控制的关键：让数据库判断状态是否为0，是才更新，并且锁住这一行。如果影响行数为0，说明座位已经被别人抢走，直接返回“选座失败”。这个方案比 Java 代码里用 synchronized 靠谱得多，因为 synchronized 只对单机有效，换个部署环境就失效了。
还需要引入“锁座超时释放”机制。用户选好座位、跳到支付页面，但迟迟不付款，座位不能一直锁着。通常做法是：订单创建时设置锁座过期时间（比如15分钟），定时任务扫描超过15分钟未支付的订单，将对应座位状态改回0，订单状态改为已取消。毕业设计不要求你做一个完善的任务调度，直接在启动类加一个@Scheduled定时方法，每分钟扫一次就可以，代码量不大，但讲到“超时释放”这个设计时，面试官会觉得你有实战意识。
2.4 订单流程与模拟支付的设计
订单状态建议用整型字段表示，而不是字符串。0待支付、1已支付、2已取消、3已退款。简单状态机如下：
- 待支付 -> 支付成功 -> 已支付（或者待支付 -> 超时/主动取消 -> 已取消）
- 已支付 -> 申请退款 -> 已退款
毕业设计不建议接真实微信支付，因为个人主体没有商户号，申请流程复杂，而且在演示环境里真的去调微信支付也没意义。模拟支付的方式很简单：前端弹窗问“是否确认支付”，点击确认后调后端pay/notify接口，后端校验订单金额和订单状态，将状态改为已支付。
这时候你可以加一个 Admin API 手动“模拟微信回调”，演示效果更接近真实：前端调/api/pay/create得到一个支付单号，后端返回一个payUrl，跳转到模拟收银台页面，点“支付成功”后，后端通过内部接口完成回调，修改订单状态并释放已锁座位。当时我做这个设计时，答辩老师还特别问了一句“真实支付时回调地址怎么配置”，说明这个点确实能抓住老师的注意力。
3. 实操过程与核心功能实现
3.1 后端工程结构与接口清单
标准的 Spring Boot 工程结构如下，照着建就行：
src/main/java/com/example/cinema/ ├── controller/ // 接口层，只做参数接收和返回 ├── service/ // 业务逻辑层 ├── mapper/ // MyBatis-Plus 的 Mapper 接口 ├── entity/ // 数据库实体类 ├── config/ // 配置类（拦截器、跨域、定时任务） ├── common/ // 统一返回结构、异常处理 └── utils/ // 工具类（JWT、日期处理等）接口清单建议提前列出来，既方便自己开发，也方便写进毕业设计文档。我列一份完整参考：
| 模块 | 接口路径 | 方法 | 功能说明 |
|---|---|---|---|
| 用户 | /api/user/login | POST | code换openid并返回token |
| 用户 | /api/user/info | GET | 获取用户信息 |
| 影片 | /api/film/list | GET | 按状态查询电影列表 |
| 影片 | /api/film/detail | GET | 查询电影详情 |
| 场次 | /api/session/listByFilmId | GET | 查询某电影的所有场次 |
| 座位 | /api/seat/listBySessionId | GET | 查询某场次的座位矩阵 |
| 订单 | /api/order/create | POST | 选座并创建订单 |
| 订单 | /api/order/list | GET | 查询当前用户订单 |
| 订单 | /api/order/cancel | POST | 取消待支付订单 |
| 支付 | /api/pay/simulate | POST | 模拟支付成功 |
| 管理 | /api/admin/film/save | POST | 新增/编辑影片 |
| 管理 | /api/admin/session/create | POST | 新增排片 |
3.2 数据库建表：直接可用的 SQL 核心片段
下面给一段关键表的 SQL，基本涵盖了购票系统的主流程：
CREATE TABLE `film` ( `id` int NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL COMMENT '电影名称', `poster_url` varchar(255) DEFAULT NULL COMMENT '海报地址', `description` text COMMENT '简介', `director` varchar(50) DEFAULT NULL, `actors` varchar(255) DEFAULT NULL, `release_date` date DEFAULT NULL, `duration` int DEFAULT 0 COMMENT '时长(分钟)', `status` tinyint DEFAULT 1 COMMENT '0下架 1热映 2即将上映', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `hall` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL, `row_count` int DEFAULT 0 COMMENT '座位行数', `col_count` int DEFAULT 0 COMMENT '座位列数', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `session` ( `id` int NOT NULL AUTO_INCREMENT, `film_id` int NOT NULL, `hall_id` int NOT NULL, `show_date` date NOT NULL, `start_time` varchar(10) NOT NULL COMMENT 'HH:mm', `end_time` varchar(10) NOT NULL COMMENT 'HH:mm', `price` decimal(10,2) DEFAULT 0.00, PRIMARY KEY (`id`), KEY `idx_film_id` (`film_id`), KEY `idx_hall_date` (`hall_id`, `show_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `seat` ( `id` int NOT NULL AUTO_INCREMENT, `session_id` int NOT NULL, `row_no` int NOT NULL, `col_no` int NOT NULL, `status` tinyint DEFAULT 0 COMMENT '0可用 1锁定 2已售', `order_id` int DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_session_row_col` (`session_id`, `row_no`, `col_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `orders` ( `id` int NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` int NOT NULL, `session_id` int NOT NULL, `total_amount` decimal(10,2) DEFAULT 0.00, `status` tinyint DEFAULT 0 COMMENT '0待支付 1已支付 2已取消 3已退款', `expire_time` datetime DEFAULT NULL COMMENT '锁座过期时间', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有个小经验：orders表千万别起名order，因为order是 MySQL 的保留字，直接建表会报语法错误，这个坑我至少见三个学生踩过。如果非要用，就必须加反引号，但建议干脆改名。
座位表只用唯一索引uk_session_row_col约束同一场次同一座位只能存在一条记录，选座并发控制就靠那条UPDATE seat SET status=1 WHERE id=? AND status=0配合唯一索引。订单表直接冗余order_no、total_amount，查询订单详情时就不用连好几张表了。
3.3 小程序端页面实现与关键代码
小程序端我建议把公共能力先封装好。请求封装是最重要的一步，所有接口统一走同一个request方法，自动带 token、统一处理 401 跳转、统一解析返回结构。
// utils/request.js const BASE_URL = 'http://localhost:8080/api' function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method, data, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token') || '' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data) } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }) reject(res.data) } else { wx.showToast({ title: res.data.msg, icon: 'none' }) reject(res.data) } }, fail: reject }) }) } module.exports = { request }选座页是前端交互最复杂的部分。座位矩阵渲染的思路：根据场次接口返回的座位数组，按 row 和 col 分组。这里推荐一行代码生成布局思路：
// 座位数据示例：{ id, rowNo, colNo, status } const map = {} seatList.forEach(seat => { const key = `r${seat.rowNo}c${seat.colNo}` map[key] = seat })渲染时外层循环行号、内层循环列号，用map查找具体座位状态。选中座位的逻辑：同一次购票只能选择连续座位，但实现时先不限制数量，点击“确认选座”后提交所选座位数组，后端再校验座位是否都可用。
支付倒计时页面我建议做一个 15:00 倒计时，到期后调用“取消订单”接口。这个倒计时要在前端本地算，不要依赖后端返回的剩余秒数，否则每次刷新都要重新同步。前端代码：
// 简版倒计时 let timer = null function startCountdown(expireTime) { const end = new Date(expireTime.replace(/-/g, '/')).getTime() timer = setInterval(() => { const remain = Math.floor((end - Date.now()) / 1000) if (remain <= 0) { clearInterval(timer) cancelOrder() return } setData({ countdown: formatTime(remain) }) }, 1000) }用date.replace(/-/g, '/')是为了兼容 iOS 的 Date 解析问题，iOS 不识别2025-03-01 14:00:00这种带横杠的格式，只有安卓和开发者工具能解析。这是个经典兼容坑，提醒各位一定注意。
3.4 购票核心接口代码示例
下面这段是“创建订单 + 锁座”的 Service 层核心代码，我给你拆细一点讲：
@Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, Long sessionId, List<Long> seatIds) { // 1. 查询场次信息，校验场次是否存在 Session session = sessionMapper.selectById(sessionId); if (session == null) { throw new BusinessException("场次不存在"); } // 2. 组装订单号 String orderNo = "NO" + System.currentTimeMillis() + RandomUtil.randomNumbers(4); // 3. 循环锁座，使用原子更新语句 for (Long seatId : seatIds) { int rows = seatMapper.lockSeat(seatId, orderNo); if (rows == 0) { throw new BusinessException("座位已被占用，请重新选择"); } } // 4. 计算总金额，创建订单 BigDecimal total = seatIds.size() * session.getPrice(); Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setSessionId(sessionId); order.setTotalAmount(total); order.setStatus(0); order.setExpireTime(LocalDateTime.now().plusMinutes(15)); orderMapper.insert(order); return order.getId(); }这段代码的关键点是@Transactional。有没有注意到我在注解里写了rollbackFor = Exception.class？这是因为 Spring 默认只在遇到运行时异常时回滚事务，如果你抛的是自定义业务异常且它不是 RuntimeException，事务就不会回滚，座位锁了订单却没建成，脏数据就出现了。所以大家写项目时，自定义异常类一定要继承 RuntimeException，或者就在这里显式指定 rollbackFor。
锁座更新语句写一个自定义 SQL，不要用 MyBatis-Plus 的 updateById 去“先查再改”：
@Update("UPDATE seat SET status = 1, order_id = #{orderId} " + "WHERE id = #{id} AND status = 0") int lockSeat(@Param("id") Long id, @Param("orderId") Long orderId);这个思路我在 2.3 里讲过，这里再强调一次：永远不要在高并发场景下用“先查再改”去更新座位，直接用原子更新判断影响行数，这是最简单可靠的防超卖方式。
4. 常见问题与排查技巧实录
4.1 小程序端环境与兼容性问题
开发者工具里一切正常，真机上一片空白。这是小程序开发最经典的问题。大概率是域名的锅，开发者工具可以勾选“不校验合法域名”，但真机不行。你在小程序后台配置 request 合法域名时必须使用 HTTPS，而且域名不能带路径，不能带端口（除非是 443）。如果后端只部署在本地，真机调试只能通过“不校验合法域名”的方式来临时绕过，但这只是开发阶段的权宜之计，答辩前一定要部署到服务器并配好 HTTPS 域名，不然现场演示完蛋。
iOS 时间显示“NaN”。我在 3.3 里提了一句，这里展开说。iOS 对new Date("2025-03-01 14:00:00")解析失败，返回 Invalid Date。解决方案有两种：把时间格式改成2025/03/01 14:00:00；或者在后端直接返回时间戳，前端用时间戳计算并格式化。第二种最稳，推荐采用。
顶部导航栏高度适配问题。小程序胶囊按钮在 Android 和 iOS 上高度不同，自定义导航栏时容易出现顶部按钮错位。常规方案是获取系统信息里statusBarHeight和menuButtonBoundingClientRect，动态计算导航栏高度。不过毕设项目一般不需要自定义导航栏，用官方默认导航栏就够，但如果你为了好看做了自定义导航，一定要把这段适配代码写好，不然演示时顶部按钮位置很奇怪，很减分。
列表页下拉刷新失效。如果你在页面配置了"enablePullDownRefresh": true，但 onPullDownRefresh 里没有调用wx.stopPullDownRefresh()，刷新动画会一直转。这种小问题在答辩演示时特别明显，建议每页都检查一遍。
4.2 后端接口与数据一致性问题
MyBatis-Plus 自动填充时间无效。有些学生想用@TableField(fill = FieldFill.INSERT)自动填充 createTime，但忘记配置 MetaObjectHandler，导致插入的数据时间为 null。建议要么配置 handler，要么直接在代码里setCreateTime(LocalDateTime.now())，毕设项目不差这一行。
SQL 注入风险。用 MyBatis 时，拼接参数必须用#{}，不要图方便用${}。尤其是排序字段、表名这种不能用#{}预编译的场景，一定要做白名单校验。这个知识点几乎是面试必问，也是答辩时老师容易盯上的点。在你写的接口里，排片字段的排序如果直接拼接前端传值，一定要防止注入。
跨域配置。小程序 wx.request 不存在浏览器跨域问题，因为微信客户端没有遵循同源策略。但管理端 Web 页面用 axios 请求后端时，需要在 Spring Boot 里配置跨域过滤器（CorsFilter）。我见过一个学生修了两天，最后发现是跨域拦截器没放行 OPTIONS 预检请求，这里提醒一下：自定义拦截器时，放行所有 OPTIONS 请求，否则 axios 的 preflight 请求被拦截，前端就会报 CORS 错误。
事务失效。除了上面说的 rollbackFor 问题，还有一个经典坑：同一个类里方法自调用，this.createOrder()，Spring 事务就不会生效，因为事务是通过代理类实现的，自调用绕过了代理。排查方法很简单，在方法里打一个日志，看异常回滚是否执行，如果数据库数据还在，基本就命中这个坑了。解决办法是把事务方法拆到另一个 Service 里注入调用，或者用AopContext.currentProxy()（需要开启 exposeProxy）。
4.3 毕设答辩高频问题与应对思路
整理几个我实际带毕设时高频出现的问题，你可以对号入座准备：
“你这个小程序的登录逻辑是什么？”回答要点：wx.login 获取 code，后端请求微信接口换取 openid，再用 openid 查询或创建用户，生成 JWT token 返回前端，前端后续请求在 header 中携带 token，后端拦截器校验。这个链路讲清楚，再加一句“遇到过 code 重复使用会失效，所以前端只调一次”，老师就觉得你有实战经验。
“高并发下你怎么防止座位超卖？”回答要点：座位表同一场次同一座位有唯一索引，锁座时使用数据库原子更新（
UPDATE seat SET status=1 WHERE id=? AND status=0），用影响行数判断是否成功。订单超过 15 分钟未支付则由定时任务释放锁定座位。这三层逻辑讲出来，并发问题基本就过关了。“为什么选 Spring Boot 而不是 SSM？”回答要点：Spring Boot 基于 Spring 注解式开发，内嵌 Tomcat，配置简化；自动装配机制减少了 XML 配置；生态完善，适合快速迭代。千万不要说“因为大家都用它”，要表达成“它解决了传统 SSM 配置繁琐的问题，让我能把精力集中在业务逻辑上”。
“你的系统有什么不足？”不要说“没有不足”。可以提两点：一是支付目前是模拟实现，接入真实支付需要企业主体和商户号；二是锁座超时释放用的是简单定时任务，如果系统规模扩大，可以引入延迟队列或 Redis 过期监听来优化。这两条诚实且有建设性，老师会认可。
5. 最终实操总结与个人经验
做这个项目的过程中，我最深的体会是：毕业设计的价值不在于代码量，而在于你说得清每一个设计决策。很多同学拿到源码第一件事是到处找 bug 改 bug，改完了就交。但实际上，源码里的每个模块，你都应该知道它为什么这么写。比如 token 校验为什么用 JWT 而不是 session？因为小程序是无状态的，服务端保存 session 的话，分布式部署就要做会话同步，而 JWT 天然适合这种无状态接口。再比如订单表为什么冗余订单编号和总金额？因为这属于查询频繁的字段，冗余可以减少联表查询，属于典型的空间换时间。
如果你拿到的是别人写的源码，一定不要急着跑起来，先看这几个地方：
- 数据库表结构是否完整，字段注释清不清楚
- 后端接口是否能单独用 Postman/Swagger 调试，不要依赖前端页面
- 事务、锁、状态更新这类关键逻辑有没有写到 Service 层，而不是 Controller 层
- 小程序端请求封装是否统一，是否每个页面都在裸调 wx.request
还有一个特别实用的小建议：把所有接口用 Apifox 或 Postman 维护好，分好目录、写好参数、保存示例响应。答辩时如果老师想看接口，你打开 Apifox 演示比打开小程序还快。而且接口文档也能直接导出，放毕业设计文档里显得非常专业。我在实际带毕设时发现，那些愿意花半小时维护接口文档的学生，答辩通过率和答辩后的心情，明显比目录乱成一团的学生好。
最后再分享一个小技巧：部署环境尽量和开发环境保持一致。如果你本机是 Windows，部署服务器是 Linux，一定要提前测一下文件路径、中文字符编码、时间格式的差异。我就遇到过学生本机运行一切正常，部署到 Linux 服务器后 MySQL 插入中文变成乱码，最后排查发现是 JDBC URL 少加了一个characterEncoding=utf8。这种问题在答辩前出现一次，足够让人崩溃一夜。把这套源码里的每一个细节都自己跑通、理解透、能讲清，你的毕业设计基本就稳了。做毕设这件事，拼的不是谁的项目最多、谁的界面最炫，而是谁对自己的系统最熟悉、最能在关键时刻把逻辑讲明白。祝顺利。
