SpringBoot博物馆预约系统：分时预约与并发控制实战

1. 项目整体思路与功能拆解

1.1 为什么这个题目值得做

SpringBoot博物馆参观预约管理系统，这个题目在计算机毕业设计里属于"看着普通、实则非常能打"的一类。我见过太多同学一上来就选什么"基于深度学习的垃圾分类系统"、"基于人脸识别的考勤系统"，结果做的时候发现数据集搞不定、模型训练跑不动、答辩时被老师一问就卡壳。但博物馆预约系统不一样，它不需要复杂算法，核心是业务流程的完整性和工程质量的可展示性，每一块功能都能讲出明确的价值点，而且天然具备"智慧展馆分时预约系统"这个热点标签，挂在简历上也说得出口。

先看需求端。这几年各地博物馆、美术馆、科技馆都在推行线上预约制，尤其是节假日"预约难、排队久"的问题频发，一个能承载分时预约、票务核销、参观人数动态管控的系统，是展馆真实需要的东西。从毕业设计踩分角度看，它的角色体系完整（游客端、管理员端、系统端），业务流程闭环（注册登录、浏览展馆、分时预约、生成凭证、现场核销、后台统计），技术栈又非常主流（SpringBoot、MySQL、Vue），拿来申请"优秀毕业论文"或者"优秀毕设"都够格，工作量适中，一个人三到四个月完全能搞定。

从个人成长角度看，这套系统的难点不在CRUD本身，而在于几个"比较级"的设计：分时预约的余票计算怎么保证不超卖、多个并发请求同时预约同一时间段的处理策略、角色权限如何细粒度控制、统计报表如何让数据真实可用。把这些点想清楚并实现出来，你对Web开发的整体认知会向前跨一大步，这不是刷两个视频能得到的。

1.2 核心功能模块划分

我在规划这个项目时，第一步不是写代码，而是画功能脑图。博物馆预约系统必须覆盖两端四角色：游客端（普通用户）、展馆运营端（管理员）、核销端（现场工作人员）、系统端（超级管理员）。每个角色的操作边界必须清晰，否则后面做权限控制时会非常痛苦。

游客端功能包括：注册登录（手机号+密码，配合图形验证码防止机器刷号）、浏览博物馆列表（支持按城市、展馆类型筛选）、查看展馆详情（开放时间、场馆介绍、展品亮点、近期特展）、选择参观日期和入馆时间段（分时预约核心）、提交预约申请（填写参观者姓名、身份证号、同行人数）、查看预约记录与电子凭证（二维码）、取消预约（有时间限制，展馆开场前2小时不可取消）、个人中心（修改资料、查看历史记录）。

运营端功能比较复杂，我拆成了四个小模块。展馆管理：维护展馆基础信息，上传封面图、完善场馆故事、设置开放日与闭馆日。场次管理：按日期和时段生成预约场次，设置每个时段的可预约人数上限、余票预警阈值。订单管理：查看全部预约单、按状态筛选（待参观/已完成/已取消/已过期）、手动取消异常订单、导出Excel报表。数据看板：展示今日预约量、本周客流趋势、热门展馆排行、各时段承载率。

核销端则要轻量，给现场工作人员使用的应该是极简界面。输入预约单号或扫二维码，核验通过后标记为"已入场"，如果预约人信息与身份证不一致，可以直接拒绝并记录原因。系统端只管一件事：管理员账号管理和权限分配，以及看全平台汇总数据。

这里有一个设计细节想提醒你：不要把"核销"功能合并进运营端后台。我当时第一版就是让管理员一个人承担全部操作，结果做演示时很尴尬——活动现场不可能让管理员拿着后台去门口一个个扫码。后来我单独剥了一个核销端，界面干净、操作路径短，演示效果和实际可用性都提升了一大截。

1.3 分时预约模式的设计逻辑

