美术馆预约系统开发全解析：从数据库设计到并发防超卖

简介：美术馆预约系统是一套面向艺术场馆的数字化管理解决方案，也可作为计算机相关专业毕业设计项目的完整参考。系统业务链路清晰，覆盖用户注册登录、预约购票、展览信息维护、票务与订单管理、消息通知和后台数据分析等功能，前端采用响应式布局适配电脑、手机与平板等不同设备。项目融合Java后端逻辑、数据库规范化设计、前端交互与安全管理等多个软件工程环节，有助于读者建立从需求分析、模块拆分到权限控制和并发预约处理的整体认知。资源包共517个文件，以Java源码、SQL数据库脚本、HTML/CSS/JavaScript前端代码为主，同时包含XML配置文件、GIF/PNG界面图与图标素材，部分界面基于AdminLTE和Bootstrap搭建，便于快速理解后台管理框架的样式组织方式。压缩后整体大小约3.01MB，文件类型多样但结构清晰，可按业务模块定位对应代码。已有552人学习下载，适合需要完成同类系统设计、巩固前后端整合能力或研究预约类业务流程的开发者参考。

1. 美术馆预约系统的毕业设计：一套能跑通全流程的工程样板

做毕业设计最怕的不是技术难，而是思路散。美术馆预约系统这个题目恰好卡在“能做”和“做得像样”之间——它有数据库、有并发预约、有票务和退款、还有后台管理和响应式页面，是一个能覆盖软件工程完整流程的综合型项目。我拆这套资源时最大的感受是：它不是把页面做出来就完事，而是把预约从“用户选时间”到“管理员对账”这条链路完整串了起来。适合想拿一个有深度、能答辩、能演示的毕设项目的同学，也适合想快速上手全栈业务系统的开发者。接下来我从前端资源、数据模型、并发控制、避坑和验证几个维度逐个拆开讲。

2. 前端资源与响应式布局：从 CSS 骨架到多端适配

2.1 资源包里每份 CSS 各自管什么

项目正文里那串 CSS 文件不是随便堆的，每一份都有自己的职责。我建议拿到资源后先花十分钟建立这个映射关系，后面改样式时才不会在十几个 CSS 里迷路。

这里有个关键点：bootstrap 必须最先加载，因为 AdminLTE 是建立在 Bootstrap 之上的，加载顺序错了会直接导致后台布局错乱。jqGrid 则是后台管理里表格的核心，预约记录、订单列表、退款申请这类数据密集场景都靠它支撑。

2.2 栅格布局与预约页面的响应式写法

响应式设计的落地主要靠 Bootstrap 的栅格体系，我拆这套资源时发现它的预约页做得很标准：用col-lg、col-md、col-sm三档分别对应桌面、平板、手机。下面是从预约页面里抽出的一段典型结构：

<div class="row"> <div class="col-lg-8 col-md-7 col-sm-12"> <div class="box box-primary"> <div class="box-header"> <h3 class="box-title">选择参观时间段</h3> </div> <div class="box-body"> <div class="form-group"> <label>参观日期</label> <input type="date" id="visitDate" class="form-control" min="2025-01-01" max="2025-12-31" /> </div> <div class="form-group"> <label>时间段</label> <select id="timeSlot" class="form-control"> <option value="09:00-11:00">上午 09:00-11:00</option> <option value="14:00-16:00">下午 14:00-16:00</option> </select> </div> <div class="form-group"> <label>剩余票数</label> <span id="remainingTickets" class="label label-success">--</span> </div> </div> </div> </div> <div class="col-lg-4 col-md-5 col-sm-12"> <div class="box box-solid"> <div class="box-body"> <h4>预约须知</h4> <p>请提前 30 分钟到场核验电子票</p> <button type="button" id="submitReservation" class="btn btn-primary btn-block">提交预约</button> </div> </div> </div> </div>

栅格的逻辑是这样的：大屏下左侧内容区占 8 列，右侧提示区占 4 列；平板时变成 7:5；手机端直接两个块上下堆叠，全部占满 12 列。这种方式的好处是不用写额外的媒体查询就能覆盖主流设备。

参数调整上要注意两点：一是日期输入框的min和max要跟后端校验一致，否则用户选了后端不允许的日期会出现前端通过、后端报错的不一致体验；二是剩余票数的刷新，常见做法是页面加载后发一次 AJAX 请求获取剩余量，用户切换时间段时再发一次，避免展示过期数据。

