又是一个老熟人项目。每年这个时间节点某高校的软件工程、计算机专业的同学都会陆陆续续开始挠头做课程设计或者毕业设计而“票务系统”这四个字出现的频率尤其高。不过这次标题里多了两个限定词——“话剧”和“微信小程序”这就比传统纯网页端的CRUD增删改查系统有意思多了也贴合现在移动端消费的习惯。这个项目说白了就是一个完整的全栈实战前端用微信小程序做用户端C端后台管理用Spring Boot做服务端同时兼顾了客户购票与运营管理两条核心业务线。对于需要完成课设、毕设的同学来说这个题目的难度适中——不会像纯电商系统那样庞大复杂但又比单纯的学生管理系统更有业务深度和展示亮点。这篇就基于我个人的实战经验把这个项目的骨架、细节、坑点一次讲透方便你直接参考复现。1. 项目全景需求拆解与技术选型背后的考量很多同学拿到这种题目第一反应是去找源码或者直接搜“XX管理系统”的代码改吧改吧。我建议你先别急先花半小时把这个项目该有的模样在脑子里画出来这样无论是写文档、做PPT还是答辩你心里都有底也不怕导师问细节。1.1 核心业务需求解析不只是卖票那么简单这个项目叫“话剧票务管理系统”首先得想清楚一个问题它和普通的电影票、火车票系统有什么本质区别话剧、舞台剧这类演出通常有这些业务特征一是场次稀缺性强一场话剧的座位就那些不像电影可以随时加场所以座位管理是核心中的核心。二是座位价值差异化话剧厅通常是分区定价一楼前排、中排、侧边、二楼包厢价格都不一样甚至同一场次同一排的中间和两边体验差距也很大。这决定了系统必须支持灵活的座位与价格策略。三是订单时效性强用户下单后如果迟迟不支付座位需要被释放否则会影响他人购票这就需要订单超时关闭机制。四是运营管理诉求明显主办方需要知道哪个场次卖得好哪类观众是主力退票情况如何这些数据要能被查询和统计。所以这个系统的功能模块天然就分为两块用户端微信小程序浏览话剧列表、查看演出详情与场次、选座下单、在线支付模拟或真实、查看订单、取消订单/退票、个人中心。管理端Web或接口形式演出信息管理上架/下架/推荐、场次管理开演时间、价格设置、座位管理锁定/释放、订单管理查询/发货或核销、统计报表销量/营收/热门场次。记住做课设不是只把功能堆上去就行而是要把这套业务流程跑通答辩时讲清楚这套逻辑项目的档次一下子就上来了。1.2 为什么选Spring Boot 微信小程序这个组合技术选型上这个项目给出了一个非常标准也几乎是目前课设最优解的方案后端Spring Boot前端不是Web页面而是微信小程序。选Spring Boot的原因非常务实。本身它轻量、内嵌Tomcat容器打成一个jar包就能跑部署不像老的SSHStrutsSpringHibernate体系那么痛苦。Spring Boot的自动装配机制让开发人员能快速搭建一个能提供RESTful API的服务端。加上它和MyBatis Plus这类ORM框架配合开发效率很高数据库操作也直观非常适合周期只有几周的学生项目。而选微信小程序作为前端价值更明显使用门槛低现在微信几乎人人都在用不用额外装App。微信自带登录体系解决了用户认证这个最麻烦的问题拿到微信的openid当作用户唯一标识。审核发布流程对校园场景还比较友好体验贴近真实商业产品。对于评委老师来说能现场掏出手机扫码体验一把“买票”比在电脑上看网页有冲击力得多。另外需要说明网上还有一种实现是后台管理也做成微信小程序但我个人更建议管理端做成PC端的Web页面前端用Vue或Thymeleaf模板引擎即可或者干脆只提供一套管理员专用的RESTful接口配合Swagger文档。因为后台管理天然适合大屏和PC操作硬塞进小程序里反而别扭。结论Spring Boot负责后端API微信小程序负责C端用户交互管理端用Web页面——这是一个分工明确、各自发挥长处的组合答辩时能在“为什么这么选型”的问题上拿到不错的分数。2. 系统架构与数据库设计先把地基打牢2.1 前后端交互的架构逻辑整个系统跑起来的逻辑是这样的用户打开微信小程序微信客户端调用后端的登录接口后端拿着小程序传过来的code去微信服务器换openid和session_key用openid在本系统里登记注册为新用户返回一个自定义的登录态Token。之后小程序的所有请求都带着这个Token后端通过拦截器或切面校验这个Token识别用户身份。后端Spring Boot按经典分层来设计Controller层负责接收HTTP请求做参数校验返回统一格式的JSON。Service层业务逻辑核心比如创建订单时要锁定座位、校验库存、计算金额这些逻辑都在这里。Mapper层DAO层MyBatis Plus操作数据库单表查询几乎不用写XML多表查询或复杂统计再写几条SQL。实体类对应数据库表结构。数据库用MySQL就行5.7或8.0都可以。连接池可以用Druid方便监控SQL执行情况。2.2 核心数据表结构与关系设计数据库设计是这个系统最需要花心思的地方直接决定后期开发是否顺畅。我这里给出经过实践检验的核心表结构用户表t_user字段id、openid微信唯一标识、nickname、avatar_url、phone、create_time。 这个表比较简单但要注意openid必须加唯一索引。话剧表t_play字段id、title剧名、cover_url封面、detail_url详情页大图、description简介、status上架/下架、create_time。 注意话剧本身不存票价票价挂在具体场次上这样同一部剧不同场次可以定不同价格。场次表t_session字段id、play_id、session_time开演时间、duration时长、venue演出场馆、session_status未开售/售卖中/已售罄/已结束、row_num总排数、col_num每排座位数、total_seat_count、locked_seat_count。 场次表是连接话剧与座位的桥梁这个设计很关键。座位表t_seat字段id、session_id、row_code排号、col_code列号、seat_type普通区/优享区/包厢区、price单价这是冗余字段因为座位类型不同价格不同、status0可用、1锁定、2已售出。 注意座位表是预生成的。建场次时根据row_num和col_num批量生成这场演出的所有座位记录并在场次表里维护总座位数。这样选座时前端能直接拉到二维座位图数据后端锁定、释放、售出三个状态直接对座位记录做状态流转。订单表t_order字段id、order_no业务订单号、user_id、session_id、seat_id、play_title、session_time、seat_info比如“A区3排5号”、amount_paid、status1待支付、2已支付、3已取消、4已核销/已使用、create_time、pay_time、cancel_time。这里有两个细节需要说明一是订单号建议用业务规则生成比如年月日时分秒加随机数不依赖数据库自增ID这样更像真实电商系统。二是订单表和座位表的关系很多新手会做成“一对多”——一个订单买多张票。但话剧票务场景里座位是极度敏感的。单座位下单会更简单可靠一次买个座位重复购票通过订单列表的扩展指标统计。当然也可以设计成订单头表订单明细表两条结构更规范但考虑到是课设单表记录座位关联配合设计一个“订单明细字段”如seat_ids在开发效率和演示效果上更平衡。退款/取消记录表t_order_log字段id、order_id、operate_type1创建、2支付、3取消、4核销、operate_desc、create_time。 用于追溯订单生命周期的每一步操作答辩时能讲出一个完整的订单状态机这就是加分项。另外如果有评价功能可以加一张评论表一般院校的课设演示到这里其实已经够用了。2.3 座位选型策略的落地座位设计这块我说明一下为什么采用“预生成座位”而不是“存已售座位号”的方案。如果只存已售座位号每次查询剩余座位得做一次集合求差运算而且前端画座位图时要通过循环判断哪些是空位交互逻辑很别扭。相反在MySQL中维护每场演出的完整座位数据每个座位一个记录、一个状态前端直接查询该场次的座位列表拿到所有数据一次性渲染。每个座位绑定status值点击时前端轻松判断后端校验时也只需要一条update语句判断“能否将该座位状态从0改成1”并且更新影响行数。如果影响行数为0说明座位状态已经不是“可用”了直接提示用户被抢。这个方案叫做“乐观锁思想的变种”本质是通过数据库的行锁来规避并发问题。这也是课设答辩时你可以重点展示的含金量点我考虑到了并发场景下的座位超售问题。出于性能考虑小厅话剧一两千个座位每次创建订单只是更新单行记录这压力MySQL完全扛得住不需要引入Redis等额外中间件。这一点可以在文档里写明展示你对技术边界的判断。3. 后端Spring Boot核心实现从用户登录到订单闭环3.1 微信小程序登录与Token鉴权微信登录的流程是这个项目的第一个关卡很多同学卡在了这里。我先理顺完整闭环小程序端调用wx.login()获取临时code。 后端在Controller里接收code调用微信接口GET https://api.weixin.qq.com/sns/jscode2session?appidAPPIDsecretSECRETjs_codeCODEgrant_typeauthorization_code。后端拿到返回的openid后去t_user表查如果不存在则自动注册一个新用户如果存在则直接登录成功。后端生成一个UUID作为Token存到Redis或数据库表里课设不想引入Redis可以放到数据库一张token表或者用JWT方式返回给小程序。小程序将Token存入storage后续所有请求在header里携带token。这里重点提醒几个坑微信的code只能使用一次用完就失效不能跨会话复用。appsecret非常敏感任何情况下都不要放在小程序前端代码里必须放在后端。获取openid的接口需要后端通过HTTP客户端调用可以用Hutool的HttpUtil也可以用Spring的RestTemplate。要处理微信接口超时和网络异常的情况返回给前端一个友好的错误提示。Token这一层如果你不想写复杂的拦截器可以用Spring MVC提供的HandlerInterceptor重写preHandle方法从Header拿到Token到库里查一下有没有对应的用户没有就返回401状态码。3.2 座位的锁定、释放与售卖状态机座位状态机是秩序的关键也是一旦做不好就被人喷的设计。我直接给你画出状态流转的核心规则状态0可用 - 状态1锁定用户点击“提交订单”时触发锁定后这个座位别人看不到了。 状态1锁定 - 状态0可用订单超时未支付或用户主动取消座位释放。 状态1锁定 - 状态2已售出用户支付成功座位不可再流转。 状态0可用 - 状态2已售出这个路径严格来说不该走否则容易绕开锁座流程引起超卖需要靠接口隔离来规避唯一的售票入口就是“锁定后支付”所以如果前端绕过锁定直接调用了支付接口后端校验座位状态已经不再是“可用”直接提示异常。这里要特别强调超时释放的实现。真实项目一般用延迟队列或定时任务扫单课设里最简单的方案是在订单表中加一个“锁定时间”字段或者复用create_time字段再加一个状态“待支付”。后端启动一个Spring Boot的定时任务每30秒扫描一次查出所有“已锁定”且“创建时间超过15分钟”的订单将订单状态改为“已取消”同时将对应座位状态改回“可用”。之所以要这套逻辑是因为微信小程序的体验中用户可能在选座页面停留很久如果不自动释放座位会被“占着茅坑不拉屎”运营那边还得手忙脚乱地处理这让人觉得系统不专业。3.3 订单创建接口核心代码逻辑示例下面把订单创建最核心的接口写出来精简版感受一下这个业务链路的严密性。Transactional public OrderVO createOrder(Long userId, Long sessionId, Long seatId) { // 1. 查场次校验状态 Session session sessionMapper.selectById(sessionId); if (session null || session.getSessionStatus() ! SessionStatus.SELLING.getCode()) { throw new BizException(该场次不在售卖期); } // 2. 尝试锁定座位乐观锁思路关键一步 int lockCount seatMapper.updateStatusBySeatId(seatId, SeatStatus.AVAILABLE, SeatStatus.LOCKED); if (lockCount 0) { throw new BizException(座位已被抢购请更换座位); } // 3. 查询座位信息构造订单 Seat seat seatMapper.selectById(seatId); Play play playMapper.selectById(session.getPlayId()); String seatInfo seat.getRowCode() 排 seat.getColCode() 号; Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setSessionId(sessionId); order.setSeatId(seatId); order.setPlayTitle(play.getTitle()); order.setSessionTime(session.getSessionTime()); order.setSeatInfo(seatInfo); order.setAmountPaid(seat.getPrice()); order.setStatus(OrderStatus.PENDING_PAY.getCode()); orderMapper.insert(order); // 4. 记录操作日志 orderLogMapper.insert(OrderLog.build(order.getId(), 创建订单锁定座位 seatInfo)); return buildOrderVO(order); }这里的灵魂就在第二步那条乐观锁updateUPDATE t_seat SET status 1 WHERE id #{seatId} AND status 0MySQL执行更新时对行加锁同时where条件里带上“status 0”就是判断了这个座位在锁定瞬间是否还是可用的。高并发下两个用户同时抢同一个座位只会有一个用户的update影响行数为1另一个为0后者的请求就直接被拒了。这就是防止超卖的保险丝。注意update操作返回0时一定要主动抛异常回滚事务否则座位虽然被锁了订单却没查到数据库就出现脏数据了。3.4 管理端的统计报表设计作为一个票务管理系统运营管理侧的报表能力是很有展示价值的。最少要实现三个维度一是场次销量统计按场次分组统计每个场次售出票数和销售额SQL一句GROUP BY就能搞定。二是热门话剧排行按话剧分组统计票房关联t_play表查出剧名和封面。三是每日订单量趋势按日期分组统计订单数画成折线图能看到哪几天是购票高峰期。管理端的Web页面可以用VueElementUI也可以尽量简化使用Bootstrap甚至服务端渲染只要清楚把表格和图表数据展示出来就行。有时候页面用ECharts画两张图答辩可视度直接拉满。4. 微信小程序端从界面渲染到交互体验4.1 小程序页面结构规划小程序端页面不宜太多但一定要保证业务逻辑闭环。我建议规划以下5个核心页面首页pages/index/index展示轮播图推荐位、话剧列表、搜索框支持对热门剧目排序。 详情页pages/detail/detail话剧图文详情、场次选择。 选座页pages/seat/seat核心交互页座位二维图渲染、点击选座、确认下单。 订单列表页pages/order/order我的订单按状态区分待支付/已支付/已取消。 订单详情/支付页pages/orderDetail/orderDetail展示订单信息发起支付或取消订单。另外还有个人中心页pages/mine/mine用于展示用户信息和登录状态。微信小程序的底部TabBar推荐放3个首页、订单、个人中心。选座页通过路由跳转进入这样逻辑干净。4.2 座位图二维渲染的实现方法座位图是选座页的视觉核心。效果逻辑很简单后端下发一个二维数组或者扁平数组带座位坐标信息即可。前端拿到数组通过wxml的wx:for嵌套循环渲染纵向循环排、横向循环列。这里有一个优化思路如果座位数据比较大上千个座位一次性渲染上千个节点会卡顿。课设不影响演示但你可以用canvas重绘座位图或者考虑虚拟滚动。不过一般几百座的小剧场不会有明显卡顿用view布局足够。座位状态颜色需要有个约定灰色已售出不可点。白色可用可以点选。蓝色或橙色当前选中。锁定时前端要实时刷新防止别人占座。点击一个座位时立即弹层询问“确认选择该座位”以便提示用户当前座位单价。用户确认后才调后端createOrder接口锁定座位然后跳转到支付确认页面。4.3 支付环节怎么设计真实项目会接入微信支付但个人开发者的微信支付资质不太容易申请课设阶段通常不需要真的调起支付。我在项目里采用的方式是“模拟支付”下单后停留在“待支付”状态页面里给出“确认支付”按钮点击后调后端的mockPay接口直接把订单状态改成“已支付”并把座位状态改为“已售出”。这里需要注意的是虽然是模拟支付业务流程依然要严谨走完。mockPay接口里依然要校验订单是否归属当前用户、订单状态是否为待支付。不要让用户直接修改前端“已支付”就完事儿要确保绕过后端也会被拦截。为了演示真实感可以加一个支付倒计时比如前端页面上设置15分钟倒计时倒计时结束自动刷新订单状态提示“订单超时已取消”。这套交互会让人觉得这个系统不是玩具。4.4 全局状态管理与请求封装小程序开发虽然不像Vue项目那么强调状态管理但有一点必须做封装request请求工具。// utils/request.js const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, token: wx.getStorageSync(token) }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); }封装的几个好处一是统一携带token每个页面不用重复写二是统一处理业务码和错误提示页面代码整洁三是方便统一拦截登录失效res.code为401时跳转登录页并清空storage。这一套代码写出来在答辩里是一个很明确的“工程化思维”体现。5. 常见问题与排查技巧实录开发这个系统总会遇到各种“翻车”现场我把几个高频问题和排查思路整理出来看到就是省时间。现象可能原因排查与解决方案数据库导入SQL时报错MySQL版本兼容性检查SQL的字符集设置统一utf8mb4确认无需手动为所有表加前缀把数据库排序规则设为utf8mb4_general_ci小程序请求后端一直失败合法域名未配置 / 本地不勾选“不校验合法域名”开发者工具右上角详情-本地设置-勾选“不校验合法域名...”真机调试时也必须关闭校验调试阶段推荐用局域网IP加端口访问后端报“Access denied”但接口写对了拦截器放行问题检查LoginInterceptor对所有路径的preHandle逻辑确认静态资源/登录接口/接口文档白名单已放行用户同时抢同一座位后台订单重复座位更新SQL条件缺失核对update时是否带status0条件配合数据库行锁无该条件必然超卖查询座位列表出现重复数据连表查询没有去重检查SQL是否有join笛卡尔积风险小程序真机上图片无法显示图片域名不合法图片统一上传到对象存储或后端本地静态目录并配置允许访问的白名单开发阶段可以把图片转成base64临时用订单状态卡在“待支付”但座位被锁了定时任务未生效检查Scheduled是否在主启动类或配置类启用检查cron表达式是否正确微信登录code换openid失败appid/appsecret配置错误核对小程序的AppID是哪个后端配置文件中的参数是否和微信公众平台一致后端接口返回JSON中时间格式不对日期序列化问题在全局配置文件里规定时间格式如yyyy-MM-dd HH:mm:ss避免返回一串时间戳部署服务器后小程序无法通过IP访问防火墙/安全组未开端口检查服务器防火墙以及云服务商安全组是否放行了对应的Spring Boot端口这拦腰斩断一些坑后再补充两个实战心得心得一关于数据库字段设计所有价格字段建议直接用整数类型比如“元”的100倍单位为“分”避免出现浮点运算时0.10.2不等于0.3这种经典问题。如果你用BigDecimal记得使用BigDecimal.valueOf传入字符串或使用scale避免构造精确值误差。展示时前端除以100格式化成人人能看懂的货币格式即可。心得二关于日志从开发到答辩前在整个链路的关键步骤都加上日志打印特别是“创建订单-锁定座位失败”这种接口打印出的业务异常日志能给你节省非常多排查时间。我记得某一版项目就是没打日志结果前端一直报“座位已被抢”后端看不了日志愣是排查了半天才发现是update语句字段写错了。6. 部署、演示与文档写作经验6.1 本地开发和部署的建议本地开发阶段Spring Boot默认的8080端口加上小程序的开发工具跑通是完全够的。如果你要把项目部署到云服务器上演示有几个细节要注意。Spring Boot的application.yml里数据库连接、微信小程序的appid、secret都建议用外部配置方式也就是使用application-prod.yml之类的多个profile文件避免源码泄露时连同密钥一起泄露。同时把文件上传路径如果涉及话剧海报图片上传配置成服务器绝对路径而不是项目相对路径因为打成jar包后相对路径会变化。服务器上运行jar包用nohup java -jar xxx.jar app.log 21 即可后台运行。如果有域名并且配置了HTTPS证书小程序就不用勾选“不校验合法域名”了直接通过https请求访问。6.2 演示时怎么讲能加分演示环节决定了印象分排对优先级第一优先演示完整购票流程。打开小程序 - 浏览话剧 - 点进详情 - 选场次 - 选座 - 提交订单 - 模拟支付 - 订单状态变更。这条链路走完最基本的功能闭环就立住了。第二优先展示异常流程。比如“选座后不支付等15分钟自动释放”“一个座位被一个账号锁了另一个账号点这个座位提示已被抢”导视老师现场就能直观理解到系统的严谨性。第三优先展示管理端数据统计。打开管理页面切到图表页展示今日订单量、热门话剧排行配合讲两句“这些指标可以根据运营需求动态调整”说明你做的是实用系统不是交差作业。6.3 万字文档的写作逻辑文档是课设和毕设的大头很多同学不知道怎么写篇幅。核心把握一条原则文档不是给源码加注释而是完全按照一个“项目交付说明手册”来写。文档结构推荐如下需求分析2-3页背景、用户角色分析、功能需求列表、非功能需求性能、安全。 可行性分析与技术选型1-2页经济、技术、操作可行性对比Spring Boot和SSH、对比小程序和H5。 系统设计4-6页架构图、功能模块图、数据库ER图、核心表结构说明。 系统实现8-12页每个核心模块的实现思路关键代码块展示页面截图。 系统测试2-3页功能测试用例表格化列测试项、预期结果、实际结果。 总结与展望1页存在的不足如“未来可以扩展对接真实微信支付”、“引入Redis缓存热门场次座位数据”。把上面这些内容填充好万字并不是难题。尤其数据库设计部分多写几张表结构注释和字段含义说明几百字就有了。6.4 我需要再唠叨几句的补充一是如果你想给项目加一点亮点可以加一个简单的轮播图管理管理端上传图片小程序首页展示或喜剧类目、演出提醒、收藏功能。也不要为了多而多盲目堆功能反而会因为代码质量参差导致整体分被拉低。建议在“完整的基础功能”和“一个有亮点的扩展功能”之间保持平衡。二是要保证代码质量规范命名。类名用驼峰常量用UPPER_SNAKESQL关键字大写。这些细节答辩时导师一眼就能看到体现出你的编程习惯。三是我个人最深的一个体会这种综合项目最大的价值其实不是某个高深的算法而是让你完整地建立“产品视角”。这头是用户那头是运营中间是订单流转再往下挖一层是并发控制、数据一致性、状态机。把这一整套链路理顺了以后工作里接任何系统心里都不会慌。好这篇就聊到这儿。这个选题我是看着一届一届从最简单版本的票务系统进化到这种全栈闭环形态的难度和含金量都挺平衡。拿到源码后别急着删删改改把数据表建好把代码跑通把流程图和时序图画出来你很快就会觉得这个系统它不只是代码更像是一条完整的业务线在你手里活过来了。