分时预约是博物馆系统的灵魂，也是答辩时最容易展开讲技术点的地方。它的业务逻辑并不复杂：把一天的开放时间切成几个固定时段（比如上午9:00-11:00、11:00-13:00、下午13:00-15:00、15:00-17:00），每个时段限定预约人数上限。用户选择日期后，系统展示每个时段剩余名额，选择有余额的时段提交预约。

但聪明的地方在于底层数据模型。我建议不要把"时段余票"设计成一个普通字段，而是用一张独立的visit_session表来维护场次信息，用booking_record表来记录预约订单。核心原理是：余票数=场次名额上限-当前已确认预约数。这样设计的好处是，新增一个时段、调整某个时段名额、关闭某个场次，都不需要动业务逻辑，只要操作visit_session表即可。

再进一步，为了应对"同一时刻多个用户抢同一时段"的问题，我在生成预约单和扣减余票的地方加了@Transactional事务和行级锁（SELECT ... FOR UPDATE）。这个点必须写进论文里，并且答辩时主动讲，因为它是教科书里"事务隔离性与并发控制"在真实业务里的直接应用，老师很难不给你加分。

展馆侧还需要配合"总量管控"逻辑：一个游客一天只能预约同一展馆一次，避免黄牛占票；同一手机号累计未到场次数超过3次，限制后续预约。这就是"智慧展馆"概念的实体化——系统不是简单记录预约信息，而是能基于规则做动态管控。

2. 技术选型与表结构设计

2.1 为什么是SpringBoot+MySQL这套组合

博物馆预约系统的技术选型，要同时考虑"稳妥"和"时髦"两个维度。SpringBoot是当前Java Web开发的事实标准，没有之一。它把复杂的Spring配置简化成了"自动配置+约定优于配置"，你不用再去写一堆繁琐的XML，一个@SpringBootApplication注解就能启动整个应用。更关键的是，市面上90%以上的中小型项目、绝大部分企业内部系统都是这套技术栈，你做完这个项目再去看其他SpringBoot项目，会觉得套路非常熟悉，这对刚走出校门的求职者来说是巨大的信心优势。

MySQL在数据存储层同样是标配。关系型数据库的ACID特性完全能覆盖预约系统的需求，而且MySQL的InnoDB引擎支持行级锁、外键约束、事务，这些在分时预约的余票扣减中刚好用得上。相比NoSQL（比如MongoDB）或者新型数据库（比如PostgreSQL），MySQL的资料最丰富，中文社区解决方案最全，毕设阶段遇到问题几乎都能搜到现成答案。

前端我用的是Vue 3 + Element Plus，没有选择前后端不分离的传统JSP方案。原因有两个。第一，现在企业里实际项目绝大多数是前后端分离架构，你的毕设如果直接用了前后端分离，答辩时可以理直气壮地说"这套架构具备工程落地价值"。第二，Vue的组件化开发在复用性上更有优势，后台管理系统的表格、表单、弹窗都可以抽成公共组件，写起来并不比写JSP慢。可视化部分接入ECharts，做客流趋势图、展馆热度排行，效果拔群。

2.2 核心表的字段设计详解

数据库设计是整套系统的地基。我的表结构前后改了四版，下面直接把最终的沉淀成果分享出来，每个字段都标注了设计理由。

用户表user：主键id（自增）、phone（唯一索引，登录识别）、password（MD5加盐后的密文）、nickname、real_name（实名认证字段）、id_card（身份证号）、avatar（头像URL）、role（0游客/1运营/2核销员/3超级管理员）、status（0正常/1锁定）、visit_blacklist（是否进入限制预约名单）、create_time、update_time。

展馆表museum：id、name、city、address、introduction（长文本，展馆介绍）、cover_image、open_time（开馆时间）、close_time、closed_days（每周闭馆日，如周一）、max_daily_capacity（每日承载上限）、status（0下架/1上架）。

场次表visit_session：id、museum_id（外键）、session_date（目标日期）、start_time（时段开始）、end_time（时段结束）、quota（该时段名额上限）、booked_count（当前已预约数）、status（0关闭/1开放/2已满）。这里要注意，booked_count是冗余字段，用于快速展示余票，但它的变更必须放在和订单创建相同的事务里，保证一致性。