2.3 打印样式与入场凭证：print.css 里的小细节

门票和订单凭证的打印是个容易翻车的细节。很多系统在浏览器打印时会顺带把导航栏、侧边栏、按钮一起打印出来，非常难看。这份资源里的做法是引入print.css，利用@media print把无关区域隐藏掉。

@media print { .main-header, .main-sidebar, .btn, .footer { display: none !important; } .content-wrapper { margin-left: 0 !important; padding: 0 !important; } .ticket-info { width: 100%; border: 2px solid #333; padding: 16px; font-size: 14px; } }

核心思路是：屏幕显示用screen.css，打印输出用print.css，两套样式互不干扰。使用!important是为了覆盖 AdminLTE 框架里优先级更高的选择器。这里有个经验：如果打印时出现多余空白页，多半是某个盒子的 margin 值没在 print 样式里重置，优先检查content-wrapper的margin-left，因为侧边栏占位会在打印时产生左侧空白。

3. 数据模型与用户/会员模块：建表与加密落地

3.1 实体关系与数据表设计思路

预约系统的数据模型我拆完之后的感受是：它没有过度设计，但该有的关联都有了。核心实体可以分成三组：用户侧（用户、会员）、业务侧（展览、预约、门票）、支撑侧（支付记录、通知记录）。它们之间的关系是：用户创建预约，预约关联到具体展览和时间段；预约支付后生成门票，门票入场时核验；取消预约时产生退款记录，退款记录关联支付记录。

设计时有三点是资源里反复强调的：一是预约表不直接存展览名称，而是存展览 ID，保持数据一致性；二是票数余额放在展览时间段表里，而不放在展览主表里，因为一天可能分上午和下午两个场次，两个场次的余票是独立的；三是所有业务表都带状态字段，这是后面做预约状态流转的基础。

3.2 核心建表 SQL 与字段说明

下面这组 SQL 是从资源里提炼的核心建表语句，为了篇幅我做了精简，字段说明在注释里：

-- 用户表 CREATE TABLE `user` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL COMMENT '登录名', `password` VARCHAR(255) NOT NULL COMMENT '加密后的密码', `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号', `email` VARCHAR(100) DEFAULT NULL COMMENT '邮箱', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 展览时间段表：余票在这里控制 CREATE TABLE `exhibition_session` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `exhibition_id` INT UNSIGNED NOT NULL COMMENT '展览ID', `session_date` DATE NOT NULL COMMENT '场次日期', `time_slot` VARCHAR(20) NOT NULL COMMENT '时间段，如09:00-11:00', `capacity` INT NOT NULL DEFAULT 100 COMMENT '总票数', `remaining` INT NOT NULL DEFAULT 100 COMMENT '剩余票数', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1=可预约 0=已关闭', PRIMARY KEY (`id`), UNIQUE KEY `uk_session` (`exhibition_id`, `session_date`, `time_slot`), KEY `idx_remaining` (`remaining`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 预约订单表 CREATE TABLE `reservation` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `user_id` INT UNSIGNED NOT NULL, `session_id` INT UNSIGNED NOT NULL COMMENT '展览时间段ID', `ticket_count` INT NOT NULL DEFAULT 1 COMMENT '预约票数', `amount` DECIMAL(10,2) NOT NULL COMMENT '订单金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0=待支付 1=已支付 2=已取消 3=已入场', `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `paid_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_session_id` (`session_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

三个关键设计：一是exhibition_session里的UNIQUE KEY约束了同一个展览同一天同一个时间段只能有一条记录，这是防止重复建场次；二是remaining字段单独建了索引，因为预约时WHERE remaining > 0是高频查询；三是order_no用唯一索引，这是后面做防超卖和订单幂等的基础保障。

3.3 用户密码加密与登录会话

用户密码这块资源里用的是哈希加盐，不是明文存储，也不推荐用 MD5 直接存。常见做法是用 PHP 的password_hash()或者 Java 的BCrypt，下面以 PHP 和 MySQL 为例写注册逻辑：

// 注册：密码哈希后入库 $password = password_hash($_POST['password'], PASSWORD_DEFAULT); $stmt = $pdo->prepare("INSERT INTO user (username, password, phone, email) VALUES (?, ?, ?, ?)"); $stmt->execute([$_POST['username'], $password, $_POST['phone'], $_POST['email']]); // 登录：用 password_verify 校验 $user = $pdo->prepare("SELECT id, password FROM user WHERE username = ?"); $user->execute([$_POST['username']]); $row = $user->fetch(); if ($row && password_verify($_POST['password'], $row['password'])) { $_SESSION['user_id'] = $row['id']; // 登录成功 } else { // 登录失败 }

password_hash()生成的字符串里本身就包含了盐和算法信息，所以校验时不需要单独存盐字段，直接password_verify()就行。这里要注意：不要为了省事把$_SESSION['user_id']换成$_SESSION['username']，拿到 ID 之后后续的预约、查订单都拿这个 ID 去关联，还能避免用户名一旦修改导致会话错乱的问题。

4. 预约与票务流程：状态机、锁与防超卖

4.1 预约状态机与订单生命周期

预约的核心不是表单提交，而是状态管理。我拆资源时把状态流转画成了一个直线加分支的结构：新建订单是“待支付”，支付完成变成“已支付”，入场核销后变成“已入场”；如果用户主动取消或支付超时，则变成“已取消”。整个流程里只有“待支付”和“已支付”两个状态允许被取消，其他状态不能做取消失败。

这个状态机就是后面所有业务逻辑的判断依据，前端按钮的展示、后端接口的校验、退款申请的审核，全部围绕这套状态值来写。

4.2 并发预约防超卖：悲观锁与剩余票数扣减

预约系统的技术难点在防超卖。同一个时间段只有 100 张票，两人同时提交时如果都读到remaining=1，都减一，最后就超卖了。资源里用的方案是事务加悲观锁：先锁住exhibition_session的对应行，再判断剩余票数，再更新，最后插入预约记录。

-- 伪代码：事务开始 START TRANSACTION; -- 1. 锁定该场次的行，阻止其他事务同时修改 SELECT id, remaining FROM exhibition_session WHERE id = 1001 FOR UPDATE; -- 2. 判断剩余票数是否充足 -- 假设上面查到 remaining = 5，本次预约 2 张 INSERT INTO reservation (user_id, session_id, ticket_count, amount, status, order_no) VALUES (10, 1001, 2, 40.00, 0, '20250101120001'); -- 3. 扣减余票 UPDATE exhibition_session SET remaining = remaining - 2 WHERE id = 1001 AND remaining >= 2; -- 4. 判断上一步影响的行数，如果为 0 则说明余票不足，回滚 -- ROW_COUNT() 返回本次 UPDATE 影响的行数 COMMIT;

这里的核心是SELECT ... FOR UPDATE把行锁住，直到事务提交才释放。UPDATE ... WHERE id = ? AND remaining >= ?是第二道保险，即使前面被锁的逻辑漏了，这一步也能通过影响行数兜底。我用的是悲观锁，因为预约系统的写冲突频率不高但后果严重，悲观锁实现简单、逻辑清晰，比乐观锁的版本号机制更适合毕设答辩时讲清楚。

4.3 购票、取消与退款窗口设计

票务侧的资源里把“取消”做成了时间窗口模式。规则是：开场前 2 小时允许取消并自动退款，开场前 2 小时内取消只能做异常申请，需要后台人工审核。这个窗口的实现是在取消接口里比对当前时间和场次开始时间：

$deadline = date('Y-m-d H:i:s', strtotime($session['session_date'] . ' ' . $startTime) - 7200); if (time() < strtotime($deadline)) { // 允许取消，状态改为已取消，退还余票 $pdo->beginTransaction(); // 更新预约状态为已取消 $pdo->prepare("UPDATE reservation SET status = 2 WHERE id = ? AND status = 1") ->execute([$reservationId]); // 回补余票 $pdo->prepare("UPDATE exhibition_session SET remaining = remaining + ? WHERE id = ?") ->execute([$ticketCount, $sessionId]); $pdo->commit(); } else { // 已过截止时间，提示走人工审核 }

窗口时间设置在系统配置里，不要硬编码。这个细节在答辩时容易被追问：“如果你的截止时间比系统时间晚一天怎么办？”所以初始化时一定要检查服务器时区，建议统一在 PHP 里date_default_timezone_set('Asia/Shanghai')，数据库连接也指定time_zone，否则前后台显示的时间不一致会让用户困惑。

5. 避坑与排查：并发、支付、部署三个方向

5.1 高频事故与修复记录

拆完这套资源后，我把里面涉及的坑按真实项目经验做了归类，挑了四个最具代表性的整理成踩坑记录。

事故一：剩余票数对不上账

现象：后台看到的remaining数据和实际售出的票数总和加起来不等于capacity。
原因：取消预约时只改了预约状态，没有回补remaining；或者回补时事务没提交就中断了。
解决：把余票回补放到和状态更新同一个事务里，两步要么同时成功要么同时失败，不要分两次请求去执行。

事故二：并发情况下两张票被卖三次

现象：压测时用 50 个并发请求抢最后 2 张票，结果生成了 3 个支付订单。
原因：查询余票和扣减余票之间没有加锁，两个请求同时读到remaining=2就都通过了。
解决：改用SELECT ... FOR UPDATE锁行后再扣减，同时加上remaining >= ticket_count的条件作为第二重校验。

事故三：支付回调重复通知导致重复发门票

现象：同一个订单被支付平台回调了两次，结果系统生成了两张相同门票。
原因：回调接口没有做幂等处理，每次收到通知都直接执行“把订单置为已支付并生成门票”的逻辑。
解决：在回调的入口先检查订单当前状态，只有订单还是“待支付”时才执行后续逻辑，已支付的订单直接返回成功。

事故四：本地正常部署后页面样式全崩

现象：后台管理页面打开后没有任何样式，HTML 结构完全裸露。
原因：资源路径写的是绝对路径，部署到二级目录时找不到 CSS 文件。
解决：将所有静态资源引用改为相对路径，或者用模板引擎的 base 标签统一处理，部署后先检查浏览器 Network 面板确认 CSS 的加载状态码是 200。

5.2 排查路线：从日志到数据库

排查这类系统问题时我的顺序是固定的：先看日志，再看数据库，最后才是改代码。日志层面，预约和支付模块一定要打业务日志，包含order_no、user_id和操作动作三个字段，这样一条订单的完整生命周期能通过order_no串起来。数据库层面，最常用的排查手段是查锁等待：

-- 查看当前锁等待状态 SELECT * FROM information_schema.INNODB_TRX; -- 查看锁等待关系 SELECT * FROM sys.innodb_lock_waits;

如果事务长时间不提交，INNODB_TRX里能看到持续时间很长的旧事务，这就是页面卡死或接口超时的常见根源。把长时间未提交的事务KILL掉，再回代码里检查事务是否有COMMIT路径确实被执行到。

6. 验证与进阶：从压测到关键日志核对

6.1 用并发脚本验证防超卖是否真的有效

代码写完了不代表它一定扛得住并发，我建议做一个简单的压测验证。下面这个脚本用 Python 并发模拟 30 个用户同时预约同一场次剩余 2 张票的场景：

import requests import threading import random url = "http://localhost:8080/api/reservation/create" def book_ticket(user_id): data = { "user_id": user_id, "session_id": 1001, "ticket_count": 1, } try: resp = requests.post(url, json=data, timeout=5) print(f"用户 {user_id}: {resp.status_code} {resp.json().get('msg')}") except Exception as e: print(f"用户 {user_id}: 请求异常 {e}") threads = [] for i in range(1, 31): t = threading.Thread(target=book_ticket, args=(i,)) threads.append(t) t.start() for t in threads: t.join()

跑完之后去数据库查两条数据：一是reservation表里session_id = 1001且状态不是“已取消”的订单数，加起来不能超过场次容量；二是exhibition_session表里该场次的remaining值是否和实际匹配。如果订单数超了或remaining变成负数，说明锁没生效。

6.2 日志追踪与入门槛验证

验证预约全链路时我习惯用一个固定订单号从头跟到尾，比如在下单接口打日志时强制写入order_no，然后去日志文件里用grep把这个订单所有操作日志过滤出来，看看先后顺序是否符合预期状态流转：

grep "20250101120001" /var/log/artmuseum/app.log

如果日志里显示的状态从 0 跳到 2 而没有经过 1，那大概率是回调逻辑里把状态直接覆盖了，写成了无条件更新。代码里更新订单状态时必须带上AND status = 0这样的前置条件，否则状态机形同虚设。从那以后我每次新模块上线前都会强制走一遍这个流程：并发压测一次，拉日志核对状态流转，再去数据库核数量。这套流程帮我挡下了不少上线后才暴露的问题，希望这次拆解的内容也能帮到你。

本文还有配套的精品资源，点击获取