基于 Django 与 Vue 3 的 AI 实验室智能预约系统设计与实现
摘 要
针对高校实验室资源预约中信息不透明、时段冲突频发、管理依赖人工的现状，本系统采用 Django REST Framework + Vue 3 前后端分离架构，MySQL 8.4 持久化，实现了"认证 → 实验室管理 → 预约与冲突检测 → 审批 → 签到 → 统计通知"的完整业务闭环，并在此之上叠加 AI 能力层：AI 对话助手、自然语言智能排期与 AI 运营分析大屏，形成"传统预约管理 + 大模型智能服务"的一体化平台。
系统的技术贡献集中在三处：一是预约冲突的正确性保障，采用半开区间 [start, end) 重叠判定结合 select_for_update() 行锁与事务串行化，从算法与并发两个层面杜绝重复预约；二是 AI 服务的离线降级设计，大模型接口不可用时自动切换本地规则内核，保证核心智能功能始终可演示、可用；三是可解释的智能排期，推荐方案附带综合评分与推荐理由并经过四维安全校验。后端基于 DRF APITestCase 编写 28 个接口级单元测试，覆盖冲突 409、越权 404、签到窗口、审批通知等关键路径，全部通过；页面功能经浏览器全流程走查验证。
1 系统概述
1.1 课题背景
高校实验室的日常使用长期存在三类问题：
- 信息不透明：实验室开放时段、设备配置、占用情况分散在公告与人工答复中，学生寻找可用空档成本高；
- 流程无序：预约、审批、签到缺乏统一系统支撑，高峰期时段撞车、恶意占坑难以约束；
- 利用率失衡：哪些实验室空闲、哪些时段拥挤缺乏数据呈现，资源调度依赖管理员经验，无法引导错峰使用。
1.2 课题意义
- 对学生：一站式查看实验室与空档、在线提交预约、实时获知审批结果，AI 助手支持用自然语言完成查询与办理；
- 对管理员：审批、实验室与设备维护、利用率统计集中在一个后台，AI 运营大屏将运行状态可视化并自动生成分析结论；
- 对毕业设计本身：覆盖 JWT 认证、并发控制、事务、可视化、大模型接入与降级设计等技术点，完整度高且均有工程实现支撑。
1.3 主要内容
第 1 章介绍课题背景与现状；第 2 章说明开发环境与技术选型；第 3 章进行可行性、功能与非功能需求分析；第 4 章给出架构、数据库与核心机制设计；第 5 章按模块展示详细实现；第 6 章给出测试方案与结果；最后总结全文。
1.4 研究现状
现有实验室预约类系统多停留在 CRUD 层面：能录入、能查询，但普遍存在两个缺口------其一，冲突检测仅在应用层做查询比对，缺少数据库层的并发保护，并发提交时可能产生重复预约；其二，预约数据沉睡在数据库中，缺少面向错峰引导与运营决策的数据可视化与智能分析。本系统针对这两个缺口，分别设计了行锁串行化的冲突防控机制和"热力图 + AI 运营大屏"的数据利用链路，并引入大模型能力降低普通用户的使用门槛。
2 系统开发环境
2.1 总体技术栈
| 层次 | 技术选型 |
|---|---|
| 前端 | Vue 3 + Vite + Element Plus + Pinia + Vue Router + axios + ECharts |
| 后端 | Python 3.13 + Django 6.1 + Django REST Framework + SimpleJWT + django-cors-headers |
| 数据库 | MySQL 8.4（PyMySQL 驱动，InnoDB 引擎） |
| 联调方式 | Vite 开发服务器代理 + DRF browsable API，前后端独立启动 |
2.2 Django 与 DRF
Django 负责工程组织与 ORM，DRF 提供序列化、视图集与权限体系。后端按业务域拆分为 accounts、labs、bookings、notifications、assistant 五个应用，每个应用内部保持 models / serializers / views / tests 的固定分层，接口统一以 /api/<domain>/ 前缀暴露。
2.3 Vue 3 与组件库
前端采用组合式 API 与 <script setup> 写法；Element Plus 提供表格、表单、日历等后台组件；ECharts 承担热力图、趋势折线与占比环形图；Pinia 管理登录态与用户信息，Vue Router 负责路由与守卫，axios 实例统一携带 token 与错误处理。
2.4 认证机制
采用 JWT 方案：登录成功后后端返回 access + refresh 令牌，前端将 access token 与用户信息存入 localStorage，axios 请求拦截器自动附加 Authorization: Bearer 头；路由守卫在导航前校验 token 与角色字段，管理员区域（/admin/*）仅 role=1 或超级用户可进入，学生访问会被重定向回首页，越权接口在后端再以 DRF 权限类兜底。
2.5 MySQL 8.4
选用 InnoDB 引擎以利用其事务与行级锁能力------这是冲突检测方案的数据层基础；字符集统一 utf8mb4 以兼容生僻字与 emoji；驱动使用纯 Python 的 PyMySQL，避免本机编译 mysqlclient 的依赖问题。
3 需求分析
3.1 可行性分析
技术可行性 ：Django + Vue 3 均为成熟主流技术，社区资料完备；大模型能力通过标准 HTTP 接口接入并可替换供应商，本地规则内核作为降级兜底，不依赖单一外部服务。经济可行性 ：全部组件开源免费，仅需一台可运行 MySQL 的普通 PC 即可完整部署演示。操作可行性：学生端基于浏览器完成全部操作，AI 助手支持自然语言交互，无需培训；管理端为常规表格化后台，管理员可快速上手。
3.2 功能需求
学生端：
- 注册、登录、忘记密码（手机号线索找回）；
- 浏览实验室列表与详情（位置、容量、设备）；
- 按日期与时段提交预约，冲突实时提示；
- 查看我的预约，支持取消与在窗口期内签到；
- 对待审批单发起催审批（2 小时内限催一次）；
- 查看实验室 × 时段占用热力图以错峰预约；
- 使用 AI 助手对话查询空档、诊断冲突、办理预约；
- 使用智能排期以自然语言描述需求并获取推荐方案；
- 接收审批结果等站内通知并标记已读；
- 维护个人资料、修改密码、查看个人使用统计。
管理端：
- 实验室与设备的增删改查、上下线管理；
- 预约审批（通过 / 驳回，驳回必填原因并自动释放时段）；
- 查看数据统计概览（今日预约、待审批、总量等指标卡）；
- 查看占用热力图与预约明细；
- 查看 AI 运营大屏：KPI、30 天趋势、预警事件与 AI 分析结论；
- 配置 AI 助手模型参数。
3.3 业务流程
主流程为：学生提交预约 → 系统执行参数校验与冲突检测（409 拦截）→ 生成待审批单并锁定时段 → 管理员审批 → 站内信通知学生 → 学生在实验开始前后签到窗口内签到 → 预约转为进行中 / 完成。旁路流程包括学生取消（释放时段）、管理员驳回（释放时段 + 通知）、催审批（通知全体管理员）。
3.4 非功能需求
- 并发安全：并发提交同一时段不得产生重复预约；
- 数据隔离：学生仅可见本人预约与通知，越权访问返回 404 而非 403，避免资源存在性泄露；
- 性能：常用列表接口响应在百毫秒级，统计接口允许秒级聚合；
- 可维护：后端按业务域分包，前端按视图分包，接口文档与部署文档随代码维护；
- 可用性：大模型不可用时 AI 功能自动降级为本地规则，核心链路不中断。
4 系统概要设计
4.1 系统架构
浏览器（Vue 3 SPA）
│ axios / JSON over HTTP
▼
Django REST Framework
├── accounts 认证与用户信息（JWT）
├── labs 实验室与设备 CRUD
├── bookings 预约 / 冲突检测 / 审批 / 签到 / 统计
├── notifications 站内通知
└── assistant AI 助手 / 智能排期 / 运营大屏
│ ORM
▼
MySQL 8.4（InnoDB，事务 + 行锁）4.2 功能结构
系统分为学生端与管理端两个功能区：学生端以"找实验室 → 约时段 → 查结果"为主线，叠加 AI 助手、智能排期与热力图三个智能入口；管理端以审批为核心，辅以资源维护、数据统计与 AI 运营大屏。
图 4-1 实验室列表界面（学生端）
图 4-2 实验室管理界面（管理端）
4.3 数据库设计
核心表包括：accounts_customuser（用户，含角色与状态字段）、labs_lab / labs_equipment（实验室与设备）、bookings_booking（预约，含状态机：待审批 → 已批准/已驳回 → 进行中 → 已完成/已取消）、notifications_notification（站内通知）、assistant 相关会话与配置表。预约表对（实验室， 日期， 时段）不建唯一索引------因为驳回释放后允许再次预约，唯一约束会误伤合法场景，故并发安全交由应用层冲突判定 + 行锁实现。详细 ER 图与字段说明见 docs/数据库设计.md。
4.4 核心机制设计
冲突检测与并发控制 ：采用半开区间语义 [start, end)，相邻时段（如前一段结束恰等于后一段开始）允许连续预约；检测条件为 start < exist.end AND end > exist.start，在事务内对目标实验室当日已有预约执行 select_for_update() 行锁，串行化并发提交：
python
with transaction.atomic():
qs = Booking.objects.select_for_update().filter(
lab=lab, date=date, status__in=PENDING_OR_APPROVED)
if any(s < end and e > start for s, e in
qs.values_list('start_time', 'end_time')):
raise Conflict409()AI 离线降级：assistant 模块将"意图识别与回答生成"抽象为可替换后端------优先调用可配置的大模型接口；接口超时或不可达时自动切换本地规则内核（关键词意图 + 模板回答 + 真实预约数据查询），保证断网环境下对话、排期推荐与运营分析仍可演示。
5 系统详细设计与实现
5.1 认证模块
登录页提供账号密码登录，注册页采集手机号与院系信息，忘记密码页通过手机号线索重置。登录成功后前端存储 JWT 与用户信息，路由守卫据此控制各区域访问。
图 5-1 登录界面
5.2 实验室浏览与预约模块（学生端）
实验室列表展示位置、容量、设备与开放状态；进入预约页选择日期与时段后，系统实时提示与已有预约（含待审批）重叠的时段，被占用时段不可提交。
图 5-2 预约实验室界面
5.3 我的预约模块（学生端）
列表按状态分组展示本人预约，提供取消、窗口期内签到、对待审批单催审批等操作；已完成记录计入个人使用统计。
图 5-3 我的预约界面
5.4 占用热力图模块（双端共用）
聚合预约数据生成"实验室 × 时段"占用率色阶矩阵，直观呈现高峰与低谷，学生据此错峰预约，管理员据此调整开放策略。
图 5-4 占用热力图界面
5.5 AI 助手模块（学生端）
多轮对话界面支持查询空档、诊断本人预约冲突、解答安全规范、一句话办理预约；回答由大模型生成，断网时自动切换本地规则内核，界面标注当前模型与运行模式。历史会话持久化，可回看与删除。
图 5-5 AI 助手对话界面
5.6 智能排期模块（学生端）
用户用自然语言描述需求（如"周三下午 3 小时，需要超净工作台"），系统解析时间、设备、资质等约束，检索满足条件的实验室并生成多套排期方案，每套方案附综合评分与推荐理由，经时间、设备、资质、安全四维校验后可直接一键转预约。
图 5-6 智能排期界面
5.7 站内通知模块
审批通过、驳回、催办等事件生成站内信，顶栏铃铛显示未读数，通知页支持单条已读与全部已读。
图 5-7 站内通知界面
5.8 预约审批模块（管理端）
待审批列表展示申请人、实验室、时段与事由，通过即生效并通知学生；驳回必须填写原因，驳回后时段立即释放并通知学生。
图 5-8 预约审批界面
5.9 数据统计模块（管理端）
指标卡呈现今日预约、待审批、通过/驳回/取消总量，配合趋势图与明细表，支撑日常运营决策。
图 5-9 后台数据统计界面
5.10 AI 运营大屏模块（管理端）
大屏聚合展示实验室总数、今日预约、待人工确认、今日 AI 请求数等 KPI，含近 30 天预约趋势、时段占用热力、AI 功能使用分布与实时预警（如爽约率超阈值），并由大模型生成利用率、爽约风险与错峰建议三段分析结论，支持一键生成 AI 运营报告。
图 5-10 AI 运营大屏界面
6 系统测试
6.1 测试目的与方法
采用两种方法验证：一是接口级单元测试，基于 DRF APITestCase 直连 MySQL 测试库，覆盖正常流与异常流；二是浏览器功能走查，按"登录 → 预约 → 审批 → 通知 → 签到"主流程在 Chrome 中逐步操作核对。
6.2 测试环境
| 项目 | 配置 |
|---|---|
| 操作系统 | Windows 11 |
| 后端 | Python 3.13 + Django 6.1 + DRF |
| 数据库 | MySQL 8.4（独立测试库） |
| 前端 | Vue 3 + Vite 6 |
| 浏览器 | Chrome 无头 / 有头 |
6.3 核心测试用例
| 编号 | 测试场景 | 预期结果 | 实测 |
|---|---|---|---|
| T01 | 正常提交不冲突预约 | 201 创建成功 | 通过 |
| T02 | 与已有预约部分重叠 | 409 冲突拦截 | 通过 |
| T03 | 相邻时段连约（end = start） | 允许提交 | 通过 |
| T04 | 驳回已通过的预约 | 时段释放，状态流转 | 通过 |
| T05 | 预约过去日期 / 过远日期 | 400 参数错误 | 通过 |
| T06 | 非开放时段 / 时长不足 | 400 参数错误 | 通过 |
| T07 | 取消他人预约 | 404 不可见即不可操作 | 通过 |
| T08 | 学生调用审批接口 | 403 权限拒绝 | 通过 |
| T09 | 未登录访问业务接口 | 401 未认证 | 通过 |
| T10 | 通过预约并触发通知 | 学生收到站内信 | 通过 |
| T11 | 重复审批同一预约 | 400 状态非法 | 通过 |
| T12 | 签到时间窗外签到 | 400 拒绝 | 通过 |
| T13 | 待审批状态签到 | 400 拒绝 | 通过 |
| T14 | 签到成功后重复签到 | 幂等，不产生异常 | 通过 |
| T15 | 越权查看他人通知 | 404 不可见 | 通过 |
上述用例分别验证了冲突判定（T02/T03）、参数校验（T05/T06）、权限与数据隔离（T07--T09/T15）、审批状态机（T10--T11）与签到窗口（T12--T14）五条设计约束。
6.4 专项验证
并发冲突实测 ：模拟两个请求并发提交同一实验室相同时段，后提交者被 409 拦截，数据库中仅存在一条有效记录------验证了行锁串行化方案在真实并发下的正确性（过程记录见 docs/数据库设计.md 第七节）。
AI 降级实测：断开外网后，AI 助手与智能排期自动切换本地规则内核，空档查询与排期推荐仍可返回基于真实预约数据的结果，界面标注降级模式。
6.5 测试结果
后端单元测试共 28 个用例，覆盖冲突 409、越权 404、签到窗口、审批通知、已完成流转等关键路径，全部通过；前端页面按学生与管理两种角色全流程走查，无死链、无样式错位、控制台无报错。
结 论
本系统完成了"基于 Django 与 Vue 3 的 AI 实验室智能预约系统"的设计与实现：在认证、预约、审批、签到、通知的完整业务闭环之上，叠加了 AI 对话助手、可解释智能排期与 AI 运营大屏三层智能能力。技术上，半开区间冲突判定结合行锁与事务保证了并发正确性，可替换的 AI 后端设计兼顾了大模型能力与离线可用性；28 个接口级单元测试与浏览器全流程走查为上述设计提供了验证。系统功能完整、可独立部署，可作为同类资源预约场景的参考实现。
需要源码的私信！