做毕业设计选题目这件事我带过不少学生最深的感受是选题其实比写代码更让人头大。它不需要你去追求什么大而全的创新真正需要的是“确定性”——你确定这个题目你能做完你确定答辩时有东西可讲你确定写进简历里不会心虚。Spring Boot智慧景区门票销售统计系统就是一个踩中了所有这些确定性的典型题目。它的本质是把一套基于Spring Boot的Web后端和数据库系统落地到景区门票销售场景里完成从门票管理、游客购票、订单记录再到销售数据统计分析的一整条数字化管理闭环。这个系统解决的是景区运营里一个非常实际的问题门票卖了多少、卖了多少钱、什么时间卖得多、哪类票受欢迎。以前靠的是Excel和人工台账数据滞后、对账费劲、做决策全凭感觉。系统上线之后所有销售数据实时入库按天看、按周看、按月看都是几个接口的事还能通过图表直观地看到客流高峰时段和热门票型。可以说这正是“智慧文旅”从概念落到地面时最小也最完整的业务单元。如果你正在为毕业设计选题发愁或者已经选了类似方向但心里没底这篇文章可以作为一份完整的参考路线。我会从题目价值、技术选型、数据库设计、核心代码实现、常见问题排查这几个维度一点一点拆开讲。项目里用到的思路和代码其实也可以直接移植到其他管理类系统里。1. 这个题目到底值不值得做选题逻辑与系统定位1.1 为什么“智慧景区门票销售统计”适合做毕设先聊选题。很多学生以为毕设题目越偏门越显档次或者觉得要跟上什么人工智能、区块链才算前沿。但事实上对绝大多数本科阶段的毕业设计来说能完整地跑通一个“用户能操作、数据能流转、结果能展示”的系统比只写一堆理论却落不了地的“伪创新”要重要得多。智慧景区门票销售统计系统这个方向赢在三点。第一业务场景真实且熟悉。你去过景区吧门票类型、价格、购票渠道、旺季限流、淡季调价这些你多少都有感知。理解需求不需要实地调研答辩时老师问起业务场景你讲“门票分成人票儿童票、旺季淡季不同价、线上订票现场核销”逻辑都说得通不会出现“这个系统到底给谁用”的灵魂拷问。第二功能边界可控一个人做得完。系统核心就是基础数据管理、门票销售、订单管理、统计报表外加后台登录权限。没有复杂的购物车、支付回调、多角色工作流工作量集中在两三条业务主线上非常适合一个学期从零开始做完。第三统计数据是天然的展示亮点。一张订单表建好之后按时间维度、票种维度、金额维度能衍生出非常多统计页面和图表接口。这一方面让系统看起来“功能很多”另一方面也是答辩时最直观的效果展示。相比写一堆无脑的增删改查页面一个带趋势图、占比饼图、数据报表的统计模块视觉和逻辑上都更能打动人。1.2 技术栈选型背后的现实考量技术栈这部分我推荐一套“稳妥但又不缺亮点”的组合后端Spring Boot 2.7.x MyBatis-Plus MySQL 8.0前端Vue 3 Element Plus ECharts缓存有条件的话加一个Redis。这套组合可以说是毕业设计场景下的标准答案原因也很朴素。Spring Boot是首选不是因为它是当前最新的框架而在于生态成熟度和“约定大于配置”的开发体验。你用它写一个Web接口只需要加几个注解、配置一个数据源就能把项目跑起来。网上关于Spring Boot的教程、问答、源码解析多到难以计数你遇到的基本问题早在多年前就有人踩过并给出了解决方案。对毕设来说这种确定性就是最大的效率。MyBatis-Plus是在MyBatis的基础上把单表的CRUD操作简化到了极致。你不需要为每个实体类写一套增删改查XML继承一个BaseMapper接口就能获得几乎所有单表操作能力。这样你就能把时间花在统计SQL、业务逻辑这些真正能体现思考深度的代码上。这里特别提醒一下版本问题。Spring Boot版本选2.7.x而不是3.x是一个实践下来的建议。Spring Boot 3对JDK版本有硬性要求必须JDK 17以上而很多学校机房和指导老师默认环境还是JDK 8。如果你的机器上只有JDK 8强行用Spring Boot 3会在环境准备阶段就卡很久。用2.7.x配JDK 8环境搭起来几乎零障碍等以后工作了再切高版本也来得及。前端选Vue 3 Element Plus原因更简单Element Plus的表格、表单、日期选择器、弹窗组件都是后台管理系统现成的东西页面写起来就像搭积木。ECharts是纯前端图表库把后端返回的统计JSON数据往option里一塞折线图、柱状图、饼图就能渲染出来。整套练下来前后端联调的经验有了简历上的项目描述也会充实很多。注意不要为了“显得高级”在毕设里硬上微服务、消息队列这类技术。一个景区门票销售系统单机完全能扛住引入这些只会增加部署复杂度和答辩时被追问的风险。学有余力的话把Redis用起来做缓存和库存控制已经足够作为亮点来讲了。2. 系统架构与数据库设计2.1 功能模块如何拆解一个可运行的景区门票销售统计系统按后端模块来划分建议拆成五块。第一块是系统管理模块管理员登录、修改密码、用户管理。这里涉及JWT做登录凭证或者简单的拦截器做登录校验是每个Web系统的地基。毕设里用JWT做登录凭证前后端分离时非常方便后端签发一个token前端每次请求带上后端拦截器校验通过才放行。第二块是景区与门票管理模块维护景区基本信息和门票类型。门票类型要设计的字段包括票种名称成人票、儿童票、学生票、团体票、票种编码、价格、库存量、是否启用、备注。景区信息则是门票归属的上层维度方便将来做多景区扩展。第三块是售票管理模块这是业务核心。前端选择门票类型、填写游客信息、提交订单后端校验库存、计算金额、生成订单号、扣减库存、保存订单。这里要把“减库存”和“生成订单”放在同一个事务里保证数据一致性。第四块是订单管理模块订单列表查询、订单详情、退票处理。退票逻辑要扣回库存并且记录退票原因和时间。订单查询要支持按订单号、手机号、时间范围筛选这对后面做统计也有帮助。第五块是统计分析模块这是整个系统的“智慧”所在。包括日销售额统计、月度销售趋势、门票类型销售占比、客流量时段分析。每个统计项对应一组SQL聚合查询和一张图表展示是整个系统最出彩的部分。这样拆下来每个模块的工作量比较均衡既不是一堆无脑增删改查也不会难到自己完不成。2.2 核心表结构设计数据库是这套系统的地基我直接按实际开发时的表结构来讲。核心表一共设计6张左右挑重点的介绍。ticket_type 门票类型表id 主键ticket_name 票种名称ticket_code 票种编码price 价格Decimal(10,2)stock 库存量status 状态1启用 0停用create_time 创建时间update_time 更新时间remark 备注sale_order 销售订单表id 主键order_no 订单号唯一索引ticket_id 关联门票类型ticket_name 冗余字段下单时的票名快照price 冗余字段下单时的价格快照quantity 购买数量total_price 总金额visitor_name 游客姓名visitor_phone 游客手机号status 订单状态0已支付 1已退票 2已过期sale_time 销售时间create_time 创建时间这里特意加了 ticket_name 和 price 的冗余字段值得说明原因。如果只存了 ticket_id将来门票价格调整了历史订单的金额就追溯不到了。冗余字段保存的是下单那一刻的快照统计和历史查询才准确。这也是实际业务系统里很常见的做法。sys_user 管理员表id, username, password加密存储, nickname, role, create_timescenic_spot 景区信息表id, spot_name, spot_code, address, description, create_time另外两张表refund_record 退票记录表、operate_log 操作日志表。退票记录表记录退票时间、退票原因、经办人操作日志表记录管理员的关键操作答辩时可以讲“系统有安全审计能力”。索引方面sale_order 表的 sale_time、ticket_id、order_no 一定要建索引。统计SQL基本都是按时间范围和票种来过滤和分组没有索引数据量一上来查询会明显变慢。这是一个很值得在答辩时主动讲出来的细节。提示字段类型上金额一律用 Decimal不要用 Float/Double会有精度问题。时间字段建议用 datetime 并统一设置为服务器时区避免统计时出现小时级偏差。3. 核心业务逻辑与关键代码实现3.1 售票流程与库存并发控制售票是整个系统的核心流程拆成几个步骤说。用户在前端选好门票类型和数量提交订单后后端接口主要做四件事第一根据 ticket_id 查出当前门票类型判断状态是否启用第二判断库存是否足够第三计算订单金额生成唯一订单号保存订单第四扣减库存。其中最容易出问题的就是第四步。如果直接这样写TicketType ticket ticketTypeMapper.selectById(ticketId); if (ticket.getStock() quantity) { throw new BusinessException(库存不足); } ticket.setStock(ticket.getStock() - quantity); ticketTypeMapper.updateById(ticket);在高并发情况下两个请求同时读到库存为10都判断够卖然后都执行扣减最后库存可能只减了一次但订单已经生成了两张。这就是典型的超卖。解决方法在毕设这个量级下最推荐“乐观锁”思想扣减库存的SQL直接带上库存条件。UPDATE ticket_type SET stock stock - #{quantity} WHERE id #{ticketId} AND stock #{quantity}这条SQL的返回值是受影响的行数。如果返回0说明库存不够更新失败那么这次下单就回滚并提示用户库存不足。这种方式不需要引入分布式锁单库场景下完全够用代码量少关键逻辑讲起来也清清楚楚。同时下单和扣减库存必须在同一个事务里。用Spring的 Transactional 标注服务方法一旦出现异常订单和库存都会回滚避免“钱扣了票没减”或者“票减了订单没生成”的状态。订单号生成也有讲究。不能用数据库自增主键直接当订单号展示出去会暴露业务量。最简单的做法是用时间戳加随机数String orderNo OD System.currentTimeMillis() RandomUtil.randomNumbers(4);如果对订单号全局唯一性要求更高可以接入雪花算法MyBatis-Plus自带的IdWorker就直接支持也是一个答辩加分点。3.2 统计报表的核心SQL统计模块是整个系统的灵魂。我从最常见的几个统计需求讲起。日销售额统计按天统计某段时间内每天的订单数量、销售总金额SELECT DATE(sale_time) AS sale_date, COUNT(*) AS order_count, SUM(total_price) AS total_amount, SUM(quantity) AS ticket_count FROM sale_order WHERE status 0 AND sale_time #{startDate} AND sale_time DATE_ADD(#{endDate}, INTERVAL 1 DAY) GROUP BY DATE(sale_time) ORDER BY sale_date;这里有个细节日期范围要用“大于等于开始日期并且小于结束日期加一天”这种写法而不是 sale_time BETWEEN #{startDate} AND #{endDate}。因为 datetime 类型带时分秒直接用BETWEEN会漏掉结束日期当天的数据。这个坑我见不少人踩过。月度趋势统计按自然月统计销售额用于前端画折线图SELECT DATE_FORMAT(sale_time, %Y-%m) AS sale_month, SUM(total_price) AS total_amount, COUNT(*) AS order_count FROM sale_order WHERE status 0 AND sale_time #{startDate} AND sale_time #{endDate} GROUP BY DATE_FORMAT(sale_time, %Y-%m) ORDER BY sale_month;门票类型销售占比统计不同类型的销售数量和金额占比用于前端画饼图。这种查询用到JOIN正好展示对SQL关联查询的掌握SELECT t.ticket_name, SUM(o.quantity) AS sale_quantity, SUM(o.total_price) AS sale_amount FROM sale_order o LEFT JOIN ticket_type t ON o.ticket_id t.ticket_id WHERE o.status 0 AND o.sale_time #{startDate} AND o.sale_time #{endDate} GROUP BY t.ticket_name, t.ticket_id;客流量时段分析这个需求能让系统更有“智慧”的味道。统计一天内每个小时的订单量帮助景区判断高峰时段辅助人员排班SELECT HOUR(sale_time) AS hour_slot, COUNT(*) AS order_count, SUM(quantity) AS visitor_count FROM sale_order WHERE status 0 AND sale_time #{startDate} AND sale_time DATE_ADD(#{endDate}, INTERVAL 1 DAY) GROUP BY HOUR(sale_time) ORDER BY hour_slot;这几条SQL基本覆盖了“智慧景区”里销售统计的核心场景。拿到结果后封装成DTO返回给前端前端用ECharts画折线图、柱状图、饼图展示整个统计模块就立起来了。关于统计性能给一个实操建议如果订单表数据量增长很快统计SQL一定要走索引。前面说的 sale_time、status 字段建复合索引非常关键。另外如果统计范围特别大可以在Mapper里用动态SQL拼接时间范围避免每次都全表扫描。3.3 前端数据可视化的对接思路后端把统计接口写好之后前端的对接其实就是三件事调接口拿数据、把数据格式转换成ECharts需要的结构、渲染图表。以月销售趋势折线图为例后端返回的数据格式设计成这样的列表[ {saleMonth: 2025-01, totalAmount: 126800.00, orderCount: 320}, {saleMonth: 2025-02, totalAmount: 98600.00, orderCount: 288}, {saleMonth: 2025-03, totalAmount: 153200.00, orderCount: 402} ]前端拿到之后先用数组的map方法把月份和金额分别提取成两个数组然后塞到ECharts的option里const months res.data.map(item item.saleMonth); const amounts res.data.map(item item.totalAmount); option { tooltip: { trigger: axis }, xAxis: { type: category, data: months }, yAxis: { type: value, name: 销售额元 }, series: [{ name: 销售额, type: line, data: amounts, smooth: true, areaStyle: {} }] };饼图对应门票类型占比接口数据格式是 [{ name: 成人票, value: 128000 }, ...]ECharts的饼图series直接就能吃。这里有一个小坑如果你用Element Plus的日期选择器传给后端的日期格式是“YYYY-MM-DD”而后端用 LocalDateTime 去接会有转换问题。建议后端接收字符串后再手动解析成日期范围或者用 DateTimeFormat 指定格式再传给SQL。这个细节处理好了前后端联调能少很多不必要的返工。前端页面的布局建议用Element Plus的栅格布局把统计卡片总销售额、订单总数、总游客量放在上方折线图和柱状图并排放在中间饼图独立占一行。一眼望过去信息层级清晰答辩演示的时候视觉效果会好很多。4. 开发过程遇到的问题与排查实录4.1 常见问题速查表系统开发过程中我把最常遇到的几个问题整理成了表格供排查时快速对照。问题现象可能原因解决方案统计结果比预期少一天时间范围用了BETWEEN漏掉了结束当天改用 sale_time start AND sale_time end1天库存出现负数或超卖查询后扣减无并发控制用 UPDATE ... WHERE stock #{quantity} 原子扣减金额精度丢失字段用了Float/Double数据库和Java都用BigDecimal/Decimal接口报406/415前后端日期格式不一致前端传字符串后端手动解析或指定格式启动时DataSource配置报错MySQL版本或驱动不匹配Spring Boot 2.7.x 用 mysql-connector-java 8.x图表数据为空统计SQL没有匹配到status0的数据检查订单状态字段值确认数据初始化脚本是否执行MyBatis-Plus分页不生效没配置分页插件添加 MybatisPlusInterceptor 并注入 PaginationInnerInterceptor返回给前端的密码字段泄露直接返回实体类在实体类上使用 JsonIgnore 或返回自定义VO4.2 踩坑背后的原理复盘表格是结果我再说两个具体的排查过程因为看懂原理比记住答案重要得多。第一个是日期统计漏数据的坑。我第一次写日统计SQL的时候用的是 sale_time BETWEEN 2025-03-01 AND 2025-03-31结果发现3月31日当天的数据完全没统计进去。原因很简单sale_time 是 datetime 类型存储的值类似于“2025-03-31 14:23:00”而 BETWEEN 的下边界是“2025-03-31 00:00:00”那么这条记录就不满足条件。排查时我先用 SELECT MAX(sale_time) FROM sale_order 看了下数据分布确认时间确实存进去了再逐段拆SQL最后定位到是边界条件的问题。改成 sale_time 2025-03-01 AND sale_time 2025-04-01 之后数据就完全正确了。这个经验后来在写所有报表类SQL时都非常有用。第二个是并发扣库存的问题。最开始代码就是“先查库存再判断再更新”本地测试单线程怎么点都没问题。后来写了一个小脚本用多线程同时提交200个买票请求发现订单生成了200条但库存只扣了不到100。排查过程是这样的先在Controller入口打印请求开始时间确认确实是并发同时到达然后在更新库存那行打印更新前后的stock值发现在并发下多个事务读到了相同的旧值。定位到问题后改成带条件的UPDATE语句依赖数据库行锁保证原子性再跑200个并发请求库存和订单就对上了。这也是我前面强烈建议用原子SQL扣库存的原因。4.3 给毕设开发的两个额外建议一是准备好模拟数据。统计模块的图表展示空数据是看不出效果的。建议写一个测试数据生成工具类用循环加随机数生成过去半年甚至一年的订单数据每天几十条到几百条不等再模拟一些节假日高峰。这样前端图表一渲染出来趋势、峰值、占比都非常直观答辩时展示效果完全不一样。二是把README和数据库初始化脚本写规范。毕业设计的源码交付时老师大概率会先看README。把项目结构、技术栈、启动步骤、默认账号、模拟数据生成方式都写清楚不仅方便老师复现也体现了工程素养。注意默认管理员密码一定不要明文存储在数据库里用BCrypt加密。这个细节写到论文和答辩PPT里是很能体现安全意识的一点。我个人在写这类系统的过程中感受最深的一点是一个毕业设计项目真正值钱的不是你用了多少框架、写了多少行代码而是你能不能在答辩现场把“为什么这么设计”讲清楚。景区门票销售统计系统听上去只是一个普通的CRUD项目但当你把数据冗余、乐观锁防超卖、日期边界、统计索引这些细节都做对之后它就变成了一个有思想、能落地的完整系统。最后再分享一个小技巧答辩前把每个核心接口用Postman完整走一遍流程截图保存。这样无论是写论文还是做PPT都有真实的数据和截图可以用比任何口头描述都有说服力。
做毕业设计选题目这件事我带过不少学生最深的感受是选题其实比写代码更让人头大。它不需要你去追求什么大而全的创新真正需要的是“确定性”——你确定这个题目你能做完你确定答辩时有东西可讲你确定写进简历里不会心虚。Spring Boot智慧景区门票销售统计系统就是一个踩中了所有这些确定性的典型题目。它的本质是把一套基于Spring Boot的Web后端和数据库系统落地到景区门票销售场景里完成从门票管理、游客购票、订单记录再到销售数据统计分析的一整条数字化管理闭环。这个系统解决的是景区运营里一个非常实际的问题门票卖了多少、卖了多少钱、什么时间卖得多、哪类票受欢迎。以前靠的是Excel和人工台账数据滞后、对账费劲、做决策全凭感觉。系统上线之后所有销售数据实时入库按天看、按周看、按月看都是几个接口的事还能通过图表直观地看到客流高峰时段和热门票型。可以说这正是“智慧文旅”从概念落到地面时最小也最完整的业务单元。如果你正在为毕业设计选题发愁或者已经选了类似方向但心里没底这篇文章可以作为一份完整的参考路线。我会从题目价值、技术选型、数据库设计、核心代码实现、常见问题排查这几个维度一点一点拆开讲。项目里用到的思路和代码其实也可以直接移植到其他管理类系统里。1. 这个题目到底值不值得做选题逻辑与系统定位1.1 为什么“智慧景区门票销售统计”适合做毕设先聊选题。很多学生以为毕设题目越偏门越显档次或者觉得要跟上什么人工智能、区块链才算前沿。但事实上对绝大多数本科阶段的毕业设计来说能完整地跑通一个“用户能操作、数据能流转、结果能展示”的系统比只写一堆理论却落不了地的“伪创新”要重要得多。智慧景区门票销售统计系统这个方向赢在三点。第一业务场景真实且熟悉。你去过景区吧门票类型、价格、购票渠道、旺季限流、淡季调价这些你多少都有感知。理解需求不需要实地调研答辩时老师问起业务场景你讲“门票分成人票儿童票、旺季淡季不同价、线上订票现场核销”逻辑都说得通不会出现“这个系统到底给谁用”的灵魂拷问。第二功能边界可控一个人做得完。系统核心就是基础数据管理、门票销售、订单管理、统计报表外加后台登录权限。没有复杂的购物车、支付回调、多角色工作流工作量集中在两三条业务主线上非常适合一个学期从零开始做完。第三统计数据是天然的展示亮点。一张订单表建好之后按时间维度、票种维度、金额维度能衍生出非常多统计页面和图表接口。这一方面让系统看起来“功能很多”另一方面也是答辩时最直观的效果展示。相比写一堆无脑的增删改查页面一个带趋势图、占比饼图、数据报表的统计模块视觉和逻辑上都更能打动人。1.2 技术栈选型背后的现实考量技术栈这部分我推荐一套“稳妥但又不缺亮点”的组合后端Spring Boot 2.7.x MyBatis-Plus MySQL 8.0前端Vue 3 Element Plus ECharts缓存有条件的话加一个Redis。这套组合可以说是毕业设计场景下的标准答案原因也很朴素。Spring Boot是首选不是因为它是当前最新的框架而在于生态成熟度和“约定大于配置”的开发体验。你用它写一个Web接口只需要加几个注解、配置一个数据源就能把项目跑起来。网上关于Spring Boot的教程、问答、源码解析多到难以计数你遇到的基本问题早在多年前就有人踩过并给出了解决方案。对毕设来说这种确定性就是最大的效率。MyBatis-Plus是在MyBatis的基础上把单表的CRUD操作简化到了极致。你不需要为每个实体类写一套增删改查XML继承一个BaseMapper接口就能获得几乎所有单表操作能力。这样你就能把时间花在统计SQL、业务逻辑这些真正能体现思考深度的代码上。这里特别提醒一下版本问题。Spring Boot版本选2.7.x而不是3.x是一个实践下来的建议。Spring Boot 3对JDK版本有硬性要求必须JDK 17以上而很多学校机房和指导老师默认环境还是JDK 8。如果你的机器上只有JDK 8强行用Spring Boot 3会在环境准备阶段就卡很久。用2.7.x配JDK 8环境搭起来几乎零障碍等以后工作了再切高版本也来得及。前端选Vue 3 Element Plus原因更简单Element Plus的表格、表单、日期选择器、弹窗组件都是后台管理系统现成的东西页面写起来就像搭积木。ECharts是纯前端图表库把后端返回的统计JSON数据往option里一塞折线图、柱状图、饼图就能渲染出来。整套练下来前后端联调的经验有了简历上的项目描述也会充实很多。注意不要为了“显得高级”在毕设里硬上微服务、消息队列这类技术。一个景区门票销售系统单机完全能扛住引入这些只会增加部署复杂度和答辩时被追问的风险。学有余力的话把Redis用起来做缓存和库存控制已经足够作为亮点来讲了。2. 系统架构与数据库设计2.1 功能模块如何拆解一个可运行的景区门票销售统计系统按后端模块来划分建议拆成五块。第一块是系统管理模块管理员登录、修改密码、用户管理。这里涉及JWT做登录凭证或者简单的拦截器做登录校验是每个Web系统的地基。毕设里用JWT做登录凭证前后端分离时非常方便后端签发一个token前端每次请求带上后端拦截器校验通过才放行。第二块是景区与门票管理模块维护景区基本信息和门票类型。门票类型要设计的字段包括票种名称成人票、儿童票、学生票、团体票、票种编码、价格、库存量、是否启用、备注。景区信息则是门票归属的上层维度方便将来做多景区扩展。第三块是售票管理模块这是业务核心。前端选择门票类型、填写游客信息、提交订单后端校验库存、计算金额、生成订单号、扣减库存、保存订单。这里要把“减库存”和“生成订单”放在同一个事务里保证数据一致性。第四块是订单管理模块订单列表查询、订单详情、退票处理。退票逻辑要扣回库存并且记录退票原因和时间。订单查询要支持按订单号、手机号、时间范围筛选这对后面做统计也有帮助。第五块是统计分析模块这是整个系统的“智慧”所在。包括日销售额统计、月度销售趋势、门票类型销售占比、客流量时段分析。每个统计项对应一组SQL聚合查询和一张图表展示是整个系统最出彩的部分。这样拆下来每个模块的工作量比较均衡既不是一堆无脑增删改查也不会难到自己完不成。2.2 核心表结构设计数据库是这套系统的地基我直接按实际开发时的表结构来讲。核心表一共设计6张左右挑重点的介绍。ticket_type 门票类型表id 主键ticket_name 票种名称ticket_code 票种编码price 价格Decimal(10,2)stock 库存量status 状态1启用 0停用create_time 创建时间update_time 更新时间remark 备注sale_order 销售订单表id 主键order_no 订单号唯一索引ticket_id 关联门票类型ticket_name 冗余字段下单时的票名快照price 冗余字段下单时的价格快照quantity 购买数量total_price 总金额visitor_name 游客姓名visitor_phone 游客手机号status 订单状态0已支付 1已退票 2已过期sale_time 销售时间create_time 创建时间这里特意加了 ticket_name 和 price 的冗余字段值得说明原因。如果只存了 ticket_id将来门票价格调整了历史订单的金额就追溯不到了。冗余字段保存的是下单那一刻的快照统计和历史查询才准确。这也是实际业务系统里很常见的做法。sys_user 管理员表id, username, password加密存储, nickname, role, create_timescenic_spot 景区信息表id, spot_name, spot_code, address, description, create_time另外两张表refund_record 退票记录表、operate_log 操作日志表。退票记录表记录退票时间、退票原因、经办人操作日志表记录管理员的关键操作答辩时可以讲“系统有安全审计能力”。索引方面sale_order 表的 sale_time、ticket_id、order_no 一定要建索引。统计SQL基本都是按时间范围和票种来过滤和分组没有索引数据量一上来查询会明显变慢。这是一个很值得在答辩时主动讲出来的细节。提示字段类型上金额一律用 Decimal不要用 Float/Double会有精度问题。时间字段建议用 datetime 并统一设置为服务器时区避免统计时出现小时级偏差。3. 核心业务逻辑与关键代码实现3.1 售票流程与库存并发控制售票是整个系统的核心流程拆成几个步骤说。用户在前端选好门票类型和数量提交订单后后端接口主要做四件事第一根据 ticket_id 查出当前门票类型判断状态是否启用第二判断库存是否足够第三计算订单金额生成唯一订单号保存订单第四扣减库存。其中最容易出问题的就是第四步。如果直接这样写TicketType ticket ticketTypeMapper.selectById(ticketId); if (ticket.getStock() quantity) { throw new BusinessException(库存不足); } ticket.setStock(ticket.getStock() - quantity); ticketTypeMapper.updateById(ticket);在高并发情况下两个请求同时读到库存为10都判断够卖然后都执行扣减最后库存可能只减了一次但订单已经生成了两张。这就是典型的超卖。解决方法在毕设这个量级下最推荐“乐观锁”思想扣减库存的SQL直接带上库存条件。UPDATE ticket_type SET stock stock - #{quantity} WHERE id #{ticketId} AND stock #{quantity}这条SQL的返回值是受影响的行数。如果返回0说明库存不够更新失败那么这次下单就回滚并提示用户库存不足。这种方式不需要引入分布式锁单库场景下完全够用代码量少关键逻辑讲起来也清清楚楚。同时下单和扣减库存必须在同一个事务里。用Spring的 Transactional 标注服务方法一旦出现异常订单和库存都会回滚避免“钱扣了票没减”或者“票减了订单没生成”的状态。订单号生成也有讲究。不能用数据库自增主键直接当订单号展示出去会暴露业务量。最简单的做法是用时间戳加随机数String orderNo OD System.currentTimeMillis() RandomUtil.randomNumbers(4);如果对订单号全局唯一性要求更高可以接入雪花算法MyBatis-Plus自带的IdWorker就直接支持也是一个答辩加分点。3.2 统计报表的核心SQL统计模块是整个系统的灵魂。我从最常见的几个统计需求讲起。日销售额统计按天统计某段时间内每天的订单数量、销售总金额SELECT DATE(sale_time) AS sale_date, COUNT(*) AS order_count, SUM(total_price) AS total_amount, SUM(quantity) AS ticket_count FROM sale_order WHERE status 0 AND sale_time #{startDate} AND sale_time DATE_ADD(#{endDate}, INTERVAL 1 DAY) GROUP BY DATE(sale_time) ORDER BY sale_date;这里有个细节日期范围要用“大于等于开始日期并且小于结束日期加一天”这种写法而不是 sale_time BETWEEN #{startDate} AND #{endDate}。因为 datetime 类型带时分秒直接用BETWEEN会漏掉结束日期当天的数据。这个坑我见不少人踩过。月度趋势统计按自然月统计销售额用于前端画折线图SELECT DATE_FORMAT(sale_time, %Y-%m) AS sale_month, SUM(total_price) AS total_amount, COUNT(*) AS order_count FROM sale_order WHERE status 0 AND sale_time #{startDate} AND sale_time #{endDate} GROUP BY DATE_FORMAT(sale_time, %Y-%m) ORDER BY sale_month;门票类型销售占比统计不同类型的销售数量和金额占比用于前端画饼图。这种查询用到JOIN正好展示对SQL关联查询的掌握SELECT t.ticket_name, SUM(o.quantity) AS sale_quantity, SUM(o.total_price) AS sale_amount FROM sale_order o LEFT JOIN ticket_type t ON o.ticket_id t.ticket_id WHERE o.status 0 AND o.sale_time #{startDate} AND o.sale_time #{endDate} GROUP BY t.ticket_name, t.ticket_id;客流量时段分析这个需求能让系统更有“智慧”的味道。统计一天内每个小时的订单量帮助景区判断高峰时段辅助人员排班SELECT HOUR(sale_time) AS hour_slot, COUNT(*) AS order_count, SUM(quantity) AS visitor_count FROM sale_order WHERE status 0 AND sale_time #{startDate} AND sale_time DATE_ADD(#{endDate}, INTERVAL 1 DAY) GROUP BY HOUR(sale_time) ORDER BY hour_slot;这几条SQL基本覆盖了“智慧景区”里销售统计的核心场景。拿到结果后封装成DTO返回给前端前端用ECharts画折线图、柱状图、饼图展示整个统计模块就立起来了。关于统计性能给一个实操建议如果订单表数据量增长很快统计SQL一定要走索引。前面说的 sale_time、status 字段建复合索引非常关键。另外如果统计范围特别大可以在Mapper里用动态SQL拼接时间范围避免每次都全表扫描。3.3 前端数据可视化的对接思路后端把统计接口写好之后前端的对接其实就是三件事调接口拿数据、把数据格式转换成ECharts需要的结构、渲染图表。以月销售趋势折线图为例后端返回的数据格式设计成这样的列表[ {saleMonth: 2025-01, totalAmount: 126800.00, orderCount: 320}, {saleMonth: 2025-02, totalAmount: 98600.00, orderCount: 288}, {saleMonth: 2025-03, totalAmount: 153200.00, orderCount: 402} ]前端拿到之后先用数组的map方法把月份和金额分别提取成两个数组然后塞到ECharts的option里const months res.data.map(item item.saleMonth); const amounts res.data.map(item item.totalAmount); option { tooltip: { trigger: axis }, xAxis: { type: category, data: months }, yAxis: { type: value, name: 销售额元 }, series: [{ name: 销售额, type: line, data: amounts, smooth: true, areaStyle: {} }] };饼图对应门票类型占比接口数据格式是 [{ name: 成人票, value: 128000 }, ...]ECharts的饼图series直接就能吃。这里有一个小坑如果你用Element Plus的日期选择器传给后端的日期格式是“YYYY-MM-DD”而后端用 LocalDateTime 去接会有转换问题。建议后端接收字符串后再手动解析成日期范围或者用 DateTimeFormat 指定格式再传给SQL。这个细节处理好了前后端联调能少很多不必要的返工。前端页面的布局建议用Element Plus的栅格布局把统计卡片总销售额、订单总数、总游客量放在上方折线图和柱状图并排放在中间饼图独立占一行。一眼望过去信息层级清晰答辩演示的时候视觉效果会好很多。4. 开发过程遇到的问题与排查实录4.1 常见问题速查表系统开发过程中我把最常遇到的几个问题整理成了表格供排查时快速对照。问题现象可能原因解决方案统计结果比预期少一天时间范围用了BETWEEN漏掉了结束当天改用 sale_time start AND sale_time end1天库存出现负数或超卖查询后扣减无并发控制用 UPDATE ... WHERE stock #{quantity} 原子扣减金额精度丢失字段用了Float/Double数据库和Java都用BigDecimal/Decimal接口报406/415前后端日期格式不一致前端传字符串后端手动解析或指定格式启动时DataSource配置报错MySQL版本或驱动不匹配Spring Boot 2.7.x 用 mysql-connector-java 8.x图表数据为空统计SQL没有匹配到status0的数据检查订单状态字段值确认数据初始化脚本是否执行MyBatis-Plus分页不生效没配置分页插件添加 MybatisPlusInterceptor 并注入 PaginationInnerInterceptor返回给前端的密码字段泄露直接返回实体类在实体类上使用 JsonIgnore 或返回自定义VO4.2 踩坑背后的原理复盘表格是结果我再说两个具体的排查过程因为看懂原理比记住答案重要得多。第一个是日期统计漏数据的坑。我第一次写日统计SQL的时候用的是 sale_time BETWEEN 2025-03-01 AND 2025-03-31结果发现3月31日当天的数据完全没统计进去。原因很简单sale_time 是 datetime 类型存储的值类似于“2025-03-31 14:23:00”而 BETWEEN 的下边界是“2025-03-31 00:00:00”那么这条记录就不满足条件。排查时我先用 SELECT MAX(sale_time) FROM sale_order 看了下数据分布确认时间确实存进去了再逐段拆SQL最后定位到是边界条件的问题。改成 sale_time 2025-03-01 AND sale_time 2025-04-01 之后数据就完全正确了。这个经验后来在写所有报表类SQL时都非常有用。第二个是并发扣库存的问题。最开始代码就是“先查库存再判断再更新”本地测试单线程怎么点都没问题。后来写了一个小脚本用多线程同时提交200个买票请求发现订单生成了200条但库存只扣了不到100。排查过程是这样的先在Controller入口打印请求开始时间确认确实是并发同时到达然后在更新库存那行打印更新前后的stock值发现在并发下多个事务读到了相同的旧值。定位到问题后改成带条件的UPDATE语句依赖数据库行锁保证原子性再跑200个并发请求库存和订单就对上了。这也是我前面强烈建议用原子SQL扣库存的原因。4.3 给毕设开发的两个额外建议一是准备好模拟数据。统计模块的图表展示空数据是看不出效果的。建议写一个测试数据生成工具类用循环加随机数生成过去半年甚至一年的订单数据每天几十条到几百条不等再模拟一些节假日高峰。这样前端图表一渲染出来趋势、峰值、占比都非常直观答辩时展示效果完全不一样。二是把README和数据库初始化脚本写规范。毕业设计的源码交付时老师大概率会先看README。把项目结构、技术栈、启动步骤、默认账号、模拟数据生成方式都写清楚不仅方便老师复现也体现了工程素养。注意默认管理员密码一定不要明文存储在数据库里用BCrypt加密。这个细节写到论文和答辩PPT里是很能体现安全意识的一点。我个人在写这类系统的过程中感受最深的一点是一个毕业设计项目真正值钱的不是你用了多少框架、写了多少行代码而是你能不能在答辩现场把“为什么这么设计”讲清楚。景区门票销售统计系统听上去只是一个普通的CRUD项目但当你把数据冗余、乐观锁防超卖、日期边界、统计索引这些细节都做对之后它就变成了一个有思想、能落地的完整系统。最后再分享一个小技巧答辩前把每个核心接口用Postman完整走一遍流程截图保存。这样无论是写论文还是做PPT都有真实的数据和截图可以用比任何口头描述都有说服力。
