机房管理系统设计与实现：设备状态、预约冲突与工单闭环

简介：本资源是一份面向高校数据库课程设计实践的机房管理系统完整开发资料包，适用于计算机专业本科生及初学数据库设计的学习者，聚焦机房设备、用户、预约与使用记录等核心业务的数据建模与实现。压缩包共3个文件（2个Word文档+1个SQL脚本），总大小155KB：其中《数据库设计说明书.doc》和《详细设计.doc》系统阐述ER模型构建、关系模式转换、范式分析（1NF/2NF/3NF）、索引设计及关键SQL查询逻辑；《学院机房管理系统.sql》提供可直接运行的建表语句、约束定义与基础测试数据，覆盖机房、设备、用户、预约、使用记录五大实体及其关联关系。目前已有756人学习下载，资料结构紧凑、理论与实操高度对应，特别适合课程设计快速上手、理解数据库设计全流程并完成答辩交付。

1. 机房管理系统：不是做个登录页就叫“管理系统”，它得管得住设备、算得清工单、扛得住300台终端并发

去年帮某高校信息中心做毕设答辩辅导时，看到一个学生演示“机房管理系统”——首页是张静态机房照片，点“设备管理”跳转到Excel表格截图，后台用的是本地SQLite，连管理员密码都明文写在JS里。导师当场问：“如果明天有20个老师同时预约50台电脑做实验课，系统怎么锁资源？怎么防冲突？断电重启后预约记录还在不在？”学生愣住。这暴露了多数课设/毕设的通病：把“有界面”当成“能管理”。真正的机房管理系统，核心不是炫技的前端，而是资源状态可溯、预约逻辑闭环、故障响应可追、数据变更可控。它要服务三类人：管理员（批量操作+权限隔离）、教师（快速预约+冲突提示）、学生（自助查询+扫码签到）。本方案基于真实交付项目提炼，采用B/S架构，后端用Spring Boot 2.7 + MyBatis Plus，数据库用MySQL 8.0（非SQLite），支持300+终端并发压测，含完整ER图、4张核心数据表设计、预约冲突检测SQL、设备离线自动告警逻辑，以及答辩高频问题应答清单。适合计算机专业本科毕设、信管专业课程设计，或中小IT部门快速落地轻量级机房运维工具。

2. 需求拆解与数据库设计：从“我要管电脑”到“设备-预约-工单-日志”四维数据模型

机房管理不是简单罗列电脑编号。我带过三个类似项目，发现需求常被模糊成“方便老师预约”“能查设备状态”，但落地时必然卡在四个硬骨头：设备状态如何实时同步？预约时间重叠怎么拦？维修工单和设备绑定怎么不丢？谁在什么时间动过哪台设备？这四点直接决定数据库是否健壮。下面按真实交付节奏拆解。

2.1 核心业务场景驱动字段设计

先明确四个刚性场景：

• 场景1：教师A预约“周三9:00-11:00，机房A-01至A-30共30台”，系统必须校验该时段该区域无其他预约，且30台设备当前状态均为“空闲”；
• 场景2：学生B扫码签到后，设备状态需从“空闲”变“使用中”，若15分钟未操作，自动触发“疑似离席”告警；
• 场景3：设备C报修，工单生成时必须关联具体设备ID、报修人、故障现象，并支持上传现场照片；
• 场景4：管理员导出“上月设备故障TOP5”，需统计每台设备报修次数、平均修复时长、是否超期。

这些场景倒逼出四张主表：device（设备表）、reservation（预约表）、repair_ticket（工单表）、device_log（操作日志表）。关键不是字段多，而是字段间约束是否闭环。比如reservation表里不能只存“开始时间”“结束时间”，必须加status（预约状态：待确认/已生效/已取消/已过期）和conflict_flag（冲突标记：0=无冲突，1=存在时间/区域重叠），否则后期查冲突要全表扫描，性能崩盘。

2.2 ER图与四张核心表结构详解

ER图核心关系：一台设备（device）可产生多条日志（device_log）和多个工单（repair_ticket）；一次预约（reservation）关联多台设备（通过中间表reservation_device实现多对多）。以下是生产环境验证过的表结构，字段命名直击痛点：

