简介：这是一套面向高校计算机专业学生与Java初学者的小程序电影票订票系统完整源码，可作为毕业设计、课程设计或全栈练手项目。资源包含小程序端与后台管理两大部分：小程序端支持信息公告查看、推荐影院、在线订票与支付、优惠券抵扣、附近影院定位、个人中心（历史订单、钱包、优惠券）、影院评价及导航跳转；后台涵盖用户、影院、订票、公告与优惠券管理，业务闭环较为完整。压缩包共416个文件，约36.01MB，以html页面、jar依赖、java源码、class字节码、xml配置、js脚本、json数据、wxss与wxml小程序页面、图片素材及一份sql建库脚本为主，前后端与数据库结构一目了然。技术栈采用SSM框架、JDK1.8、Tomcat7与MySQL5.7，小程序基于uniapp或原生开发，配套Eclipse/IDEA与HBuilder X/微信开发者工具即可运行。目前已有44人学习，适合需要完整赛题方案、排错思路与目录结构参考的读者。
1. 电影票订票小程序这套源码，到底能帮你省下多少事
如果你正在接一个电影票订票类的小程序私活，或者想拿一套完整项目练手全栈开发，那「基于小程序的电影票订票小程序软件源代码（完整前后端+mysql+LW）」这个标题背后的东西，值得你花十分钟看完。它解决的核心问题很具体：选座、场次、订单、支付回调、后台排片这一整条链路，从数据库表结构到小程序端页面再到服务端接口，全部给你串好了。适合谁？一是接外包需要快速交付原型的开发者，二是想学小程序+Node/Java后端+MySQL完整闭环的学生，三是手里有影院资源想做轻量级选座工具的小团队。我见过太多人卡在「座位图怎么画」「锁座怎么防并发」这两个点上，这套源码的价值恰恰在于它把这两个最容易翻车的地方跑通了。
2. 先看懂数据模型：五张核心表撑起整个订票链路
2.1 为什么表设计决定了后面所有接口的写法
拿到一套订票源码，别急着跑起来看页面。我一般先翻数据库建表语句，因为表结构直接暴露了作者对业务的理解深度。电影票订票的本质是「场次 + 座位 + 订单」三者的状态流转，如果表设计得含糊，后面接口一定会出现「同一个座位被两个人下单」这种血泪事故。常见做法是把影片、影院、影厅、场次、座位、订单拆成独立表，用外键或者冗余字段关联。这套源码里最关键的是场次表和座位状态表，前者决定排片，后者决定选座。
先看影片表和场次表的关系。影片表存的是电影基本信息，场次表存的是「某影厅某时间放某部电影」，两者是一对多。很多新手会把影片名直接冗余到场次表里，短期看没问题，但一旦影片信息要改（比如改海报），就得批量更新，这是典型的埋雷。
-- 影片表：只存电影本身的信息 CREATE TABLE `movie` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL COMMENT '影片名', `poster` VARCHAR(255) COMMENT '海报地址', `duration` INT COMMENT '时长(分钟)', `status` TINYINT DEFAULT 1 COMMENT '1上映 0下架' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 场次表：关联影片和影厅，存放映时间 CREATE TABLE `schedule` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `movie_id` INT NOT NULL COMMENT '关联影片', `hall_id` INT NOT NULL COMMENT '关联影厅', `start_time` DATETIME NOT NULL COMMENT '开场时间', `price` DECIMAL(10,2) NOT NULL COMMENT '票价', INDEX `idx_movie` (`movie_id`), INDEX `idx_start` (`start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;上面这段建表语句里，schedule表用movie_id和hall_id做关联而不是冗余影片名，是为了让排片和影片信息解耦。idx_start这个索引很关键，因为用户查「今天有哪些场次」时，查询条件就是start_time的范围，没这个索引数据量一上来就慢。price用DECIMAL而不是FLOAT，是因为金额计算用浮点会出现 0.1+0.2 不等于 0.3 的经典问题，这个坑在订单金额校验时特别致命。
2.2 座位状态表：锁座逻辑的物理基础
座位表是整套系统里最容易设计错的地方。有两种常见方案：一种是把每个座位的状态直接存在场次表的一个 JSON 字段里，另一种是单独建座位状态表。前者写起来快，但并发锁座时几乎没法用行锁，只能整行锁，性能差；后者虽然表数据量大，但可以精确到「某场次某座位」一行记录，锁座时用行级锁，并发安全。
-- 座位状态表：每场次每个座位一行 CREATE TABLE `seat_status` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `schedule_id` INT NOT NULL COMMENT '场次ID', `seat_no` VARCHAR(10) NOT NULL COMMENT '座位号 如 5排8座', `status` TINYINT DEFAULT 0 COMMENT '0可选 1已锁 2已售', `order_id` BIGINT DEFAULT NULL COMMENT '关联订单', `lock_time` DATETIME DEFAULT NULL COMMENT '锁定时间', UNIQUE KEY `uk_schedule_seat` (`schedule_id`, `seat_no`), INDEX `idx_order` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;uk_schedule_seat这个唯一索引是整个锁座逻辑的保险丝。当两个请求同时想锁同一个场次的同一个座位时，数据库层面会保证只有一条插入或更新成功，另一条直接报唯一键冲突。这比在应用层用代码判断「座位是否已被占」可靠得多，因为应用层的判断存在时间窗口，高并发下必然出问题。lock_time字段用于实现「锁座超时释放」，用户下单后没支付，15 分钟后要把座位放出来，这个字段就是判断依据。
3. 后端接口怎么搭：从排片查询到下单锁座的完整链路
3.1 场次查询接口：一次请求拿全选座页所需数据
用户点进一部电影，要看到「哪些影院、哪些时间、什么价格」的场次列表，再点某个场次进入选座页。这两个页面的数据可以拆成两个接口，也可以合并。我一般会拆开，因为场次列表可能被缓存，而选座页的座位状态是实时的，不能缓存。
// 场次列表接口：按影片ID和日期查场次 router.get('/schedule/list', async (req, res) => { const { movieId, date } = req.query; // 日期范围查询，避免全表扫描 const start = `${date} 00:00:00`; const end = `${date} 23:59:59`; const list = await db.query( `SELECT s.id, s.start_time, s.price, h.name AS hall_name, c.name AS cinema_name FROM schedule s JOIN hall h ON s.hall_id = h.id JOIN cinema c ON h.cinema_id = c.id WHERE s.movie_id = ? AND s.start_time BETWEEN ? AND ? ORDER BY s.start_time ASC`, [movieId, start, end] ); res.json({ code: 0, data: list }); });这个接口的关键在BETWEEN ? AND ?的范围查询，配合前面建的idx_start索引，能快速定位某天的场次。参数movieId和date都来自前端，必须做类型校验，否则date传个非法字符串会导致 SQL 报错。返回结构里带上影院名和影厅名，是为了让前端不用再发额外请求，这是减少请求数的常见优化。
3.2 锁座接口：用事务和唯一索引挡住并发
锁座是整个系统技术含量最高的地方。用户在小程序上点选几个座位，点「确认选座」，后端要做的第一件事是「把这些座位标记为已锁」，并且保证别人不能再选。这里必须用数据库事务，把「检查座位状态」和「更新座位状态」放在一个原子操作里。
// 锁座接口：事务 + 唯一索引防并发 router.post('/seat/lock', async (req, res) => { const { scheduleId, seats, userId } = req.body; const conn = await db.getConnection(); try { await conn.beginTransaction(); // 先查这些座位当前状态，FOR UPDATE 加行锁 const [rows] = await conn.query( `SELECT seat_no, status FROM seat_status WHERE schedule_id = ? AND seat_no IN (?) FOR UPDATE`, [scheduleId, seats] ); // 只要有一个座位不是可选状态，就回滚 const occupied = rows.filter(r => r.status !== 0); if (occupied.length > 0) { await conn.rollback(); return res.json({ code: 1, msg: '座位已被选', seats: occupied.map(r => r.seat_no) }); } // 全部可选，批量更新为已锁 await conn.query( `UPDATE seat_status SET status = 1, lock_time = NOW() WHERE schedule_id = ? AND seat_no IN (?)`, [scheduleId, seats] ); await conn.commit(); res.json({ code: 0, msg: '锁座成功' }); } catch (e) { await conn.rollback(); res.json({ code: 500, msg: '系统繁忙' }); } finally { conn.release(); } });FOR UPDATE是这段代码的核心，它会对查询到的行加排他锁，其他事务想改这些行必须等当前事务提交。配合seat_status表的唯一索引，即使两个请求同时进来，数据库也会串行化处理。lock_time记录锁定时刻，后面用定时任务扫描超过 15 分钟还是status=1的记录，把它们改回0，这就是锁座超时释放。注意conn.release()必须放在finally里，否则连接池会被耗尽，这是新手最容易犯的错。
3.3 下单与支付回调：状态流转不能乱
锁座成功后，用户进入确认订单页，点支付，后端生成订单并调起支付。支付成功后，第三方会回调你的接口，这时候要把座位状态从「已锁」改成「已售」，并写入订单。这里的状态流转顺序不能乱：先锁座 → 再生成待支付订单 → 支付回调 → 改座位为已售 + 订单改已支付。如果顺序错了，比如先改座位为已售再等支付，那用户不支付就会导致座位白白被占。
// 支付回调：验签后更新订单和座位状态 router.post('/pay/callback', async (req, res) => { const { orderNo, tradeNo, sign } = req.body; // 验签逻辑省略，生产环境必须校验 const conn = await db.getConnection(); try { await conn.beginTransaction(); // 订单状态从待支付改为已支付 const [result] = await conn.query( `UPDATE orders SET status = 1, trade_no = ? WHERE order_no = ? AND status = 0`, [tradeNo, orderNo] ); // 如果影响行数为0，说明订单已处理过，直接返回成功 if (result.affectedRows === 0) { await conn.commit(); return res.send('success'); } // 把该订单关联的座位改为已售 await conn.query( `UPDATE seat_status SET status = 2 WHERE order_id = ( SELECT id FROM orders WHERE order_no = ? )`, [orderNo] ); await conn.commit(); res.send('success'); } catch (e) { await conn.rollback(); res.send('fail'); } finally { conn.release(); } });WHERE order_no = ? AND status = 0这个条件是为了幂等，支付平台可能重复回调，加上状态判断后，第二次回调影响行数为 0，直接返回成功，不会重复改座位。affectedRows这个返回值一定要判断，这是处理重复回调的标准做法。座位状态改成2而不是删除记录，是为了保留历史数据，方便后台统计上座率。
4. 小程序端选座页怎么做：座位图渲染与交互细节
4.1 座位图的数据结构设计
小程序端选座页的核心是把座位排布画出来。常见做法是用view配合flex布局，每个座位是一个小方块。数据从后端拿到的是一个座位号列表，前端需要把它转换成「几排几座」的二维结构。这里有个细节：影厅的座位排布不是简单的矩形，可能有过道、有情侣座，所以后端返回的座位数据最好带上row和col字段，前端直接按坐标渲染。
// 把后端返回的座位列表转成二维数组 function buildSeatMap(seatList) { const map = {}; seatList.forEach(seat => { // seatNo 格式如 "5排8座"，解析出排和座 const match = seat.seatNo.match(/(\d+)排(\d+)座/); if (!match) return; const row = parseInt(match[1]); const col = parseInt(match[2]); if (!map[row]) map[row] = []; map[row][col] = { seatNo: seat.seatNo, status: seat.status // 0可选 1已锁 2已售 }; }); return map; }这个转换函数把扁平的座位列表变成以排为 key 的对象，前端渲染时遍历排，再遍历座。status字段决定座位的颜色：可选是白色，已锁是灰色，已售是红色。注意match可能返回 null，因为座位号格式不一定规范，加个判断避免报错。
4.2 选座交互：点击切换与已选数量限制
用户点击座位时，要切换选中状态，同时限制最多选 4 个或 6 个（根据影院规则）。这里的状态管理用小程序页面的data存一个已选座位数组，点击时判断是否已在数组中，在就移除，不在就加入，但加入前要检查数量上限。
// 点击座位事件 onSeatTap(e) { const { seatNo, status } = e.currentTarget.dataset; // 已锁或已售的座位不能点 if (status !== 0) return; let selected = this.data.selectedSeats; const idx = selected.indexOf(seatNo); if (idx > -1) { // 已选中，取消选中 selected.splice(idx, 1); } else { // 未选中，检查上限 if (selected.length >= 4) { wx.showToast({ title: '最多选4个座位', icon: 'none' }); return; } selected.push(seatNo); } this.setData({ selectedSeats: selected }); }e.currentTarget.dataset拿到的是渲染时绑定的座位号和状态，status !== 0直接拦截不可选座位。selected.indexOf判断是否已选，这是数组操作的常规写法。上限判断放在加入之前，避免先加入再回退的闪烁。setData更新后，座位颜色通过selectedSeats.includes(seatNo)动态计算。
5. 避坑指南：这套源码跑起来最容易翻车的五个地方
5.1 座位唯一索引没建，并发下单出现重座
现象：两个人同时选同一个座位，都能下单成功，后台一看两个订单关联了同一个座位。原因：seat_status表只建了普通索引，没有唯一索引，两个事务同时更新同一行时，后一个覆盖了前一个。解决：把(schedule_id, seat_no)建成唯一索引，并在锁座接口里用FOR UPDATE加行锁，双保险。
5.2 锁座后没释放，座位永久占用
现象：用户选了座但没支付，退出小程序后，这个座位一直显示已锁，别人选不了。原因：锁座时写了lock_time，但没有定时任务去清理超时锁。解决：加一个每分钟跑一次的定时任务，把status=1且lock_time超过 15 分钟的记录改回0。注意时间阈值要和前端提示的「15分钟内完成支付」保持一致。
5.3 支付回调没做幂等，订单状态被重复改
现象：支付平台回调了两次，第二次把已经改好的订单又改了一遍，座位状态出现异常。原因：回调接口没有判断订单当前状态，直接执行更新。解决：更新时加AND status = 0条件，判断affectedRows，为 0 说明已处理过，直接返回成功。这是支付回调的标准写法，任何涉及支付的接口都要考虑幂等。
5.4 场次时间用字符串比较，跨天查询出错
现象：查「明天」的场次，结果把「今天深夜」的场次也查出来了。原因：start_time存的是DATETIME，但查询时用字符串拼接BETWEEN '2024-01-01' AND '2024-01-01'，导致范围不对。解决：日期范围要精确到00:00:00和23:59:59，或者直接用DATE(start_time) = ?函数，但后者会导致索引失效，数据量大时优先用范围查询。
5.5 小程序端座位图渲染卡顿，几百个座位掉帧
现象：大影厅有 300 多个座位，选座页滑动卡顿，点击响应慢。原因：每个座位是一个独立的view，setData更新时整个列表重渲染。解决：把座位按排分组，每排一个view，减少节点数；点击时只更新变化的座位，用setData的路径更新selectedSeats而不是整个数组。如果还卡，考虑用canvas绘制座位图，但交互逻辑要自己实现。
6. 进阶技巧：把锁座超时释放做成可配置的定时任务
前面提到锁座超时释放，这里展开讲一个我实际用过的实现方式。核心思路是用一个定时任务扫描seat_status表，把超时的锁座记录释放掉。但直接UPDATE全表会锁太多行，影响正常下单，所以要分批处理。
// 每分钟执行一次，分批释放超时锁座 async function releaseExpiredSeats() { const BATCH_SIZE = 200; const TIMEOUT_MINUTES = 15; let total = 0; while (true) { // 只查超时的，LIMIT 控制单次处理量 const [rows] = await db.query( `SELECT id FROM seat_status WHERE status = 1 AND lock_time < DATE_SUB(NOW(), INTERVAL ? MINUTE) LIMIT ?`, [TIMEOUT_MINUTES, BATCH_SIZE] ); if (rows.length === 0) break; const ids = rows.map(r => r.id); await db.query( `UPDATE seat_status SET status = 0, lock_time = NULL WHERE id IN (?)`, [ids] ); total += rows.length; // 每批之间歇 100ms，给正常请求让路 await new Promise(r => setTimeout(r, 100)); } if (total > 0) console.log(`释放超时座位 ${total} 个`); } // 启动定时器 setInterval(releaseExpiredSeats, 60 * 1000);DATE_SUB(NOW(), INTERVAL ? MINUTE)是 MySQL 的日期函数，比在应用层算好时间再传参更直观。LIMIT分批是为了避免一次更新太多行导致锁等待，BATCH_SIZE设 200 是个经验值，太小任务跑得慢，太大影响正常业务。每批之间setTimeout歇 100ms，是给数据库喘息时间，这个细节在高并发场景下能明显减少慢查询。
TIMEOUT_MINUTES这个参数我建议做成配置项，因为不同影院的规则不一样，有的要求 10 分钟，有的 20 分钟。配置化之后，改规则不用改代码。另外，释放座位时要把lock_time置为NULL，否则下次扫描还会扫到这条记录，虽然status=0不会被更新，但白白浪费查询。
还有一个容易忽略的点：如果用户锁座后，订单已经生成了但没支付，释放座位的同时要不要把订单也关掉？我的做法是订单表加一个expire_time字段，定时任务同时扫描超时未支付的订单，把订单状态改为「已取消」。这样座位和订单状态一致，不会出现「座位释放了但订单还挂着」的脏数据。
最后说个我踩过的坑：定时任务在多个服务实例部署时会重复执行，导致同一个座位被释放两次。解决办法是用分布式锁，或者把定时任务单独部署成一个服务。如果项目规模小，单实例部署，这个问题可以暂时忽略，但心里要有数。希望帮到你。
本文还有配套的精品资源，点击获取