预约记录表booking_record：id、booking_no（业务编号，如BK20250615001）、user_id、museum_id、session_id、visit_date、visit_time_range、visitor_name、visitor_id_card、ticket_count（同行人数）、status（0待参观/1已完成/2已取消/3已过期/4已核销）、qr_code_url（二维码凭证）、cancel_reason、create_time、cancel_time、checkin_time。

核销记录表checkin_record：id、booking_id、operator_id（核销员用户ID）、checkin_type（0扫码/1输入单号）、checkin_result（0通过/1拒绝）、reject_reason、create_time。

操作日志表operation_log：id、user_id、module（操作模块）、action（具体行为）、params（JSON格式参数快照）、ip、create_time。这个表很加分，答辩时你可以说"系统所有敏感操作均有日志留痕，满足展馆安全审计要求"。

2.3 表关系的建立与索引优化

表之间的关联关系要设计得"恰到好处"，不要过度建外键。我的做法是逻辑外键为主——在实体类中用@ManyToOne、@OneToMany维护关联，但数据库物理层面不强制FOREIGN KEY约束。为什么？因为物理外键在插入、更新时会有额外的锁开销，并且微服务拆表时很麻烦，现在的主流开发习惯都是逻辑外键。这不是偷懒，是工程实践里的常规选择。

索引的规划要站在查询场景的视角反推。高频查询场景无非这几种：用户查自己的预约记录（user_id）、运营端按日期查场次（museum_id + session_date）、核销时按单号查订单（booking_no，注意这里是唯一索引）、统计看板按天聚合（create_time范围查询）。每个场景建立对应索引，索引数量控制在10个以内，既保证加速效果，又不会让写入性能受损。

真实项目里我还给booking_record表做了分表评估，但最终结论是当前数据量（日均几千单）完全不需要分表，单表加索引就够了。这个思考过程放在论文"数据库设计"一节里，能体现出你具备架构意识。

3. 核心功能实现与实操过程

3.1 环境准备与项目初始化

实操第一步，把开发环境准备好。JDK版本建议1.8或11（生产环境最稳的还是1.8，但如果你要展示新特性，11也没问题），Maven 3.6+，IDE用IDEA社区版或旗舰版都行，MySQL 5.7或8.0，Node.js 14+用于前端工程。

项目初始化我习惯用Spring Initializr（IDEA内置）生成SpringBoot项目骨架。依赖选Spring Web、Spring Boot DevTools、Lombok、Spring Data JPA或MyBatis-Plus（个人更推荐MyBatis-Plus，因为它的BaseMapper能省掉大量单表CRUD代码）、MySQL Driver、Validation。生成后立刻调整application.yml，配置端口、数据库连接地址（带characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai参数）、连接池（HikariCP）参数、日志级别。

注意：很多新手在这一步容易卡在数据库连接失败。先排查MySQL服务是否启动，再看用户名密码是否正确，然后在命令行里用mysql -u root -p实测连通。如果MySQL 8.0以上版本，驱动应该在com.mysql.cj.jdbc.Driver而不是老的com.mysql.jdbc.Driver。

前端工程我用Vue CLI创建，项目名museum-admin，模板选Vue 3，安装Element Plus、Axios、Vue Router、Pinia、ECharts。开发环境通过vue.config.js里的devServer.proxy将API请求代理到后端的8080端口，解决跨域问题。这个配置是前后端联调的基础，不会配的话后面每一步都会报跨域错误。

3.2 用户注册登录与验证码实现

注册登录是整个系统的入口，实现质量直接影响演示时的第一印象。我的方案是：图形验证码（用Hutool工具库生成四字符验证码图片） + 手机号密码注册 + 登录签发JWT Token。

图形验证码的防刷逻辑要放在最前面。生成验证码时，把验证码文本存入Redis（或本地Session），设置2分钟有效期，用户提交表单时校验输入与存储值是否一致，不区分大小写。这里有个细节：不管验证码校验成功还是失败，都必须立刻把已存验证码删除，防止同一验证码被暴力尝试。