-- 设备表：重点在status字段的枚举值和last_heartbeat时间戳 CREATE TABLE `device` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `code` varchar(32) NOT NULL COMMENT '设备编号，如A-01', `room_id` bigint NOT NULL COMMENT '所属机房ID', `ip_address` varchar(15) DEFAULT NULL COMMENT 'IP地址，用于心跳检测', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：0=离线，1=空闲，2=使用中，3=维修中，4=报废', `last_heartbeat` datetime DEFAULT NULL COMMENT '最后心跳时间，超10分钟未更新则置为离线', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_code` (`code`), KEY `idx_room_status` (`room_id`,`status`) ) ENGINE=InnoDB COMMENT='设备基础信息表'; -- 预约表：关键在time_range字段组合与冲突检测索引 CREATE TABLE `reservation` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL COMMENT '预约标题，如"大一C语言实验"', `teacher_id` bigint NOT NULL COMMENT '预约教师ID', `start_time` datetime NOT NULL COMMENT '开始时间', `end_time` datetime NOT NULL COMMENT '结束时间', `room_id` bigint NOT NULL COMMENT '预约机房ID', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：0=已取消，1=待确认，2=已生效，3=已过期', `conflict_flag` tinyint NOT NULL DEFAULT '0' COMMENT '冲突标记：0=无冲突，1=存在重叠', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_time_room` (`start_time`,`end_time`,`room_id`) COMMENT '覆盖查询：查某时段某机房所有预约' ) ENGINE=InnoDB COMMENT='预约主表'; -- 预约-设备关联表：解决“一次预约多台设备”的原子性 CREATE TABLE `reservation_device` ( `id` bigint NOT NULL AUTO_INCREMENT, `reservation_id` bigint NOT NULL COMMENT '预约ID', `device_id` bigint NOT NULL COMMENT '设备ID', `assigned_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '分配时间，用于追溯', PRIMARY KEY (`id`), UNIQUE KEY `uk_rid_did` (`reservation_id`,`device_id`), KEY `idx_did` (`device_id`) ) ENGINE=InnoDB COMMENT='预约与设备的多对多关系表'; -- 工单表：status字段必须支持维修流程状态机 CREATE TABLE `repair_ticket` ( `id` bigint NOT NULL AUTO_INCREMENT, `device_id` bigint NOT NULL COMMENT '故障设备ID', `reporter_id` bigint NOT NULL COMMENT '报修人ID', `description` text COMMENT '故障描述', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：1=待受理，2=处理中，3=已修复，4=已关闭，5=已驳回', `assignee_id` bigint DEFAULT NULL COMMENT '指派人ID', `closed_time` datetime DEFAULT NULL COMMENT '关闭时间', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_device_status` (`device_id`,`status`) ) ENGINE=InnoDB COMMENT='设备维修工单表';

提示：device表的last_heartbeat字段是设备在线状态的生命线。实际部署时，每台终端需运行一个轻量心跳脚本（Python或Shell），每30秒向API发送POST /api/heartbeat?deviceCode=A-01，后端更新该字段。若超过10分钟未更新，定时任务自动将status置为0（离线）。这个设计比前端轮询更可靠，也避免了“明明设备关机了，系统还显示空闲”的玄学问题。

2.3 冲突检测SQL：一行SQL堵死90%预约纠纷

预约冲突是机房管理最常被挑战的点。很多方案用代码遍历判断，但高并发下极易漏判。正确做法是把冲突逻辑下沉到数据库层，用唯一索引+触发器或应用层SQL原子判断。我们选后者，因其更可控、易调试。核心SQL如下：

-- 检测某时段某机房是否存在时间重叠的生效预约（status=2） SELECT COUNT(*) FROM `reservation` r WHERE r.room_id = ? AND r.status = 2 AND r.start_time < ? -- 新预约结束时间 AND r.end_time > ?; -- 新预约开始时间

参数说明：?依次为新预约的room_id、新预约的end_time、新预约的start_time。此SQL利用idx_time_room索引，毫秒级返回结果。若COUNT>0，说明存在重叠，拒绝创建。注意：必须在事务中执行此SQL+INSERT，否则仍可能并发冲突。Spring Boot中用@Transactional包裹即可。

2.4 日志表设计：不为审计而生，专为“谁动了我的电脑”取证

device_log表常被忽略，但它决定系统是否可信。字段设计必须满足两个硬需求：能定位操作人，能还原操作链。因此不存“操作类型”字符串，而用整型action_type枚举（1=签到，2=签退，3=强制下线，4=状态变更），并强制记录operator_id（操作人ID）和source_ip（操作来源IP）。关键设计是related_id字段——当action_type=3（强制下线）时，该字段存被下线学生的登录ID；当action_type=4（状态变更）时，存工单ID。这样一条日志就能串联起“学生签到→设备异常→报修→管理员强制下线→维修完成”全链路。

CREATE TABLE `device_log` ( `id` bigint NOT NULL AUTO_INCREMENT, `device_id` bigint NOT NULL, `action_type` tinyint NOT NULL COMMENT '1=签到,2=签退,3=强制下线,4=状态变更', `operator_id` bigint NOT NULL COMMENT '操作人ID，学生/教师/管理员统一ID体系', `source_ip` varchar(15) NOT NULL COMMENT '操作来源IP', `related_id` bigint DEFAULT NULL COMMENT '关联ID，如student_id或ticket_id', `remark` varchar(200) DEFAULT NULL COMMENT '备注，如"网络异常强制下线"', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_device_time` (`device_id`,`created_time`), KEY `idx_op_time` (`operator_id`,`created_time`) ) ENGINE=InnoDB COMMENT='设备操作日志表';

3. 后端核心模块实现：Spring Boot中如何让预约不超时、设备不掉线、工单不丢失

数据库是骨架，后端是血肉。这里不讲Spring Boot启动原理，只聚焦三个模块的真实落地细节：预约引擎、设备心跳服务、工单状态机。每个模块都来自某次线上翻车后的重构。

3.1 预约引擎：用Redis分布式锁解决高并发下的“最后一台电脑”争抢

场景：300名学生同时抢“周五下午最后一节”的30台电脑。若用数据库行锁，大量请求会阻塞在SELECT FOR UPDATE，响应超时。我们改用Redis分布式锁，但关键在锁粒度与释放时机。错误做法是锁整个机房，正确做法是锁“机房+时间段”组合：

// Redis锁Key：RESERVATION_LOCK:{roomId}:{dateStr}:{hourSlot} // 例：RESERVATION_LOCK:1:20240520:14 表示机房1在2024-05-20的14点时段 String lockKey = String.format("RESERVATION_LOCK:%d:%s:%s", roomId, DateUtil.formatDate(new Date(), "yyyyMMdd"), String.valueOf(startHour)); // 加锁，30秒超时，防止死锁 Boolean isLocked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "locked", 30, TimeUnit.SECONDS); if (!isLocked) { throw new BusinessException("预约繁忙，请稍后重试"); } try { // 1. 检查设备库存（查device表status=1的数量） long availableCount = deviceMapper.countAvailableByRoom(roomId); if (availableCount < needCount) { throw new BusinessException("设备不足，当前仅剩" + availableCount + "台"); } // 2. 执行预约逻辑（插入reservation + reservation_device） reservationService.createReservation(reservationDto); } finally { // 必须用Lua脚本保证删除原子性，避免误删其他线程的锁 String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; redisTemplate.execute(new DefaultRedisScript<>(script, Long.class), Collections.singletonList(lockKey), "locked"); }

注意：countAvailableByRoom方法必须走SELECT COUNT(*) FROM device WHERE room_id=? AND status=1，且device表的room_id和status字段有联合索引（已在2.2节建好）。这是性能关键，避免全表扫描。

3.2 设备心跳服务：用Scheduled+异步线程池保活，不卡主线程

设备心跳看似简单，但若用@Scheduled(fixedDelay = 30000)直接查库更新，300台设备每30秒一次全表扫描，CPU飙升。优化分三步：

1. 分片扫描：将设备按ID取模分10组，每组30秒轮询，降低单次压力；
2. 异步更新：查出离线设备后，用@Async提交到专用线程池更新状态，不阻塞调度线程；
3. 状态缓存：用Caffeine缓存设备最新状态（key=deviceId, value=status），读多写少场景提速10倍。

// 心跳检测任务（每30秒执行） @Scheduled(fixedDelay = 30000) public void checkDeviceHeartbeat() { // 分片：取模10，当前线程处理第i组 int shard = (int)(System.currentTimeMillis() % 10); List<Device> offlineDevices = deviceMapper.findOfflineByShard(shard, 600); // last_heartbeat超600秒 if (!offlineDevices.isEmpty()) { // 异步更新状态，避免阻塞 updateStatusAsync(offlineDevices); } } @Async("deviceUpdateExecutor") // 自定义线程池 public void updateStatusAsync(List<Device> devices) { devices.forEach(device -> { device.setStatus(DeviceStatus.OFFLINE.getCode()); deviceMapper.updateById(device); // 更新缓存 caffeineCache.put(device.getId(), device.getStatus()); }); }

3.3 工单状态机：用状态模式+数据库约束，杜绝“已修复”工单再被修改

工单状态流转必须强约束：待受理→处理中→已修复→已关闭，禁止跳转（如不能从待受理直跳已关闭），禁止回滚（已关闭不能变处理中）。我们弃用if-else硬编码，改用状态模式，核心是RepairTicketService的updateStatus方法：

public void updateStatus(Long ticketId, Integer newStatus, Long operatorId) { RepairTicket ticket = ticketMapper.selectById(ticketId); // 数据库级校验：查当前状态 Integer currentStatus = ticket.getStatus(); // 状态流转规则表（内存Map，启动时加载） Map<Integer, Set<Integer>> validTransitions = stateMachineConfig.getValidTransitions(); if (!validTransitions.getOrDefault(currentStatus, Collections.emptySet()).contains(newStatus)) { throw new BusinessException("状态流转非法：从" + currentStatus + "不能变为" + newStatus); } // 原子更新：WHERE条件包含当前状态，防并发覆盖 int updated = ticketMapper.updateStatusByIdAndCurrentStatus( ticketId, newStatus, currentStatus, operatorId, new Date()); if (updated == 0) { throw new BusinessException("状态更新失败，可能已被他人修改"); } }

对应的MyBatis XML中，updateStatusByIdAndCurrentStatus的SQL必须带AND status = #{currentStatus}，这是最终防线。

4. 前端与交互设计：扫码签到不卡顿、预约页面不白屏、状态看板不糊弄

前端不是“套个Vue模板”，而是解决真实场景的交互痛点。某次上线后，教师反馈“预约页面打开要5秒”，查因是首页加载了全部300台设备状态；学生抱怨“扫码后屏幕卡住”，实为前端未做Loading态。以下设计均经压测验证。

4.1 预约页面：懒加载+时间轴渲染，首屏加载<1秒

传统做法：进入预约页，一次性加载本周所有机房、所有时段、所有设备状态，JSON超2MB。优化后：

• 机房列表：首次只加载启用中的机房（SELECT * FROM room WHERE enabled=1）；
• 时段选择：用时间轴组件（非下拉框），默认显示当前周，滚动加载下周；
• 设备状态：不预加载，用户点击“查看A区设备”时，才发GET /api/devices?room=A&status=1，返回精简字段（id, code, status）。

<!-- Vue组件：时间轴时段选择 --> <template> <div class="timeline"> <div v-for="slot in timeSlots" :key="slot.id" @click="selectTimeSlot(slot)" :class="{ 'active': selectedSlot === slot }" class="timeline-item" > {{ slot.startTime }}-{{ slot.endTime }} <!-- 动态显示该时段可用设备数 --> <span class="available-count">{{ slot.availableCount }}</span> </div> </div> </template> <script> export default { data() { return { timeSlots: [], // 初始为空，滚动时加载 selectedSlot: null } }, mounted() { this.loadTimeSlots(); // 只加载当前周 }, methods: { loadTimeSlots() { // 调用API，参数：weekOffset=0（当前周） api.getTimeSlots({ weekOffset: 0 }).then(res => { this.timeSlots = res.data; }); } } } </script>

4.2 扫码签到：WebSocket实时反馈，告别“转圈圈”

学生扫码后，传统HTTP轮询（每2秒查一次）导致体验卡顿。改用WebSocket，设备端扫码即触发/ws/signin?code=A-01，后端广播{deviceId: "A-01", status: "using", timestamp: "2024-05-20T09:00:00"}，前端监听并立即更新UI：

// 前端WebSocket连接 const ws = new WebSocket('wss://your-domain.com/ws'); ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.deviceId === this.deviceCode) { this.deviceStatus = data.status; // 直接更新状态 this.lastActive = data.timestamp; this.$message.success(`已成功签到！`); } }; // 扫码后发送请求 this.$http.post('/api/signin', { code: this.qrCode }).then(() => { // 不等响应，直接显示Loading，由WS通知结果 this.loading = true; });

提示：WebSocket服务端用Spring Boot的@MessageMapping实现，消息广播用SimpMessagingTemplate.convertAndSend("/topic/device/status", message)。务必配置心跳包（server.websocket.max-text-message-size=1024000），防Nginx代理超时断连。

4.3 管理看板：ECharts动态图表，数据不准就换颜色

看板不是摆设。某次巡检发现“设备在线率98%”的图表，点进去发现是把“未上报心跳的设备”全算作在线。修正后：

• 在线率 =COUNT(status=1 OR status=2) / COUNT(*) * 100；
• 故障TOP5用柱状图，但柱子颜色按修复时长分级：≤24h绿色，24-72h黄色，>72h红色；
• 所有图表数据源必须是/api/dashboard/stats接口，该接口聚合device、repair_ticket、device_log三表，用MySQL视图或MyBatis多表JOIN实现，禁用前端计算。

-- 看板统计视图（简化版） CREATE VIEW dashboard_stats AS SELECT r.room_name, COUNT(d.id) as total_devices, COUNT(CASE WHEN d.status IN (1,2) THEN 1 END) as online_count, COUNT(CASE WHEN t.status = 3 AND t.closed_time > DATE_SUB(NOW(), INTERVAL 24 HOUR) THEN 1 END) as fixed_24h, COUNT(CASE WHEN t.status = 3 AND t.closed_time <= DATE_SUB(NOW(), INTERVAL 24 HOUR) THEN 1 END) as fixed_over_24h FROM room r LEFT JOIN device d ON r.id = d.room_id LEFT JOIN repair_ticket t ON d.id = t.device_id GROUP BY r.room_name;

5. 避坑指南：那些让我凌晨三点改代码的“小问题”

做过三个机房系统，踩过的坑比写的代码还多。以下5条是答辩和上线时最高频的翻车点，按“现象→原因→解决”给出血泪经验，每条都对应真实事故。

5.1 现象：预约成功后，设备状态没变，学生扫码还是显示“空闲”

原因：预约创建和设备状态更新不在同一事务。reservation插入成功，但UPDATE device SET status=2因网络抖动失败，事务未回滚。
解决：用@Transactional包裹整个预约流程，并在reservation_device插入后，立即执行deviceMapper.updateStatusBatch(deviceIds, DeviceStatus.USING)，而非依赖前端或定时任务。状态更新失败则抛异常，事务自动回滚。

5.2 现象：MySQL CPU 100%，慢查询日志全是SELECT * FROM device WHERE status=1

原因：device表数据量超10万，status字段无索引，全表扫描。
解决：添加复合索引ALTER TABLE device ADD INDEX idx_status_room (status, room_id)。注意：单列status索引效果差，因status只有5个值，区分度低，必须加room_id提升选择性。

5.3 现象：教师说“我取消了预约，但设备还是被锁着”，查数据库发现reservation.status=0但device.status=2

原因：取消预约时，只更新了reservation表，忘了触发device状态回滚。
解决：在ReservationService.cancel()方法中，强制调用deviceService.releaseDevices(reservationId)，该方法根据reservation_device表查出所有关联设备，批量更新status=1（空闲）。并在device_log中记录“因预约取消释放设备”。

5.4 现象：扫码签到偶尔失败，日志显示“设备A-01不存在”，但设备表里明明有

原因：扫码用的设备编号是学生手输的，或二维码生成时多了一个空格，如"A-01 "。
解决：在SignInController中，对code参数做trim()和toUpperCase()标准化：String cleanCode = code.trim().toUpperCase();，再查库。同时，设备编号录入时增加校验正则^[A-Z]-\\d{2,3}$，前端和后端双重拦截。

5.5 现象：导出Excel卡死，浏览器提示“连接已重置”

原因：导出接口/api/export/reservations用List<Reservation>查出全部数据再转Excel，内存溢出。
解决：改用流式导出。MyBatis用ResultHandler逐条处理，Apache POI用SXSSFWorkbook（内存行数限制为100），边查边写：

@GetMapping("/export/reservations") public void exportReservations(HttpServletResponse response) throws IOException { response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setHeader("Content-Disposition", "attachment; filename=reservations.xlsx"); SXSSFWorkbook workbook = new SXSSFWorkbook(100); // 内存保留100行 Sheet sheet = workbook.createSheet("预约记录"); // 写表头... // 流式查询，避免OOM reservationMapper.selectForExport(new ResultHandler<Reservation>() { @Override public void handleResult(ResultContext<? extends Reservation> context) { Reservation r = context.getResultObject(); Row row = sheet.createRow(sheet.getLastRowNum() + 1); // 填充单元格... } }); workbook.write(response.getOutputStream()); workbook.dispose(); // 必须调用，释放临时文件 }

6. 答辩与验收：用“三问一演”法让导师闭嘴点头，而不是追问漏洞

答辩不是背稿，是证明你真懂这个系统。我带过的23个学生里，90%栽在“被问住”——不是不会，而是没准备导师的提问路径。我的经验是：用“三问一演”法构建答辩逻辑链：导师必问的三个底层问题 + 一个5分钟现场演示。这套方法在某高校信管专业连续三年答辩通过率100%。

6.1 导师必问的三个底层问题及应答策略

导师不会问“用了什么技术”，而是问技术背后的决策。以下是三个高频问题，附真实应答话术（非背诵，是思路）：

6.2 5分钟现场演示：只演“最痛的场景”，不秀花活

答辩演示切忌“首页→设备→预约→工单→日志”全走一遍。导师没耐心，且看不出价值。我让学生只演一个场景：教师紧急预约+学生扫码签到+设备异常处理全链路。步骤严格计时：

1. 0:00-1:30 教师预约：登录教师账号 → 选“机房A” → 选“今天14:00-15:00” → 输入“大二Java实验” → 点击预约 → 显示“预约成功，已锁定A-01至A-30”。（此时后台SQL日志应显示：INSERT reservation + INSERT 30条reservation_device + UPDATE 30台device.status）
2. 1:30-3:00 学生签到：用手机扫A-01二维码 → 页面秒变“已签到，剩余时间：59:59” → 同时管理后台看板“机房A在线设备”数字+1。（此时WebSocket日志应显示广播消息）
3. 3:00-4:30 设备异常：手动将A-01的last_heartbeat设为1小时前 → 30秒后看板“在线率”下降，A-01状态变灰色 → 点击A-01“报修” → 填写“蓝屏”，提交 → 工单列表出现新工单，状态为“待受理”。（此时device_log应有两条记录：签到+状态变更）
4. 4:30-5:00 总结价值：“这个5分钟，覆盖了教师、学生、管理员三方核心动作，验证了预约原子性、状态实时性、故障可追溯性——这正是机房管理系统的三大支柱。”

6.3 答辩材料包：一份让导师主动夸“准备充分”的附件

除了PPT，我坚持让学生交一份《答辩材料包》，含三个文件：

• design_decisions.md：用表格列出5个关键设计选择（如“为何用Redis锁而非数据库锁”），每项写“选项A/选项B/选择B的理由/实测数据”；
• test_report.pdf：JMeter压测报告截图（300并发下预约接口P95<800ms）、MySQL慢查询优化前后对比；
• q_and_a.md：预判10个问题及答案，其中3个是“我不知道，但我会…”（如“Q：如何对接学校LDAP？A：目前用本地账号，对接LDAP需扩展UserDetailsService，我已研究Spring Security LDAP文档，预计2天可完成”）。

从那以后我每次带毕设，都强制学生在答辩前一周，用这份材料包找我模拟答辩。不是为了背答案，而是训练他们把“我做了什么”转化成“我为什么这么做，做得好不好”。希望帮到你。

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