拓冰网站定制 
基于 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.4PyMySQL 驱动InnoDB 引擎联调方式Vite 开发服务器代理 DRF browsable API前后端独立启动2.2 Django 与 DRFDjango 负责工程组织与 ORMDRF 提供序列化、视图集与权限体系。后端按业务域拆分为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 方案登录成功后后端返回accessrefresh令牌前端将 access token 与用户信息存入 localStorageaxios 请求拦截器自动附加Authorization: Bearer头路由守卫在导航前校验 token 与角色字段管理员区域/admin/*仅role1或超级用户可进入学生访问会被重定向回首页越权接口在后端再以 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.4InnoDB事务 行锁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()行锁串行化并发提交withtransaction.atomic():qsBooking.objects.select_for_update().filter(lablab,datedate,status__inPENDING_OR_APPROVED)ifany(sendandestartfors,einqs.values_list(start_time,end_time)):raiseConflict409()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 测试目的与方法采用两种方法验证一是接口级单元测试基于 DRFAPITestCase直连 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 个接口级单元测试与浏览器全流程走查为上述设计提供了验证。系统功能完整、可独立部署可作为同类资源预约场景的参考实现。需要源码的私信 基于 Django 与 Vue 3 的 AI 实验室智能预约系统设计与实现
基于 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.4PyMySQL 驱动InnoDB 引擎联调方式Vite 开发服务器代理 DRF browsable API前后端独立启动2.2 Django 与 DRFDjango 负责工程组织与 ORMDRF 提供序列化、视图集与权限体系。后端按业务域拆分为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 方案登录成功后后端返回accessrefresh令牌前端将 access token 与用户信息存入 localStorageaxios 请求拦截器自动附加Authorization: Bearer头路由守卫在导航前校验 token 与角色字段管理员区域/admin/*仅role1或超级用户可进入学生访问会被重定向回首页越权接口在后端再以 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.4InnoDB事务 行锁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()行锁串行化并发提交withtransaction.atomic():qsBooking.objects.select_for_update().filter(lablab,datedate,status__inPENDING_OR_APPROVED)ifany(sendandestartfors,einqs.values_list(start_time,end_time)):raiseConflict409()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 测试目的与方法采用两种方法验证一是接口级单元测试基于 DRFAPITestCase直连 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 个接口级单元测试与浏览器全流程走查为上述设计提供了验证。系统功能完整、可独立部署可作为同类资源预约场景的参考实现。需要源码的私信