密码存储必须加密，严禁明文入库。我用的是BCryptPasswordEncoder（Spring Security里的工具类，单独抽出来用即可），它把加盐逻辑内置在哈希结果中，同一个密码两次加密结果不同，安全性远高于MD5。很多教程还在教MD5+盐，那套方案已经过时了，BCrypt是当前业界标准。

JWT的载荷我放了userId和role两个核心字段，过期时间设为24小时。登录成功后返回Token给前端，前端存到localStorage，Axios请求拦截器在请求头加Authorization: Bearer xxx。后端写一个拦截器（HandlerInterceptor），放行登录接口、验证码接口和静态资源，其余接口全部校验Token。校验流程是：解析Token -> 获取用户ID -> 查询用户状态（如果被锁定则拒绝） -> 将用户对象放入ThreadLocal -> 放行。用一个自定义注解@RequireRole标注在需要角色权限的接口上，配合拦截器做二次校验，这就是细粒度权限控制的骨架。

3.3 分时预约核心逻辑实现（含并发处理）

分时预约是整个系统最核心的业务场景，我在这里花的时间最多，也强烈建议你重点投入。先梳理流程：

用户选择日期和时段 -> 系统检查该时段状态（必须是开放且有余票） -> 检查该用户当日是否已有预约（防重复） -> 生成预约单号 -> 锁定场次行记录 -> 扣减booked_count-> 插入booking_record-> 生成二维码凭证 -> 返回前端。

那个"锁定场次行记录"的实现，在MyBatis-Plus里写法如下：

