简介：这是一份基于微信小程序的电影院购票管理系统完整毕业设计资源包，适合计算机相关专业学生用于课程设计、毕业设计或项目实战。系统前端采用Vue、ElementUI和小程序，后端基于Spring Boot、Spring MVC、MyBatis等主流框架，按管理员与用户双角色设计，覆盖电影/影院/影厅管理、排片、订单、评论、小吃、广告配置以及小程序端电影浏览、购票、口碑分享等完整业务流程。资源包共2006个文件，包括1413个Markdown文档（含项目说明与笔记）、411个JavaScript脚本（前端逻辑）、115个Java源码（后端业务）、48个JSON配置及数据库SQL和设计文档，压缩包大小约65.25MB，目录结构清晰便于查阅。已有30人学习浏览。结合源码、数据库和万字文档，读者可快速理解前后端交互与小程序实现思路，并在此基础上二次开发或直接用于论文撰写与答辩展示。
1. 一套能跑通完整购票链路的小程序系统：技术栈与毕设含金量
从打开小程序选电影，到选定座位、下单支付，最后在“我的”里查到票码，这条链路看着简单，真要自己从零写一遍，排队、锁座、撤单、排片、后台管理这些环节每一个都能让人折腾好几天。基于小程序的电影院购票管理系统，正是把这条链路完整落地的一套毕设级源码包：后端用 SpringBoot + SpringMVC + Spring + MyBatis 的经典 SSM 组合，前端提供 Vue + ElementUI 的管理后台，小程序端覆盖电影浏览、购票、评论、影院套餐、订单查询等完整业务闭环，还附带数据库脚本和万字设计文档。如果你想在毕业设计里选一个“业务足够完整、且容易演示答辩”的方向，这套系统的参考价值比单纯的教育管理系统、商城系统要高不少；哪怕不是做毕设，也可以用它的表结构和订单状态机设计，补齐自己对小程序电商类项目的理解。全文我会按“架构与数据模型、管理员端核心功能、小程序端购票链路、常见坑位、进阶技巧”的顺序拆解，务必让你拿到源码后能快速跑起来。
2. 后端与数据模型：SSM 搭建方式、MySQL 与 Redis 的角色分工
2.1 为什么选择 SpringBoot + SpringMVC + MyBatis 这套组合
这套系统后端用的是 Java 生态里非常成熟的方案。项目构建基于 Maven，SpringBoot 负责自动装配和启动入口，SpringMVC 处理 HTTP 层路由与参数绑定，MyBatis 作为持久层框架操作 MySQL 5.7.26 数据库。Redis 3.0 在这里承担缓存和部分热点数据存储的职责，比如首页轮播广告、电影列表、影厅座位状态之类的高频读取数据。
很多同学看到“SpringBoot + SpringMVC + Spring + MyBatis”会疑惑：SpringBoot 不是已经把 SpringMVC 内置了吗？为什么还要单独列出来？原因是这套项目并非纯粹 SpringBoot 注解驱动的写法，而是保留了传统 SSM 的 XML 或 JavaConfig 配置痕迹，例如 SpringMVC 的拦截器配置、视图解析器配置、MyBatis 的 mapper 扫描配置仍然显式存在。这种写法在早期课程设计、毕设项目中非常普遍，好处是你能直观看到 MVC 每一层是怎么串起来的，而不是像纯 SpringBoot 项目那样“写个 Controller 就能跑”。
这种偏传统的组合对毕设来说反而是优点：答辩时老师问“请求怎么到达 Controller”“MyBatis 怎么处理参数映射”，你可以在配置里找到真实对应内容，而不是背概念。
2.2 数据库表设计：从排片到订单的关系链怎么拆
从功能反推表结构，这套系统至少包含以下核心数据表：用户表、电影表、影院表、影厅表、排片表、订单表、订单明细表、评论表、小吃表、广告表。其中最关键的关系链是“影院——影厅——排片——订单”。
影厅表需要单独设计一个座位字段，常见做法是把座位信息存成 JSON 字符串或文本，例如用seat_map字段保存行、列、座位编号。示例表结构如下：
CREATE TABLE `tb_hall` ( `hall_id` int(11) NOT NULL AUTO_INCREMENT, `cinema_id` int(11) NOT NULL COMMENT '所属影院ID', `hall_name` varchar(50) NOT NULL COMMENT '影厅名称，如1号厅', `seat_rows` int(11) NOT NULL COMMENT '座位行数', `seat_cols` int(11) NOT NULL COMMENT '座位列数', `seat_map` text COMMENT '座位状态映射，JSON存储', PRIMARY KEY (`hall_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里把seat_map设计成 text 类型而不是单独建一张座位表，是很多毕设项目的简化处理。好处是取影厅详情时一次查出来即可，前端拿到 JSON 自己渲染座位图；缺点是如果要做复杂的锁座和并发控制，纯靠这个字段不够，需要配合 Redis 做座位预占。后面第 4 章我会具体讲。
排片表是整个系统的核心表，关联电影、影院、影厅三个维度：
CREATE TABLE `tb_schedule` ( `schedule_id` int(11) NOT NULL AUTO_INCREMENT, `movie_id` int(11) NOT NULL COMMENT '电影ID', `cinema_id` int(11) NOT NULL COMMENT '影院ID', `hall_id` int(11) NOT NULL COMMENT '影厅ID', `show_date` date NOT NULL COMMENT '放映日期', `show_time` varchar(20) NOT NULL COMMENT '放映时间，如18:30', `price` decimal(8,2) NOT NULL COMMENT '票价', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1-排片中 2-已撤销', PRIMARY KEY (`schedule_id`), KEY `idx_movie_date` (`movie_id`, `show_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;status字段是排片撤销逻辑的关键。管理员撤销排片不是物理删除记录，而是把状态从“排片中”改成“已撤销”，这样已经产生的历史订单依然能查到排片信息，不会因为删除导致关联数据出错。订单表也需要记录一个完整的状态流转，从“待支付”到“已支付”再到“已退票/已撤单”。
建表脚本在源码包里是完整可执行的，你拿到后先按文档顺序建库、再导入数据即可。注意表名跟项目里 Mapper 的 resultMap 一一对应，如果自己改字段名，务必同步调整 XML 里的映射关系。
2.3 项目分层与运行顺序：从 IDEA 导入到启动
后端工程建议直接用 IntelliJ IDEA 2021.3 打开，等待 Maven 下载依赖。需要确认本机环境是 JDK 1.8、Maven 3.6 以上、MySQL 5.7.26 或兼容版本。导入后先改application.yml（或.properties）里的数据库账号密码、Redis 连接信息，然后在 MySQL 中执行sql文件夹里的建库脚本。
以下是一份典型的 application.yml 配置片段：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/cinema_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.cinema.system.entity启动类直接运行main方法后，后端服务会监听 8080 端口。但这里有一个毕设项目常见的坑：小程序端不能直接访问http://localhost:8080，因为微信小程序要求请求域名必须是 HTTPS 且已在后台配置合法域名。开发阶段最简单的处理办法是在微信开发者工具里勾选“不校验合法域名”，这样 HTTP 接口也能调试通过。
后台管理系统是 Vue + ElementUI，用 npm 安装依赖：
npm install npm run serve启动后访问本地 Vue 服务端口，登录管理员账号即可看到用户管理、电影管理、排片管理、订单管理等菜单。如果 Vue 项目是通过 axios 请求后端接口，还需要确认vue.config.js里的代理地址是否指向http://localhost:8080。这里我一般建议把代理配好，前端保存后就能直接联调。
3. 管理员端四个核心业务：电影管理、排片、撤单与广告配置的代码落地
3.1 电影管理与海报上传：文件存储路径与静态资源映射
电影管理的增删改查相对标准，重点是海报上传。后端接收 MultipartFile 后需要把文件写到指定目录，然后数据库里只保存访问路径。常见写法如下：
@RequestMapping("/movie/upload") public Result upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("上传文件为空"); } // 原文件名后缀，防止后缀伪造 String originalName = file.getOriginalFilename(); String suffix = originalName.substring(originalName.lastIndexOf(".")); // 新文件名用时间戳加随机数，避免重名覆盖 String newFileName = System.currentTimeMillis() + "_" + new Random().nextInt(1000) + suffix; String path = uploadDir + "/" + newFileName; File dest = new File(path); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } try { file.transferTo(dest); return Result.ok("/upload/" + newFileName); } catch (IOException e) { e.printStackTrace(); return Result.error("上传失败"); } }这里有几个关键点：第一，上传目录不要放在项目源码目录内，否则打包部署时容易丢文件，建议配置绝对路径，例如/usr/local/cinema/upload；第二，映射静态资源的 WebMvcConfig 要把/upload/**指向这个目录，否则前端图片无法回显；第三，毕设答辩时如果图片找不到，八成是上传路径和访问路径没对上，排查优先级最高。
3.2 排片接口设计：按电影和日期查场次的三级筛选
排片模块是管理员端业务量最高的功能。添加排片时前端会先选择电影、再选择影院、再选择影厅，然后设置日期、时间和票价。后端接口通常提供两个查询入口：一个查“可选影院”（根据电影 id 查哪些影院在排片），另一个查“可选影厅”（根据影院 id 查影厅列表）。
添加排片的 Service 核心逻辑如下：
public boolean addSchedule(Schedule schedule) { // 同一影厅同一时间不能存在两条排片，这是基本业务约束 Schedule query = new Schedule(); query.setCinemaId(schedule.getCinemaId()); query.setHallId(schedule.getHallId()); query.setShowDate(schedule.getShowDate()); query.setShowTime(schedule.getShowTime()); List<Schedule> exist = scheduleMapper.selectList(query); if (exist != null && exist.size() > 0) { return false; } schedule.setStatus(1); return scheduleMapper.insert(schedule) > 0; }这段代码体现了一个常见约束：排片冲突检测。如果同一个影厅在同一日期的同一时间被安排了两部电影，用户购票时就会出问题。更完善的做法是加时间段校验，比如一场电影时长 120 分钟，18:00 开场，下一场最早 20:00 才能排，避免开场时间重叠。源码包里如果只做了精确到分钟的去重，你可以在此基础上手动补一个“结束时间”字段做增强。
撤销排片的接口也在这里。撤销时要把排片状态从 1 改成 2，同时需要处理已经产生的订单：
public boolean revokeSchedule(Integer scheduleId) { Schedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null) { return false; } schedule.setStatus(2); scheduleMapper.updateById(schedule); // 把该排片下的未完成订单标记为已撤单 orderService.cancelByScheduleId(scheduleId); return true; }注意这里有事务问题：改排片状态和改订单状态应该放在同一个事务里，否则可能出现“排片已撤销但订单仍显示待支付”的不一致状态。推荐在 Service 方法上加@Transactional。
3.3 订单管理：后台查询、撤单处理与状态流转
后台订单管理要展示用户在小程序下的所有购票订单。列表查询往往需要关联用户表查出用户名、关联排片表查出电影名称和场次时间，所以 Mapper 里的查询一般是多表 join 或者用嵌套查询。关键状态字段orderStatus建议用整数定义，例如 0-待支付、1-已支付、2-已出票、3-已退票、4-已撤单。
撤单操作需要注意一个细节：已支付订单撤单时，需要判断当前时间是否已经超过电影开场时间。如果开场后就不能撤单，否则会造成座位已占用但没有实际观演人的问题。这个判断用 SQL 或者 Java 都可以做，我一般倾向在 Service 层用 Java 先判断：
if (schedule.getShowDate().before(new Date())) { return Result.error("电影已开场，无法撤单"); } // 判断是否开场前一定时间内不允许退票，例如开场前30分钟 long diffMinutes = (schedule.getShowDate().getTime() - System.currentTimeMillis()) / (60 * 1000); if (diffMinutes < 30) { return Result.error("开场前30分钟内不可撤单"); }这样既照顾用户体验，也避免后续小额退款纠纷。源码包里如果只做了状态直接改成已撤单，强烈建议你补上这个时间判断，答辩时是非常好的加分点。
3.4 广告管理与轮播图配置：小程序首页的动态展示逻辑
广告管理对应小程序首页的轮播图。后台维护一个广告列表，每条记录包含图片地址、跳转链接、排序值、启停状态。小程序端首页加载时请求后台接口，根据排序值拉取启用状态的广告列表。
这块业务本身不难，但有一个容易踩的坑：轮播图图片链接如果存的是localhost或内网 IP，小程序真机预览时就会加载失败，必须保证图片可以通过公网或局域网访问。因此部署时要么把图片上传到对象存储，要么在后台配置一个可被手机访问的静态资源域名。在本地开发阶段，使用“不校验合法域名”的模式加上电脑 IP 访问可以临时解决，但演示答辩前最好把资源放到可外网访问的位置。
4. 小程序端购票链路：登录鉴权、电影选座、下单支付与我的模块
4.1 小程序登录与用户身份绑定
小程序端用户第一次打开需要调用微信登录接口获取 code，再传给后端换 openid。后端拿到 openid 后先查用户表是否存在，不存在就自动注册，存在就直接返回登录态。很多毕设项目在这里简化成“前端随便输入昵称即可登录”，但如果你想做得完整，下面的流程值得参考。
小程序端登录核心代码：
wx.login({ success(res) { if (res.code) { wx.request({ url: app.globalData.baseUrl + '/user/login', data: { code: res.code }, success(response) { const data = response.data; if (data.code === 200) { wx.setStorageSync('token', data.data.token); wx.setStorageSync('userInfo', data.data.userInfo); } else { wx.showToast({ title: '登录失败', icon: 'none' }); } } }); } } });后端 Controller 接收 code 后，通过微信接口校验并换取 openid，这一步在实际开发中必须配置小程序的 appid 和 secret。拿到 openid 后生成一个业务侧的 token（可以是 UUID），存 Redis 并设置过期时间，小程序后续请求在 header 里带上这个 token。Redis 在这里的价值就是把“用户登录状态”变成可控制、可过期的会话，而不是每次请求都查数据库校验 openid。
4.2 排片查询与日期选择：小程序端电影列表到购票页的数据流
小程序首页展示电影列表，可以按日期切换查找某一天的排片场次。这里的交互路径是：电影详情页 -> 选择日期 -> 查看该电影在该日期的所有场次 -> 选择场次 -> 进入选座页。
日期选择组件可以自己用原生picker实现，也可以引入第三方日历组件。当初项目里用的是小程序自定义组件，mode="date"就能满足日期选择需求。用户选择日期后，请求后端接口：
wx.request({ url: app.globalData.baseUrl + '/schedule/listByMovieAndDate', data: { movieId: this.data.movieId, showDate: this.data.selectedDate }, success(res) { const list = res.data.data || []; this.setData({ scheduleList: list }); } });这个接口返回的数据中，每条排片包含影院名称、影厅名称、放映时间、票价、余座数量。余座数量怎么算？简单方案是当前影厅总座位数减去该排片下已支付订单占用的座位数。但更准确的方案是基于 Redis 中的座位预占数据，实时计算“可售座位数”。
4.3 选座、下单与支付模拟：座位状态锁定和订单创建
进入选座页后，小程序需要拿到当前排片下座位状态数据。以影厅表的seat_map为基础，结合订单表里已售票座位列表，动态生成每个座位的可售/已售状态。这里最核心的问题是防止“多人同时购买同一个座位”。
后端生成订单的伪代码如下：
@Transactional public Result createOrder(OrderRequest request) { // 1. 校验排片状态 Schedule schedule = scheduleMapper.selectById(request.getScheduleId()); if (schedule == null || schedule.getStatus() != 1) { return Result.error("排片已失效"); } // 2. 校验座位是否可售 List<String> selectedSeats = request.getSeatList(); // 用 Redis 原子性检查并预占 boolean success = redisService.tryLockSeats(schedule.getScheduleId(), selectedSeats); if (!success) { return Result.error("座位已被选中，请重新选择"); } // 3. 生成订单并保存座位信息 Order order = new Order(); order.setScheduleId(schedule.getScheduleId()); order.setSeatInfo(String.join(",", selectedSeats)); order.setTotalPrice(schedule.getPrice() * selectedSeats.size()); order.setStatus(0); // 待支付 orderMapper.insert(order); return Result.ok(order.getOrderId()); }tryLockSeats方法可以基于 Redis 的 SETNX 实现，把一个座位的预占 key 写入 Redis，并设置 5 到 15 分钟过期时间。过期后如果用户未支付，座位自动释放。这套机制是商城系统里“锁库存”的标准做法，虽然源码包里的实现可能比较简单（直接用数据库查选+更新），但你在理解之后可以自行替换成 Redis 方案。
支付模块这里是模拟支付。真实微信支付需要商户号、证书、回调地址等，毕设项目通常用“直接点击支付按钮跳转成已支付”代替。但为了让自己答辩时能说清楚，建议保留一个payType字段，并预留回调接口的结构。
用户支付成功后，订单状态从“待支付”变为“已支付”。这一步在小程序端做请求时，务必要传orderId而不是只传金额，防止后端不知道支付的是哪个订单。正确写法类似：
wx.request({ url: app.globalData.baseUrl + '/order/pay', method: 'POST', data: { orderId: this.data.orderId }, success(res) { if (res.data.code === 200) { wx.showToast({ title: '支付成功', icon: 'success' }); } } });4.4 影院套餐与小吃抢购：秒杀场景的简化实现
影院模块除了展示影院详情，还提供“超值套餐”抢购功能。套餐本质上是一种商品，表结构可以复用小吃表或单独建套餐表，字段包含套餐名称、原价、套餐价、库存、图片。抢购时后端要校验库存是否充足，扣减库存时要防止超卖：
public boolean rushToBuy(Order order) { // 条件更新：库存大于0才扣减，利用数据库行锁 int result = snackMapper.deductStock(order.getSnackId()); if (result <= 0) { return false; } // 生成小吃订单 snackOrderMapper.insert(order); return true; }这里的deductStock对应 SQL：
UPDATE tb_snack SET stock = stock - 1 WHERE snack_id = #{snackId} AND stock > 0;这个写法比先查库存再更新要安全很多，因为它把“库存校验”和“扣减”变成一条原子 SQL，避免并发时超卖。毕设阶段不需要上消息队列，这一招足够应对演示需求。
5. 常见问题与避坑记录：环境、事务、缓存、日期与微信登录
5.1 微信小程序请求不到本地后端接口
现象：开发者工具里页面空白，Network 面板显示请求失败，报ERR_CERT_COMMON_NAME_INVALID或request:fail。
原因：小程序默认要求所有请求域名是 HTTPS 且经过合法域名校验。本地开发是 HTTP 协议，自然被拦截。
解决：打开微信开发者工具，点击右上角“详情” -> “本地设置”，勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。如果是在真机调试，手机和电脑需要连同一个局域网，并把请求地址从localhost改成电脑的局域网 IP。
5.2 LocalDateTime 与 MySQL 日期字段映射报错
现象：请求参数里传日期字符串2025-04-15，后端一接就 400；或者数据库中show_date查出来是 Date，但实体的LocalDate字段映射失败。
原因：SpringMVC 默认不能把字符串自动转成LocalDate/LocalDateTime，需要配置全局日期转换器。MyBatis 对date类型字段映射到LocalDate有时也会因为类型处理器没注册而报错。
解决：在项目中增加一个全局生效的日期绑定配置：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addFormatters(FormatterRegistry registry) { registry.addConverter(new StringToLocalDateConverter()); } }同时，数据库连接串一定要带serverTimezone=Asia/Shanghai，没有这个参数 MySQL 驱动 8.0 以上版本经常报时区异常。源码里如果用旧版驱动、JDK 1.8，也要把useSSL=false加上，避免握手警告。
5.3 撤单或退票后座位没有释放
现象：用户退票后重新选座，发现该座位仍显示“已售”。
原因：撤单操作只改了订单状态，没有同步更新座位状态，也没有清理 Redis 里的预占 key。
解决：在撤单和退票的 Service 方法里，除了更新订单状态，还要把订单对应的座位从已售集合中移除。如果使用了 Redis 预占座位，还要显式删除预占 key。建议把座位释放的逻辑抽成一个独立方法，比如releaseSeats(scheduleId, seatList)，在退票、撤单、订单超时三种场景下统一调用，避免漏改。
5.4 Vue 后台打包后接口地址写死
现象：npm run build 之后部署到服务器，接口请求全部 404；或者开发环境正常，生产环境登录失败。
原因：Vue 项目里的 axiosbaseURL指向http://localhost:8080，本地开发没问题，部署到服务器后这个地址不存在。
解决：不要在生产包写死 IP。正确做法是使用相对路径/api，然后让 Nginx 把/api反向代理到后端服务。如果没有 Nginx，也可以把 baseURL 配置成一个可独立修改的 JS 配置文件，在部署时按环境改。毕设演示若只在本地跑，这一步可以不处理，但一旦要部署到云服务器，这就是最先报错的位置。
5.5 两个 Service 方法之间的 @Transactional 失效
现象：订单创建成功后，如果后面某个更新失败，回滚不完整，出现脏数据。
原因：@Transactional默认只对 public 方法生效，而且同类内部调用this.xxx()不会触发代理，导致事务失效。
解决：事务方法要放到独立的 Service 类中，并且从 Controller 或外部 Bean 调用，不要在同一个类里直接this.method()调用另一个事务方法。另一个常见坑是 MySQL 表引擎不是 InnoDB，MyISAM 不支持事务，检查建表语句里是不是都写了ENGINE=InnoDB。
6. 更进一步：把座位预占和防超卖做成可控的完整方案
如果你打算把系统从“毕设能跑”提升到“生产级逻辑”，或者想在答辩时被问到“高并发怎么办”时从容应答，建议把座位预占方案补全。这里我讲一套比较完整、但又不至于让你无从下手的方案。
先明确目标：同一场次同一座位，任何时间只能被一个人锁定并最终购买。实现分三层。
第一层：购买页发起下单请求时，后端把用户选中的座位写入 Redis 的预占集合。代码如下：
public boolean preSeat(Integer scheduleId, List<String> seatList, String userId) { String key = "schedule:seat:pre:" + scheduleId; // 遍历座位，逐个尝试写入Redis，并设置过期时间 for (String seat : seatList) { String seatKey = key + ":" + seat; Boolean flag = redisTemplate.opsForValue().setIfAbsent(seatKey, userId, 10, TimeUnit.MINUTES); if (flag == null || !flag) { return false; } } return true; }setIfAbsent是原子操作，如果 key 已存在说明被别人预占，直接返回失败。10 分钟是锁的有效期，这样用户即使不下单，座位也能自动释放。Redis key 的命名统一加schedule:seat:pre:前缀，方便后续批量清理。
第二层：用户支付成功后，把座位状态改成真正已售。这一步操作 MySQL，把订单表里保存的座位字符串解析后，与 Redis 中的预占 key 做核对，确认预占者是当前用户，然后更新数据库中的座位状态。这样 Redis 只是临时锁，数据库才是最终状态。
第三层：订单超时未支付的情况，需要定时清理。最轻量的方案是用 Spring 的定时任务，每分钟扫描一次超过 10 分钟未支付的订单：
@Scheduled(fixedDelay = 60000) public void autoCancelExpiredOrders() { // 查询状态为待支付且下单时间小于当前时间10分钟的订单 List<Order> expiredOrders = orderMapper.selectExpiredOrders(10); for (Order order : expiredOrders) { // 释放Redis预占座位 releaseRedisSeat(order.getScheduleId(), order.getSeatInfo()); // 把订单状态置为已取消 orderMapper.updateStatus(order.getOrderId(), 4); } }注意定时任务方法要放在独立的配置类中，并确保@EnableScheduling已开启。座位释放完成后，用户重新进入选座页就能看到位置空出来了。
这套方案做完，一来你能明确说出“Redis 管预占、MySQL 管最终状态、定时任务管超时释放”的分工，二来也展示了分布式锁的基本思路。即便真实并发量不大，这种设计在答辩时非常加分。
除了预占，我还建议你把后台的撤单、用户改签这类边界场景过一遍：电影开场时间是判断能否退票的核心依据，建议设置“开场前 30 分钟停止退票”，并用一个常量配置在代码里，不要散落多处。从那以后我每次处理订票类系统，都会先画一遍完整的状态机，把待支付、已支付、已出票、已退票、已撤单之间的转换条件列出来，再动表结构。这个小习惯能帮你少填很多逻辑坑，希望帮到你。
本文还有配套的精品资源，点击获取
