做文化艺术演出票务系统这个项目，我前后折腾了大半年，从零开始搭了一套基于Spring Boot + Vue的全栈平台，期间还融入了Node.js相关的工程化工具链。今天把这套系统的整体设计、核心技术点、实操过程中踩过的坑一次性梳理出来，给有类似需求的朋友做个参考。
这个项目最终交付的是一套包含用户端、管理员端、票务核心链路以及活动推广模块的完整系统。用户可以在线浏览演出、选座下单、支付购票，管理员可以维护演出场次、管理座位图、处理订单、配置优惠活动。如果你正准备做演出票务、展览预约、影院选座这类带“场次+库存+座位”模型的项目，这篇文章里的很多方案可以直接抄作业。
1. 项目整体设计与技术选型思路
1.1 为什么是Spring Boot + Vue，Node.js在其中扮演什么角色
先明确一个概念：这个标题里出现的三者不是对等关系。Spring Boot是后端主框架，负责业务逻辑、数据持久化、接口输出；Vue负责前端界面渲染；Node.js则贯穿在前端工程化链路里——npm、Vite、Webpack这些构建工具都跑在Node运行时上，联调阶段的Mock服务、接口代理也是Node生态的常见玩法。
选这套组合的核心原因是分工明确、资料多、招人成本低。Spring Boot在Java后端里属于“开箱即用”的类型，内置Tomcat、自动配置、生态成熟，适合快速搭建这种需要稳定事务处理能力的业务系统。Vue在中文社区里的普及率极高，Element UI / Element Plus这类组件库直接解决后台管理的页面需求，开发效率比传统模板引擎高一个量级。
Node.js参与进来的位置，我放在了三个层面：
一是前端工程化工具链。项目用Vite作为开发服务器，所有依赖安装、本地启动、打包构建都通过npm脚本完成。Vite基于ESM，冷启动秒级，热更新体验比老一代Webpack舒服太多。
二是开发期的Mock中间层。因为前端和后端是并行开发的，后端接口还没就绪时，我用Node.js起了一个轻量Mock服务，按照约定好的接口文档返回模拟数据，前端不阻塞。这个中间层在联调完成后直接下线，不会污染生产代码。
三是静态资源托管与部署。前端打包产物是纯静态文件，我放在Node.js驱动的静态服务器里做内网测试，外网正式环境则交给Nginx统一托管。这个细节在后续部署章节会细说。
1.2 票务系统的核心业务流程拆解
文化艺术演出票务系统表面看就是个“商品+订单+支付”的电商系统，但它和普通电商有个明显差异：票务强依赖场次和座位两个维度。
普通卖货是“一件商品对应一个SKU，库存就是数字”，演出票务是“一个演出有多个场次，一个场次有多个座位，每个座位本身就是一个唯一库存单位”。这个差异决定了整条业务链路的复杂度。
我把用户侧的核心流程拆成五步：
- 浏览演出列表，查看详情页里的演出介绍、场次时间、场馆位置；
- 选择场次后进入选座页，根据场馆座位图勾选座位；
- 提交订单，系统锁定座位并生成待支付订单；
- 在支付倒计时内完成支付（我设定15分钟有效）；
- 支付成功生成电子票二维码，演出当天扫码验票入场。
管理侧流程相对集中：演出方（管理员）创建演出项目 → 为项目配置场次 → 为场次导入或绘制座位图 → 设置票价规则 → 上架后用户可见。再加上订单管理、退款处理、优惠活动配置、验票核销几个模块。
这套流程里最容易出问题的不是CRUD本身，而是座位锁定的并发一致性、订单超时释放、支付回调幂等这三个点，后面我会单独展开。
1.3 活动推广模块的设计考量
标题里把“活动推广”和“票务系统”并列，说明这不是一个锦上添花的模块，而是拉新促活的核心手段。我实现的推广能力包括五类：
- 优惠券：满减券、折扣券、新人立减券，支持限定适用范围和有效期；
- 限时秒杀：指定场次在某个时间点开放低价座位，限时限量；
- 分享裂变：用户分享演出链接给好友，好友购票成功后分享者获得奖励金或积分；
- 积分体系：购票获得积分，积分可抵现、可兑换周边；
- 场次预热：未开售场次的“开售提醒”订阅，到点推送通知。
这个模块的设计重点不在于功能多，而在于把推广行为埋进核心购票流程里。比如领取优惠券之后，结算页要自动展示可用券；分享链接要带上渠道参数；秒杀结束前要有倒计时提示。所有推广功能都必须能追踪到最终订单，否则做了一堆活动却衡量不了效果，等于白做。
2. 系统架构与核心数据模型设计
2.1 前后端分离下的目录结构规划
前后端分离最怕的就是“代码放得乱七八糟，联调全靠问”。项目启动第一天我就定好了严格的目录规范，后面所有功能开发都照着这个架子填。
后端Spring Boot工程按模块分包：
src/main/java/com/example/ticket ├── controller # 接口层，只做参数接收和结果封装 ├── service # 业务层，事务边界在这里 ├── mapper # 数据访问层（MyBatis-Plus） ├── entity # 数据库实体 ├── dto # 接口出入参对象 ├── vo # 前端展示对象 ├── config # 配置类（跨域、拦截器、Redis等） ├── common # 统一返回、异常处理、常量 └── utils # 工具类前端Vue工程：
src ├── api # 接口请求封装 ├── views # 页面组件 ├── router # 路由配置 ├── store # 全局状态管理 ├── components # 通用组件 └── utils # 前端工具这套结构没什么新奇，但关键在于强约束。我在项目文档里明确写了：controller里不允许写业务逻辑，service里不允许直接操作HttpServletRequest，所有接口出入参必须用DTO对象而不是Map。一开始大家觉得麻烦，后期联调和排错时才知道这条规矩多值钱。
2.2 数据库表设计与关键字段说明
票务系统的数据表我总共设计了二十多张，核心表有这么几张：
演出相关
| 表名 | 用途 | 关键字段 |
|---|---|---|
| performance | 演出项目 | id, name, category, description, cover_url |
| session | 演出场次 | id, performance_id, venue_id, start_time, end_time, status |
| venue | 场馆 | id, name, address, seat_map_json |
| seat | 座位 | id, venue_id, session_id, row_no, col_no, seat_type, price |
| seat_occupancy | 座位占用记录 | id, session_id, seat_id, order_id, status |
这里有一个设计取舍要说明：座位的价格归属。同一场演出，不同区域（普通区、VIP区）价格不同，我把价格挂在seat表上而不是session表上，因为座位一旦被“分段定价”，价格就是座位的属性；但同一场次如果临时调价，就得批量更新seat表。另一种方案是搞price_rule表按区域映射，动态性强一些，项目初期为了简单我用了第一种。
订单相关
| 表名 | 用途 | 关键字段 |
|---|---|---|
| orders | 订单主表 | id, user_id, session_id, total_amount, pay_amount, status, expire_time |
| order_item | 订单明细 | id, order_id, seat_id, original_price, pay_price, ticket_code |
订单状态我用整型枚举：0待支付、1已支付、2已取消、3已退款、4已完成（已验票）、5已过期。订单主表和明细表分离，方便一张订单买多张票，也方便退单时按明细处理。
推广相关
| 表名 | 用途 | 关键字段 |
|---|---|---|
| coupon_template | 优惠券模板 | id, type, name, threshold, discount, total_count, limit_per_user |
| user_coupon | 用户券实例 | id, user_id, template_id, status, expire_time |
| share_record | 分享记录 | id, user_id, session_id, share_code, invitee_id, commission_status |
| point_record | 积分流水 | id, user_id, change_value, reason, create_time |
推广表里最容易被忽略的是share_record，它必须记录“分享人→被邀请人→是否购票→奖励是否发放”的完整链路，否则推广奖励审计时根本说不清楚。我在share_record上加了一个source_order_id字段，奖励只在被邀请人的首单成功后才触发发放。
2.3 接口设计与权限模型
接口设计上我遵循了RESTful风格，但做了实际妥协。比如订单创建用的是POST /api/orders，支付回调则是POST /api/payment/callback（这是外部支付平台固定的路由，没法强行按资源命名）。
权限模型用了简单的RBAC：用户（USER）、管理员（ADMIN）、超管（SUPER_ADMIN）三种角色。用户端和管理员端的接口路由做了物理隔离，管理后台所有接口统一挂在/api/admin前缀下，通过Spring拦截器校验角色权限。用户端的身份认证用JWT + Redis的方案，拦截器解析token后从Redis读取用户信息，避免每次请求都查数据库。
这里有个小教训：JWT本身是可以解密的，别把敏感信息塞进token里。我只往token里放userId和角色，其余信息一律从Redis或数据库获取。
3. 核心功能实现与实操细节
3.1 演出场次与座位管理
座位图是票务系统里用户体验最直观的部分，也是技术上最容易翻车的部分。我花了不少时间在座位图的渲染和交互上。
座位数据模型上我选择了给每个场次单独存一份座位记录。场次创建时，从场馆的静态seat_map_json生成该场次独立的seat记录列表。这么做的原因是：不同场次可以有不同的开放区域、不同的价格配置，如果所有场次共用一份座位表，临时关闭某场次的某片区域就要额外加状态字段，逻辑会绕很多弯。
前端选座页我用的方案是Canvas绘制座位图，交互数据来自后端接口：
// 座位数据结构 { sessionId: 1001, rows: [ { rowNo: 1, seats: [ { seatId: 1, colNo: 1, status: "available", price: 180 }, { seatId: 2, colNo: 2, status: "occupied", price: 180 } ] } ] }选座组件只维护一个“本地选中列表”，用户每次点击座位时先判断状态：available可以选中、occupied置灰不可点、selected表示已选中可取消。确认选座后调用后端锁定接口，把选中的座位传到服务端做真正的一致性校验。
这里重点说一下座位锁定的实现。多个用户同时选同一个座位，后端必须保证“最后只有一个人锁座成功”。我用的是Redis + Lua脚本做原子操作：
// 伪代码：锁定座位的Redis原子操作 String luaScript = "for i=1,#KEYS do " + "if redis.call('setnx', KEYS[i], ARGV[1]) == 0 then " + "return 0 " + "end " + "end " + "return 1";每个座位在Redis里的key设计为seat:lock:{sessionId}:{seatId}，setnx成功表示锁座成功。加锁之后再把锁定信息写入MySQL的seat_occupancy表，保持Redis和数据库的一致性。锁超时时间我设置的是15分钟，和订单支付有效期保持一致，到期后由定时任务清理释放。
3.2 下单与支付流程的实现要点
订单创建接口是整个系统最核心的一段逻辑，我把它拆成了多个步骤，并且全程包在一个事务里：
- 校验用户登录态；
- 校验场次是否还在售票状态；
- 校验传入的每个座位是否可售、价格是否正确；
- 重新确认座位锁（防止前端绕过锁定直接下单）；
- 计算优惠（满减、积分抵扣、优惠券组合）；
- 创建订单主表和明细表；
- 将座位占用状态置为“已锁定”；
- 发送订单超时延迟消息，用于自动取消。
前端的优惠计算只是个预览，真正的优惠校验和金额计算必须以后端为准。我在开发初期就定了一条规矩：前端传过来的任何金额字段后端都不直接信任，所有金额都按订单明细里的座位价格重新累计算，优惠券的使用条件也在后端校验。这个规矩帮我后续排查账目问题时省了一大堆事。
订单超时释放我用的是延迟消息机制。下单成功后往消息队列发一条延迟15分钟的取消消息，消息到了之后检查订单状态：如果还是待支付就自动取消并释放座位；如果已经支付则忽略。这套方案的优点是不会像定时扫表那样出现“明明超时了但订单还在”的窗口期。
支付环节对接的是常见第三方支付平台的扫码支付和APP支付两套接口。支付回调的幂等处理是重中之重，我用的方案是：
// 支付回调处理：用订单状态做幂等 synchronized (orderId.intern()) { Orders order = orderService.getById(orderId); if (order.getStatus() == 1) { // 已支付过的订单直接返回成功，不再重复处理 return success; } // 更新订单状态为已支付 // 生成电子票二维码 // 发放积分和推广佣金 }这里有个关键细节：orderId.intern()只能保证单机内的互斥，如果服务做了多实例部署，就得换用Redis分布式锁。锁的key用pay:lock:{orderId}，过期时间设置5秒，防止极端情况下的死锁。
3.3 活动推广模块：优惠券、秒杀与分享裂变
优惠券模块的难点不在发券，而在防止超发和重复领取。
超发问题发生在用户同时抢券的高并发场景。因为券模板有一个total_count发行总量，如果直接用数据库的update coupon_template set issued_count = issued_count + 1 where id = ? and issued_count < total_count，在事务并发下会有行锁竞争，性能会急剧下降。我改成了Redis预扣减模式：
// 抢券时先用Redis扣减剩余量 Long remain = redisTemplate.opsForValue() .decrement("coupon:stock:" + templateId); if (remain < 0) { // 补偿回加，返回库存不足 redisTemplate.opsForValue().increment("coupon:stock:" + templateId); throw new BizException("优惠券已被抢完"); } // 扣减成功后再落库生成用户券记录这个先Redis后MySQL的模式，把高并发的库存扣减从数据库压力转移到了Redis，MySQL这边只需要保证最终一致性即可。如果扣减Redis失败或者后续落库失败，需要通过对账任务把差额补回去。
限时秒杀本质上是一种特殊场次，我在session表上加了seckill_start_time、seckill_price、seckill_stock三个字段。秒杀场次的座位不参与普通购票流程，只能通过秒杀接口购买。接口层面加了简单的频率限制：同一个用户对同一个场次的秒杀请求，30秒内只放行一次，Redis里用INCR + EXPIRE实现。
分享裂变是最有意思的部分。每条分享链接会生成一个带shareCode的短链接，用户打开链接后，前端把这个shareCode存入localStorage，注册或下单时带上这个参数。订单支付成功后，后端根据shareCode查找到分享人，发放奖励金。这个链路的关键是shareCode必须跟着首单走，用户在分享链接里注册后过了三个月才买票，奖励也得算到分享人头上去，所以我用Redis把这些信息存了180天。
3.4 前后端联调时的Node.js工具链配置
联调效率直接决定项目进度，这块我踩过不少坑。Vite开发服务器的代理配置是第一个要解决的问题：
// vite.config.js export default defineConfig({ server: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })开发时前端跑在8081，后端Spring Boot跑在8080，Vite把/api开头的请求全部代理到后端，完美规避跨域问题。生产环境部署后，前端静态文件和后端接口都在Nginx后面，同样通过location规则把/api转发到后端服务。跨域这块，我在Spring Boot侧同时加了CORS配置作为兜底，防止某些浏览器环境下代理不生效的情况。
Mock服务是另一个提升联调效率的利器。我写了一个简单的Node.js脚本，读取一个JSON格式的接口约定文件，自动生成路由返回mock数据。约定文件长这样：
{ "/api/session/1001/seats": { "method": "get", "response": { "rows": [] } } }这个方案带来的效果是：前端页面开发完全不依赖后端进度，后端接口联调时前端只改一个baseURL的配置就能切回真实接口，两边互不阻塞。
4. 常见问题与排查实录
4.1 超卖问题与库存扣减
做秒杀活动时第一次压测就暴露了超卖问题。500个并发请求抢100张秒杀票，最终成交了103单，其中3单没有库存却能支付成功。
排查过程是这样的：先看订单表，发现超出的订单座位状态都是“锁定”，但MySQL锁定时有一批请求同时通过了“座位状态=available”的条件判断，出现了经典的check-then-act竞态条件。
修复方案分两层：底层加了Redis原子扣减作为前置防线——每个秒杀场次的Redis库存字段在活动开始前初始化，抢票接口先DECR检查余量，余量耗尽直接拒绝；上层在MySQL里给座位占用记录加了唯一索引uk_session_seat（session_id, seat_id），保证同一个座位无论如何都不可能产生两条有效的占用记录。唯一索引是兜底，Redis扣减是主力，两套都上，超卖从根上断了。
4.2 并发锁座的死锁与活锁
锁座逻辑初期用MySQL悲观锁SELECT ... FOR UPDATE，压测时发现了死锁。原因是用户同时选中了多个座位，我在一个事务里按传入顺序逐条锁座位记录，但两个请求锁座位的顺序正好相反，就互相等待。
解决方案有两个思路：一是强制规定座位请求必须按seatId升序排列后再加锁；二是改用Redis做锁。我最终采用了Redis方案，因为座位锁的粒度本来就细、冲突概率高，用独立Redis锁更容易控制超时时间。Redis锁成功之后，MySQL侧只是记录占用结果，不再承担锁竞争。
4.3 支付回调重复通知与订单状态错乱
支付平台的回调机制是“持续通知直到你返回成功”，所以重复回调是必然的，不是偶然事件。我第一版只做了简单的状态判断，结果在一个退款场景里出了问题：用户支付成功后立即申请退款，退款回调先到了，订单状态变成已退款；随后支付成功的回调又到了，因为判断逻辑是“非已支付就更新为已支付”，订单又被改回了已支付——钱退了，订单却显示已付款，直接账目不平。
后来我把回调处理改成事件驱动的状态机，订单状态只允许按照合法路径流转：待支付→已支付→已退款，任何不合法跳转直接拒绝并记录告警日志。处理回调的第一步永远是查当前状态，然后用分布式锁包住整个状态流转过程，重复回调最多是幂等返回，不会造成二次状态变更。
4.4 前端座位图渲染性能与内存泄漏
演出场馆大的时候一个场次有上千个座位，Vue组件里如果用原生DOM渲染上千个座位元素，选座交互会明显卡顿。我的优化方案是改用Canvas绘制座位图，用requestAnimationFrame控制重绘频率，座位点击用热区检测而不是DOM事件绑定。
内存泄漏问题出在选座页组件销毁后，定时器还在运行。用户在支付页待久了退回选座页，前一页的锁座倒计时定时器没有清理，导致页面内存持续上涨。排查后统一在组件onUnmounted生命周期里清除所有定时器和事件监听，这个问题才解决。
4.5 常见问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 下单后座位仍被其他人抢走 | 座位锁未持久化到MySQL | 检查Redis锁和seat_occupancy记录是否双写成功 |
| 优惠券领取数量超过发行量 | 未做Redis预扣减 | 加Redis库存预扣减逻辑 |
| 支付成功但订单还是待支付 | 回调URL配置错误或回调被拦截 | 检查支付平台回调配置和后端日志 |
| 用户重复支付了两笔 | 前端重复提交订单 | 下单接口做幂等，同用户同座位短时间内去重 |
| 部署后前端页面白屏 | 路由为history模式但Nginx未配置try_files | Nginx加上try_files $uri $uri/ /index.html; |
5. 实操心得与后续扩展建议
这个项目做下来，我最深的体会是：票务系统的核心难点不在功能多少，而在并发一致性和状态管理。所有业务规则都可以靠堆CRUD实现，但“同一个座位只能卖给一个人”“同一个订单只能被支付一次”“优惠券不能超发”这些约束，必须在设计阶段就考虑到并发场景，而不是等功能上线后打补丁。
几个具体的实操建议：
项目一开始就要区分“票务核心链路”和“周边功能”的优先级。第一步先打通演出管理、场次管理、选座、下单、支付这五个环节，形成一个用户能完整走通的闭环；优惠券、积分、秒杀、分享这些推广能力，都应该在这个闭环稳定之后再加。我见过不少团队一上来就做一堆活动功能，结果连票都卖不了，完全是本末倒置。
座位锁的TTL要和支付有效期严格一致。锁的时间太短，用户付款慢一点座位就被释放；太长，恶意用户占着座位不付款会影响正常销售。我最后定的是15分钟，用户下单后支付页有明确的倒计时，倒计时结束订单自动取消、座位自动释放，每一环都对得上。
日志和监控要提前埋好。票务系统涉及钱和库存，出了问题必须能回溯到具体请求。我后来给核心接口都加了操作日志，记录用户ID、请求参数、响应结果、耗时，支付回调做了专门的回调日志表。这个习惯在排查线上问题时帮了大忙。每场演出的座位图用的是Canvas方案，后续如果要支持拖拽式座位编辑，可以在这个基础上扩展，这也是我准备做的方向之一。