@Transactional public BookingResult createBooking(BookingRequest request) { // 1. 查询场次，带上行级锁 VisitSession session = visitSessionMapper.selectByIdForUpdate(request.getSessionId()); if (session == null || session.getStatus() != 1) { return BookingResult.fail("场次不存在或已关闭"); } // 2. 检查余票 if (session.getBookedCount() >= session.getQuota()) { return BookingResult.fail("该时段已约满"); } // 3. 检查用户当日是否重复预约 Integer count = bookingRecordMapper.countByUserAndDate( request.getUserId(), request.getVisitDate()); if (count > 0) { return BookingResult.fail("您当日已有预约记录，请勿重复预约"); } // 4. 更新场次已约数 session.setBookedCount(session.getBookedCount() + 1); visitSessionMapper.updateById(session); // 5. 生成预约记录 BookingRecord record = buildRecord(request); bookingRecordMapper.insert(record); return BookingResult.ok(record); }

selectByIdForUpdate对应SQL是SELECT * FROM visit_session WHERE id = ? FOR UPDATE，在事务内对这条记录加排他锁。另一个用户同一时刻请求同一个场次时，会被阻塞到第一个事务提交或回滚，从而避免超卖。这里补一句：用悲观锁虽然简单，但会牺牲部分性能，如果是高并发系统应该改为乐观锁（CAS）。不过毕设场景里，悲观锁更容易解释、更容易验证正确性，我建议你掌握悲观锁，然后论文里"未来展望"写一句"可进一步引入Redis原子操作或乐观锁机制提升并发吞吐"，既显深度又不给自己挖坑。

预约成功后的二维码，我直接用Google的Zxing库生成QRCode图片，写入booking_record.qr_code_url字段，内容编码是{"bookingNo":"BK20250615001","userId":"123"}。核销端扫码后解析出bookingNo，再用单号查库。

3.4 核销端与后台管理实现

核销端的设计原则是"三步内完成一次核销"。我做了两个入口：首页大搜索框输入预约单号、扫码枪自动录入。找到订单后，页面展示关键信息（单号、游客姓名、证件号后四位掩码、参观日期时段、预约人数），核销员确认无误后点击"核销入场"。点击时后端做二次校验：订单状态是否为"待参观"、当前时间是否在预约时段开始前30分钟至结束时间范围内。如果全部通过，将状态改为"已核销"，写入checkin_record，记录操作员ID。

后台管理端我按照功能模块拆成独立页面，菜单结构是：工作台（数据看板）、展馆管理、场次管理、预约订单、核销管理、用户管理、系统设置。ECharts画看板数据时，后端对应提供三个统计接口：按日统计预约量趋势（近7/30天）、按展馆统计热度排行、按时段统计承载率。这里有一个容易被忽略的加分点：统计接口尽量做聚合查询（GROUP BY+COUNT），不要循环查数据库拼数据，SQL写得干净，答辩时可以把SQL贴出来讲。

后台的Excel导出功能，我用了EasyExcel而不是老牌的POI，它占用内存更低、API更友好，导出预约订单列表、用户列表、场次列表都是一行代码的事。我建议你把导出功能做到位，因为现场演示时"一键导出"的视觉效果非常好。

4. 前端页面架构与部署上线

4.1 页面设计与交互细节

前端页面的设计直接决定评委的第一印象。我的原则是：不追求惊艳炫酷，但必须干净、清楚、有秩序。游客端首页放轮播大图（博物馆环境照片）、搜索栏（城市+关键词）、展馆卡片列表（封面图、名称、城市、开放状态、今日余票）。展馆详情页是重点，必须展示好三个信息层级：第一层是展馆基础信息和得分数据（今日预约量、剩余场次），第二层是时间选择（日期横向滚动条+时段场次卡片），第三层是预约表单（实名信息填写、同行人数选择）。时段的"余票充足/仅剩X张/已约满"状态要用不同颜色标识，让用户一眼就能判断可操作性。

前端预约流程的交互细节值得打磨。用户选择日期后，立刻用Ajax请求当天场次余票数据，切换日期时加载动画（Skeleton骨架屏）替代粗糙的loading转圈。提交预约时，先做前端校验（身份证号格式、姓名非空、时段必选），再调后端接口。后端返回失败时，错误提示要具体不要含糊，比如"该时段已被约满，请选择其他场次"，这样用户才能理解并继续操作。

后台管理端我用的是典型的左侧菜单+右侧内容区布局。表格分页、搜索筛选、状态标签（不同预约状态用不同颜色的Tag）、弹窗表单、删除确认等组件全部从Element Plus取用，保持统一风格。注意表格的每列宽度、对齐方式、可读性要调好，这些细节加在一起，美观度和使用体验会有质的提升。

4.2 部署上线与关键技术配置

整个系统我推荐用"前后端分离+Nginx反向代理+MySQL独立部署"的架构上线。后端SpringBoot项目打包成可执行JAR，执行java -jar museum-server.jar --spring.profiles.active=prod启动，生产环境配置里把application-prod.yml中的数据库地址换成云数据库（我用的是某云服务器自建MySQL）。前端执行npm run build构建出dist静态目录，用Nginx托管，并配置反向代理转发/api前缀的请求到后端8080端口。

Nginx关键配置片段：

server { listen 80; server_name your-domain.com; root /var/www/museum-frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; # 解决Vue Router的history模式刷新404 } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

那个try_files配置是Vue前端部署的经典坑，不加的话，在非首页刷新页面会报404。另外要注意，后端文件上传（展馆封面图片）需要配置上传路径映射至Nginx的/uploads静态目录，图片才能正常加载。

事先在本地把整套流程跑通，部署阶段就顺风顺水。我建议你先在本地用mvn clean package打出JAR包，再用java -jar启动，确认接口正常后，再镜像Nginx配置到服务器。服务器上开安全组端口不要敞开数据库3306端口，只开80和22，MySQL只允许本机连接，数据安全是底线。

5. 常见问题与排查技巧实录

5.1 开发期最容易踩的五个坑

第一个坑：时区与日期问题。MySQL服务器时区、JVM时区、浏览器时区不一致，会导致预约日期出现错位（比如用户选的6月15日落到数据库变成6月14日或16日）。解决办法是统一时区，数据库连接串加serverTimezone=Asia/Shanghai，MySQL服务端设default-time-zone='+8:00'，日期字段统一用LocalDateTime处理。这个坑几乎每个用SpringBoot连MySQL的人都会踩，提前配置好能省一天的时间。

第二个坑：事务注解失效。@Transactional默认只在RuntimeException时回滚，如果你代码里捕获了异常但没有再抛出，事务就没有回滚。更隐蔽的是，如果createBooking方法在同一个类里被另一个方法调用，@Transactional也会失效（因为Spring AOP代理调用问题）。一定要把事务方法放在Service类里，并且不要用this.调用()的方式自调用。

第三个坑：跨域配置错误。前后端分离开发时，前端页面访问http://localhost:9527，后端接口在http://localhost:8080，浏览器会拦截跨域请求。我在后端写了全局CorsFilter，允许指定来源，而不是粗暴地allowedOrigins("*")。生产环境直接走Nginx代理，开发环境才需要处理跨域，这个区分要想清楚。

第四个坑：二维码生成后前端无法显示。本地开发时后端的图片URL是localhost:8080/upload/xxx.jpg，手机（局域网测试）无法访问，需要把IP换成局域网地址或配置Nginx映射。这个坑在演示前一定要提前排查，避免现场丢人。

第五个坑：大量并发预约时数据错乱。我当时用JMeter压了200个并发请求预约同一场次，发现实际预约成功数比配额多出七八条。原因是当时没加行锁，后来加上selectByIdForUpdate后复测，数据完全正确。做并发测试和修复问题这个过程，我强烈建议你在论文的"系统测试"环节详细展开，这比说"系统运行稳定"有说服力十倍。

5.2 答辩高频问题与应对预案

我整理了一套答辩老师最爱问的问题清单，你提前准备，现场就能对答如流。

"分时预约如何防止超卖？"这是必问题。回答主线：悲观锁控制场次记录的并发更新，通过事务保证booked_count的增减与预约记录插入的原子性。可以把那段FOR UPDATE代码讲一遍，再补一句"如果未来流量增长可以引入Redis预扣库存，但目前单机MySQL已满足业务量级"。

"为什么选择MySQL而不是Redis做数据存储？"回答要点：核心业务数据（订单、用户、场次）需要持久化、支持事务和复杂查询，MySQL的ACID特性更契合；Redis适合做缓存层（验证码、热点场次余票），二者组合使用，而不是二选一。

"系统有哪些安全性设计？"从四个层面讲：密码BCrypt加盐加密、JWT无状态鉴权、验证码防机器刷接口、操作日志留痕审计。如果老师追问SQL注入，你说MyBatis-Plus的预编译机制天然防注入，并补充生产环境的MySQL端口不对外开放。

"你的系统能支撑多大并发？"先定一个数据量假设（如日均预约5000单），再说当前方案在该量级下完全够用，压力测试显示QPS可达200+，最后用"高并发场景下可通过增加Redis缓存、引入消息队列异步化订单处理、MySQL读写分离"作为演进方向。这段话是标准答案，但需要你自己先跑过压测，数据才有说服力。

"项目的难点是什么？"回答分时预约并发控制、角色权限体系、统计看板聚合查询三个层面，每个难点都要说破题思路和最终方案。老师想听到的是你真实思考过，照本宣科没用。

5.3 优化与避坑建议速查表

这些坑我几乎一个个都踩过，写出来是希望你能绕过去。有些问题你在开发时觉得"反正单机演示没事"，但答辩现场一旦出现，非常影响整体效果。所以每完成一个功能模块，就顺手做一次"破坏性测试"，模拟错误操作看看系统提示是否友好，这是好习惯。

6. 论文撰写与毕业答辩的实战经验

6.1 论文结构安排与写作节奏

论文和代码要同步推进，别等代码写完了再动笔。我的经验是"模块完成一章，论文跟进一章"，这样论文内容既有真实代码支撑，你也不会在答辩前的一个月里焦头烂额。整体结构遵循毕业论文的经典五章式：绪论（研究背景意义、国内外现状、研究内容方法）、相关技术介绍（SpringBoot、MySQL、Vue、JWT等）、系统分析（可行性分析、需求分析、用例图、功能结构图）、系统设计（总体架构、功能模块设计、数据库设计）、系统实现（核心功能截图+关键代码+实现说明）、系统测试（测试用例表、功能测试、性能测试）。如果你的学校要求六章或七章，在这个骨架上适当拆分即可。

每个章节的写作都有技巧。绪论不要写空话，要结合真实背景——大型博物馆线上预约制的推行、节假日参观高峰的调度难题。相关技术介绍别抄官网文档，从"为什么选它"的角度写，每个技术点用两三段讲清楚核心特性和应用场景即可。系统分析部分要画好用例图、E-R图、流程图（注意这里我说的"图"是指论文里的静态图片，不是代码里的类图），这些图比大段文字更能让老师快速建立系统认知。

系统实现部分是论文的重量级章节，要用"功能模块+界面截图+关键代码+实现说明"的固定组合。界面截图要保证页面干净、数据有代表性（不要出现空表或乱码）；关键代码只放核心业务逻辑，不要大段贴CRUD；实现说明讲清楚代码的意图。系统测试部分要表格化，把测试用例、预期结果、实际结果列清楚，再加上并发压测的结果分析。

6.2 答辩现场演示与讲解技巧

答辩时不要从头到尾把每个功能点一遍，那是很多同学容易犯的错。评委老师时间有限，你要把有限时间花在最有价值的地方。我的建议是"场景驱动"演示：讲一个完整的用户故事。

开场先介绍系统总体架构（前后端分离、SpringBoot+MySQL+Vue），然后用大白话描述一个场景："一位外地游客想在端午节参观某博物馆，他打开小程序，选择日期和上午时段，系统显示还有12个名额，他提交预约，生成二维码；当天到了现场，核销员扫码，核验身份后放行。与此同时，运营后台实时看到当日预约量变化曲线。"沿着这个故事把游客端、核销端、运营端串起来展示，流畅、完整、有重点，比机械地挨个展示菜单强得多。

在讲到并发控制时，可以当场打开JMeter或Postman的并发测试结果截图，展示200个并发请求前后台的数据一致性。这个是整个答辩演示的高光时刻——大多数同学只会说"系统稳定运行"，你拿出数据，直接碾压同行。但记住，前提是你真跑过测试、数据经得起推敲。

被老师提问时，不要急着开口。先停顿两三秒，在脑子里组织好答案结构："这个问题我从两个层面来回答"。如果遇到不会的题目，坦诚说"这部分我没有深入考虑，但我知道业界常见的做法是XXX，我可以下去学习后补充"，比强行编造好得多。自信、诚实、有逻辑，就是最好的答辩状态。

6.3 哪些功能可以后续扩展

在论文的"总结与展望"章节，要写系统现有的不足和未来拓展方向。这里不是让你写应付的话，而是真正给系统留出升级空间，也显得你有工程大局观。

我列了几个方向供参考。第一，引入消息队列（如RabbitMQ）做预约流量的削峰填谷，配合Redis预扣库存，能撑起大促级别的并发预约。第二，增加用户黑名单与信用积分机制，未到场扣分、信用分低者限制预约，这能提升展馆资源利用率，也是"智慧展馆"概念的延伸。第三，对接微信小程序或支付宝小程序，把预约入口做到国民级应用里，博物馆的覆盖面会大幅提升。第四，引入数据大屏，把实时客流、馆内热点区域、参观动线等数据可视化，让管理者一目了然。

最后再分享一个小心得：毕设项目做到"能演示、能讲清、能答疑"三个阶段才算真正完成。能做出来是第一步，能把每个设计决策背后的为什么讲清楚是第二步，能扛住评委连环发问是第三步。博物馆预约系统这个题目的最大好处就是它的业务链条完整且贴近现实，你只要认真做完整个闭环，无论代码能力还是业务理解，都会有一个肉眼可见的跃升。如果你正在选题目或者已经定了这个方向，别犹豫，把上面这些设计逐一落地，它就是你的作品，不是别人的模板。