1绪论

1.1研究背景与意义

高校校园生活中的体育馆是师生进行体育锻炼和集体活动的场所，体育馆预约管理一直采用人工登记、打电话或者线下填写等传统的方式进行。该类操作是单向的滞后，信息传递慢，常常由于数据的割裂造成场地冲突、资源闲置、用户时间浪费等现象，师生不得不往返多次或者反复询问才有可能知道可选时间段[1]。伴随着校园信息化建设的发展，一些高校采用了早期的网站或者简单的查询系统，虽然信息的获取速度得到了一定的提高，但是数字化工具也开始介入到师生互动当中去，但是师生互动的形式仍然停留在单向查询的层面，碎片化的体验、预约状态的延迟、社交深度不足、优质用户生成内容无法沉淀、数据孤岛等状况仍然普遍存在[2]。现有的方式无法满足学生和老师对于即时性的、互动性的、个性化的、具有归属感的校园体育馆预约系统的要求，创建一个整合化、智能化的校园体育馆预约管理系统是提高校园服务品质的一个重要任务[3]。

本研究所建立的系统对校园体育服务的流程规范、用户参与质量、社区健康生态培养等方面都具有一定的推进价值，可以给类似垂直领域兴趣服务的整合提供可操作的借鉴范例。

1.2国内外研究现状

1.2.1国内现状

目前国内对于预约系统的研究也已形成了一定程度的体系，各种各样的预约系统也应运而生。早期研究大多集中在图书馆自习室的预约、实验室设备的借阅等等上，技术实现主要是使用JSP、PHP这些传统的Web开发技术。近些年来由于前后端分离架构的普及，Spring Boot、Django这些企业级框架成了预约系统开发的主流手段。研究重心慢慢由基本的预约功能实现转向资源调度优化，用户行为分析等问题。国内学者在预约系统功能完备性及用户体验的设计上已有不少经验，为校园体育馆预约系统的设计给予重要的参照。

2024年刘清岗[4]用微信小程序的技术手段，对高校实验预约的审批环节展开优化，利用工作流引擎的预约申请方法，创建起带有分组分阶段特点的审批平台。该项研究突出数据安全和移动端便利的统一思想，它的多角色管理端弹性审批流程的设计可直接给本系统预约审核模块提供借鉴。2023年纪力[5]设计了基于Android的智慧场馆自动分配预约系统，系统分为用户端和管理员端两部分，用户通过手机查看场馆信息并进行预约。本文采用MySQL数据库存储业务数据，场馆信息展示和位置导航功能的设计思路给本系统场馆信息模块提供借鉴。2023年桑冉航、李晓明[6]利用Spring Boot框架搭建了健身房管理系统，包含用户管理、课程管理、器材管理等主要功能模块，在实际使用中证明了该系统的使用效率较高，可以很大程度上减少管理人员的工作量。该研究对于系统功能模块的划分方式和管理端的数据管理思路，可以给本系统的开发提供一定的参考。

1.2.2国外现状

国外有关领域更多是从资源调度优化、数据驱动决策机制等角度出发的研究。Zhuang[7]等人就预约系统里的随机到达用户资源分配问题给出基于随机动态规划的最优动态资源分配方案，从理论上表现出了预约调度同资源分配的结构特点。Ying[8]等人把机器学习同优化办法融合起来，创建起多预约患者调度体系，利用神经网络来预估用户爽约的概率以及个性化的预约时长，从而给予超订策略一定的决定性支撑。Strategic Direction[9]期刊的整合性研究是从商业模式的角度出发，探究数字化预约系统怎样促使企业实现循环经济，突出系统在削减浪费和激发革新方面的商业好处。欧洲足球俱乐部的官方应用、Fantasy Premier League等平台已经实现了数据驱动的实时互动和社群运营，Bleacher Report、SofaScore等平台用社交属性和深度数据相结合的方式，形成了一种高度粘合的预约内容生态系统，给校园体育馆预约系统用户行为分析、动态调度等带来很多参考，而对预约系统资源调度优化方面的研究就更多了，研究视角更多地走向了运筹学和管理科学之间的相互交融。学者们所关注的主要问题是动态资源分配、预约调度策略和不确定的环境下做出决策优化。Zhuang等人的研究集中于在多设施环境里安排预约调度与资源分配相结合的集成决策问题上，提出用随机动态规划的方式来表示序贯调度分配的方法，并且给出了价值函数反多模性特征所表现出来的最优动态资源分配策略。该项研究给预约系统中处理各个优先级用户资源分配问题赋予了理论依据。Ying等人将机器学习和优化方法结合起来，创建了多预约患者调度系统，用人工神经网络算失约概率及个性化预约时间，在此基础上创建优化模型做排程决定。该项研究证明了数据驱动的方法可以用于预约调度方面。还有学者探究了数字预约系统同商业模式融合的途径，认为预约系统可以减少企业的资源浪费，并且促使企业进行服务的革新。国外研究在算法上具有较高的理论深度，但是对于校园体育馆这样的特定场景关注较少，本文会将吸收其中的调度优化思想，并结合校园的实际需求来进行功能的设计。

1.3主要研究内容

本课题以基于Python的校园体育馆预约管理系统为中心展开研究，系统整体面向高校师生提供场馆查询、预约、管理、反馈一体化服务，包含普通用户和管理员两种主要角色，普通用户用学号或者工号注册登录之后可以查看场馆介绍及可预约时段，提交预约申请并管理个人预约记录，支持取消预约、收藏常用场馆、提交使用反馈，管理员对场馆信息进行维护、预约审核、用户管理、数据看板查看，能够按照场馆类型、日期、时段等维度筛选以及预约趋势统计分析，系统采用前后端分离架构和B/S模式，使用Python语言、Django框架、MySQL数据库作为技术基础，完成从需求分析、总体架构设计、功能模块设计、数据库设计到系统实现和测试的整个开发过程，解决传统场馆预约中存在信息不对称、资源调度滞后、人工管理效率低下的主要问题。

2相关技术介绍

2.1Django框架

Django是一个高级的Python Web框架，它用MTV模式把数据模型、业务逻辑和界面呈现很好地分开[10]。该框架自带了对象关系映射模块，开发者使用Python类来定义数据表结构，框架就会自行完成SQL语句的生成和执行。该机制大幅度减少数据库操作代码编写量，也大大降低由于手动编写SQL所造成的注入风险。Django也自带了自动生成的管理后台，只需要注册数据模型就可以得到完整的增删改查界面，特别适合于系统原型开发使用。本系统使用Django做后端的核心框架，用ORM模块对场馆信息、预约记录、用户数据等持久化对象进行存储和检索。Django中间件负责请求拦截、认证工作，配合使用OAuth2.0协议可以达到对用户权限精细化控制的目的。系统运行的时候，每个预约请求都会被好几处中间件进行处理，使整个django请求响应的流程不会偏离业务逻辑。李磊在其著作里系统论述了Java EE企业级应用开发的全过程方法，而其中有关MVC架构模式和业务逻辑分层的内容，也给人们认识Django框架的设计思路提供了一定的借鉴意义[11]。

2.2Vue前端框架

Vue是一个渐进式的JavaScript框架，主要用以构建用户界面，它的核心库只关注视图层，使用响应式的数据绑定以及组件化的方式来提高前端开发的效率[12]。该框架使用虚拟DOM技术来减少直接对真实DOM进行修改造成的性能损失，当数据状态发生改变的时候，Vue可以快速算出需要更新的节点区域。双向数据绑定使表单的输入和数据的状态得到同步，只需要管理数据模型，界面就会自动地完成更新。本系统前端使用Vue框架来搭建一个单页面应用，在不同的功能模块之间切换的时候不需要重新加载整个页面，操作体验像原生应用一样。场馆信息展示、预约表单提交、评论列表渲染这些交互场景都依靠Vue的组件系统来达成模块化开发[13]。前端用ajax请求调用后端的restful接口，返回的json数据直接驱动视图的更新。王子豪等针对Vue云管理平台的Web前端性能优化做了详细的探究，并给出相应的解决方案以及实践指南。谢振华用vue和spring boot进行教学系统的设计，证明该技术栈适合做企业级的应用开发。

2.3MySQL数据库

MySQL属于开源的关系型数据库管理系统，对web应用的开发有较大影响。该数据库采用多存储引擎的结构，在InnoDB引擎中包含了事务处理、行级锁、外键约束这些企业级别的特性。SQL查询优化器依靠统计信息来挑选出最好的执行计划，索引机制使得数据检索操作变得迅速。MySQL对于读写混合负载有较好的稳定性，适合预约管理系统这样的经常执行查询和写入的应用场景[14]。本系统使用MySQL进行核心业务数据的存储，即用户的账户信息、场馆的档案数据、预约的订单信息、取消的历史轨迹等都在这里。预约时段冲突检测功能需要数据库的查询能力，系统在用户提交预约申请的时候，对同一时间段内同一个场馆的预约情况进行检查。事务机制保证预约创建和库存扣减两个操作是一致的，不会出现超约的情况。郑晓霞等人的详细介绍中包含了MySQL数据库原理以及应用技巧，其有关索引的设计和查询优化的相关内容给本系统数据库性能的调节赋予了理论支撑。李锡辉的教材系统介绍了在MySQL项目开发过程中要采取的一些实践方法，可以给数据表结构的设计提供一定的借鉴[15]。

3系统分析

3.1可行性分析

3.1.1技术可行性

Django框架和Vue前端技术栈都有成熟的生态系统以及完善的文档支持，在开发过程中出现的技术问题可以很快得到解决。Python语言很多开源的第三方库可以降低对OAuth2.0认证、JWT生成和验证、Redis缓存的操作实现难度。MySQL数据库对于数据量较小的场景来说可以稳定运行，本系统的用户数以及并发数量都在MySQL可以承担的范围内。各项技术兼容性好，Django的REST框架可以和Vue前端很好地配合起来，技术选择没有大的风险。

3.1.2经济可行性

系统开发所需要的所有软件工具都是开源或者免费的，Django、MySQL、Redis、Node.js这些主要组件都不用支付授权费用。硬件方面可以利用普通的个人计算机来完成系统的开发以及运行，并不需要专门的服务器设备。系统上线之后可以部署在校园网内部服务器上，运维成本主要是数据库备份以及日常巡检。相对于人工管理而言，在长期的运用中，信息系统所具有的经济价值会降低使用成本，经济上比较可行。

3.1.3操作可行性

用户端界面以日常使用习惯为依据设计，预约流程参考电商购票方式，学生可以不用特别培训就可以使用。管理员端的功能入口按照管理职责进行分类，场馆管理、预约审核、反馈处理等模块分得清楚。系统给出直接的状态提示信息，预约成功或者失败的时候用户可以知道结果。移动端浏览器经过适配之后依然可以正常访问，大大降低了使用门槛。

3.2功能需求分析

UML用例图是用图形化的方式来表达系统功能需求的一种工具，它通过对系统同外部参与者间交互关系的表示来确定系统所具有的功能。用例图用用例来表示系统能执行的特定功能，参与者表示和系统交互的各类用户或者外部系统。用例图可以用于分析、设计阶段，使开发者同客户取得一致意见，保证系统的完整、正确地实现功能。借助直观的图示，UML用例图把系统功能同角色形成起来，从而得到清晰的映射。本文将系统按照角色模块进行需求分析。

3.2.1用户角色功能需求

注册用户登录系统之后可以查询场馆信息、查看场地详情、提交预约申请。用户可以收藏自己感兴趣的场馆，也可以为自己所做项目的星级打分。预约成功后用户可以查看自己的预约记录，在需要的时候提交取消申请。用户可以向管理员反馈在使用过程中出现的各种问题，也可以查看历史反馈处理情况。评论模块可以给场馆留言，自己也可以删除自己发出的评论。

图3-1 用户用例图

3.2.2管理员角色功能需求

管理员对场馆类型以及场馆信息做完整的设置工作，即对场馆的基本属性、开放时间、预约限制等进行参数设置。预约信息管理模块能够显示所有预约申请，还可以对已经提交的预约申请执行批准或者驳回的操作。取消记录模块会记录下所有用户的取消行为，管理员也可以对历史数据进行查询。反馈建议模块可以供管理员对用户的提问作出回答，也可以删除不合适的反馈。网站公告管理功能是用来发布系统通知和临时调整信息的。

图3-2 管理员用例图

3.3非功能需求分析

3.3.1可用性需求

系统可用性的基本要求就是系统具备高可用性架构，在用户高并发的情况下保持系统的稳定运行。系统应当具有快速恢复能力，在发生故障的时候能够自行完成修复工作。为了保证用户体验，系统需要有较高的响应速度、低的延迟，在短的时间内对用户的请求做出处理，并且可以很快地给出结果。系统应该具有负载均衡的功能，在多个服务器之间分发请求，防止由于某一个节点出现故障而造成整个系统的瘫痪。

3.3.2可靠性需求

系统的可靠性是指系统能够长时间正常工作，不会因为一些故障或者中断而停止运行。系统要建立完备的数据备份和恢复系统，在出现硬件损坏或者重大事故的时候，保证数据不会消失，而且可以快速地重新开始工作。系统中的各项服务、组件要有容错性，在一部分组件出现问题的时候，可以自动切换到备用服务上。

3.3.3安全性需求

系统的安全要件就是对用户的信息，交易的纪录以及其他重要的数据加以严防。系统需要使用加密的方式对用户的传递过来的数据加以保护，以免造成传输过程中的数据泄露或者被人修改。系统要对用户的访问进行控制，只允许授权用户访问指定的资源，不能让未经授权的用户访问系统。系统还需要有身份认证的功能来阻止不法之徒假扮别人的名义进行操作。为了防止外界的攻击，系统应该设有防火墙以及入侵检测系统这些安全防范手段，以此来保证系统不会遭遇网络的威胁。

4系统设计

4.1系统架构设计

本系统采用前后端分离的分层架构模式，将用户界面、业务逻辑与数据存储三个关注点进行解耦。用户界面层由Vue框架构建的单页面应用负责，处理页面渲染与用户交互事件。应用服务层基于Django框架实现，通过RESTful接口对外提供业务能力，包括预约申请处理、场馆信息查询、权限验证等核心逻辑。数据持久层利用Django ORM完成对象关系映射，将业务实体转换为数据库记录[16]。系统支持层包括MySQL关系数据库与Redis缓存服务，前者保障数据持久化存储，后者用于临时令牌管理与热点数据缓存。各层之间通过明确定义的接口进行通信，上层依赖下层的服务能力而不关心具体实现细节。这种分层设计提升了代码的可维护性，当某一层内部逻辑需要调整时不会波及其他层次。整个系统架构如图4-1所示。

图4-1 系统架构图

4.2系统结构功能设计

系统围绕两类用户角色组织功能模块，形成清晰的权限边界。注册用户可访问场馆浏览与预约操作相关功能，包括场馆信息查询、场馆详情展示、点赞与收藏互动、评论发布与管理、预约申请提交、预约记录查看、取消记录查询、反馈建议提交。管理员角色拥有更广泛的管理权限，涵盖场馆类型配置、场馆信息维护、预约申请批量审核、取消记录监控、反馈建议处理、网站公告发布。两类角色的功能集合相互独立又通过预约流程产生关联，用户提交的预约申请需要经过管理员审核才能生效。系统功能结构图如图4-2所示。

图4-2 系统功能结构图

4.3系统流程设计

4.3.1场馆预约功能流程设计

用户发起场馆预约请求后，系统首先校验用户的登录状态，未登录用户将被重定向至身份认证页面。通过身份验证的用户进入场馆信息浏览页面，选择目标场馆后提交预约申请，系统判断所选时段的场馆可用状态，若时段冲突则提示用户重新选择，若时段可用则生成待审核预约记录并通知管理员处理。场馆预约流程图如图4-3所示。

图4-3 场馆预约流程图

4.3.2预约审核功能流程设计

管理员登录系统后进入预约信息管理模块，系统加载全部待审核预约记录列表。管理员逐条或批量选择待审核记录，查看预约详情后判断是否符合审核通过条件，条件满足时将预约状态更新为已通过并触发用户通知，条件不满足时则标记为拒绝状态，系统记录操作结果并更新数据库中对应预约记录的审核状态字段。预约审核流程图如图4-4所示。

图4-4 预约审核流程图

4.3.3反馈建议提交功能流程设计

用户进入反馈建议模块后，系统展示历史反馈列表并提供新增入口。用户填写反馈内容后提交，系统对提交内容进行非空校验，校验不通过时返回错误提示要求用户补全内容，校验通过后将反馈记录写入数据库并在列表中实时刷新显示。用户可对自身提交的历史反馈执行删除操作，系统确认删除指令后从数据库中移除对应记录。反馈建议提交流程图如图4-5所示。

图4-5 反馈建议提交流程图

4.3.4场馆信息管理功能流程设计

管理员进入场馆信息管理模块后，系统加载当前全部场馆数据列表。管理员可选择新增场馆信息，填写场馆名称、类型、容量等基础字段后提交，系统校验必填字段完整性，校验通过后将新增记录持久化存储；对已有记录可执行编辑操作，修改内容保存后同步更新数据库；管理员亦可查看场馆下的用户评论内容，并对不合规评论执行删除处理。场馆信息管理流程图如图4-6所示。

图4-6 场馆信息管理流程图

4.3.5公告管理功能流程设计

管理员在网站公告管理模块中可发布、查询与删除公告内容。发布流程要求管理员填写公告标题与正文内容，系统对标题非空状态进行校验，校验不通过则返回提示，校验通过后将公告记录写入数据库并在前台公告列表同步展示。查询操作支持按关键词条件筛选公告列表，管理员对历史公告可执行删除操作，删除确认后系统从数据库移除对应记录并刷新列表视图。公告管理流程图如图4-7所示。

图4-7 公告管理流程图

4.4数据库设计

在数据库设计过程中，E-R图设计有助于将概念模型转化为具体的数据库结构。在此阶段，需要明确每个数据表的字段类型、约束条件及表之间的关系，为物理设计提供依据。随后，将进一步分析优化数据存储方案，保障系统的高效性与可扩展性[17]。

4.4.1E-R图设计

概念模型设计阶段的任务是将现实世界中的业务对象转换为信息世界的实体及其联系。体育馆预约管理系统涉及的核心业务对象包括用户、场馆、预约、取消记录、反馈等实体，这些实体之间存在明确的数据依赖关系。一个用户可以提交多条预约申请，一条预约申请归属于唯一的用户，用户与预约之间构成一对多联系。每个预约对应一个具体的场馆，每个场馆可以接收多条预约，场馆与预约之间同样是一对多联系。取消记录与预约相关联，每条取消记录源自一条已存在的预约订单。反馈建议由用户提交，用户与反馈之间形成一对多联系。场馆类型与场馆之间也存在一对多关系，一个类型下可以包含多个场馆。这种实体联系结构完整刻画了预约业务的数据流转路径。基于上述分析，绘制系统全局E-R图以可视化方式展示主要实体及其关联关系，为后续逻辑模型设计提供依据。周晓玉等人探讨了基于Web技术的数据库应用系统设计方法，其中关于实体关系建模的论述对本节工作具有指导价值。系统全局E-R图如图4-8所示。

图4-8 系统E-R图

根据系统分析，系统的主要实体有：用户信息、场馆类型、场馆信息、预约信息、取消记录、反馈建议、评论信息、点赞记录、收藏记录、网站公告，各个实体具体的属性如下图所示。

（1）注册用户实体主要包括注册用户id、用户姓名、用户性别、用户手机、审核状态、用户id等属性。如图4-9所示。

图4-9 注册用户实体属性图

（2）场馆类型实体主要包括场馆类型id、类型名称、创建时间、创建用户id等属性。如图4-10所示。

图4-10 场馆类型实体属性图

（3）场馆信息实体主要包括场馆信息id、场馆编号、场馆名称、场馆海报、场馆类型、场馆介绍、点击数等属性。如图4-11所示。

图4-11 场馆信息实体属性图

（4）预约信息实体主要包括预约信息id、注册用户、用户姓名、用户手机、场馆编号、场馆名称、场馆类型、预约单号等属性。如图4-12所示。

图4-12 预约信息实体属性图

（5）取消记录实体主要包括取消记录id、注册用户、用户姓名、用户手机、场馆编号、场馆名称、场馆类型、预约单号等属性。如图4-13所示。

图4-13 取消记录实体属性图

（6）反馈建议实体主要包括反馈建议id、反馈用户、用户姓名、用户手机、反馈类型、反馈内容、处理状态等属性。如图4-14所示。

图4-14 反馈建议实体属性图

（7）评论实体主要包括评论id、用户id、回复评论id、内容、昵称、头像地址、创建时间等属性。如图4-15所示。

图4-15 评论实体属性图

（8）点赞记录实体主要包括点赞记录id、用户信息id、场馆信息id、点赞时间等属性。如图4-16所示。

图4-16 点赞记录实体属性图

（9）收藏记录实体主要包括收藏记录id、用户信息id、场馆信息id、收藏时间等属性。如图4-17所示。

图4-17 收藏记录实体属性图

（10）网站公告实体主要包括公告id、标题、正文、创建时间、更新时间等属性。如图4-18所示。

图4-18 网站公告实体属性图

4.4.2数据库表设计

数据库表设计是根据业务需求，确定数据库表的结构、字段类型及其关系。通过规范化设计，保证数据的完整性、一致性与效率，同时避免冗余数据，并为后续的数据查询、存储和维护提供清晰的框架[18]。以下是系统的数据库表设计展示。

（1）注册用户表主要是用来存储系统中已完成注册的用户的详细信息。主要包括用户姓名、用户性别、用户手机、审核状态等字段。如表4-1所示。

表4-1 注册用户表

序号	字段名	类型	长度	备注
1	registered_user_id	int	11	注册用户id
2	user_name	varchar	50	用户姓名
3	user_gender	varchar	10	用户性别
4	users_mobile_phone	varchar	20	用户手机
5	examine_state	varchar	16	审核状态
6	user_id	int	11	用户id
7	create_time	datetime	-	创建时间
8	update_time	timestamp	-	更新时间

（2）场馆类型表主要是用来对体育馆进行分类管理，便于用户按类别筛选场地。主要包括类型名称、创建时间等字段。如表4-2所示。

表4-2 场馆类型表

序号	字段名	类型	长度	备注
1	venue_type_id	int	11	场馆类型id
2	type_name	varchar	64	类型名称
3	create_time	datetime	-	创建时间
4	create_by	int	11	创建用户id
5	update_time	timestamp	-	更新时间

（3）场馆信息表主要是用来存储体育馆的基本档案数据，供用户查询与预约使用。主要包括场馆编号、场馆名称、场馆类型、场馆介绍等字段。如表4-3所示。

表4-3 场馆信息表

序号	字段名	类型	长度	备注
1	venue_information_id	int	11	场馆信息id
2	venue_number	varchar	64	场馆编号
3	venue_name	varchar	64	场馆名称
4	venue_poster	varchar	255	场馆海报
5	venue_type	varchar	64	场馆类型
6	venue_introduction	longtext	4294967295	场馆介绍
7	hits	int	11	点击数
8	praise_len	int	11	点赞数
9	examine_state	varchar	16	审核状态
10	create_time	datetime	-	创建时间
11	update_time	timestamp	-	更新时间

（4）预约信息表主要是用来记录用户提交的每一次预约申请及其审核结果。主要包括用户姓名、用户手机、场馆名称、预约日期等字段。如表4-4所示。

表4-4 预约信息表

序号	字段名	类型	长度	备注
1	reservation_information_id	int	11	预约信息id
2	registered_user	int	11	注册用户
3	user_name	varchar	64	用户姓名
4	users_mobile_phone	varchar	64	用户手机
5	venue_number	varchar	64	场馆编号
6	venue_name	varchar	64	场馆名称
7	reservation_order_number	varchar	64	预约单号
8	appointment_date	date	-	预约日期
9	appointment_period	varchar	64	预约时段
10	appointment_status	varchar	64	预约状态
11	examine_state	varchar	16	审核状态
12	create_time	datetime	-	创建时间

（5）取消记录表主要是用来存储用户取消预约的操作轨迹，用于统计分析与管理监控。主要包括用户姓名、预约单号、取消日期、取消原因等字段。如表4-5所示。

表4-5 取消记录表

序号	字段名	类型	长度	备注
1	cancel_record_id	int	11	取消记录id
2	registered_user	int	11	注册用户
3	user_name	varchar	64	用户姓名
4	venue_name	varchar	64	场馆名称
5	reservation_order_number	varchar	64	预约单号
6	appointment_date	date	-	预约日期
7	appointment_period	varchar	64	预约时段
8	cancel_date	date	-	取消日期
9	cancellation_reason	text	65535	取消原因
10	create_time	datetime	-	创建时间

（6）反馈建议表主要是用来收集用户对场馆服务或系统功能的意见与建议。主要包括反馈用户、反馈类型、反馈内容、处理状态等字段。如表4-6所示。

表4-6 反馈建议表

序号	字段名	类型	长度	备注
1	feedback_and_suggestions_id	int	11	反馈建议id
2	feedback_user	int	11	反馈用户
3	user_name	varchar	64	用户姓名
4	type_of_feedback	varchar	64	反馈类型
5	feedback_content	text	65535	反馈内容
6	processing_status	varchar	64	处理状态
7	handling_reply	text	65535	处理回复
8	create_time	datetime	-	创建时间

（7）评论表主要是用来存储用户对场馆的评价内容，供其他用户参考。主要包括用户id、内容、昵称、来源id等字段。如表4-7所示。

表4-7 评论表

序号	字段名	类型	长度	备注
1	comment_id	int	11	评论id
2	user_id	int	11	用户id
3	content	longtext	4294967295	内容
4	nickname	varchar	255	昵称
5	source_id	int	11	来源id
6	create_time	timestamp	-	创建时间
7	hidden	tinyint	4	是否隐藏
8	sticky	tinyint	4	是否置顶

（8）用户账户表主要是用来存储系统登录账户的认证信息与基本状态。主要包括用户名、密码、账户状态、手机号码等字段。如表4-8所示。

表4-8 用户账户表

序号	字段名	类型	长度	备注
1	user_id	int	11	用户id
2	state	smallint	6	账户状态
3	user_group	varchar	32	所在用户组
4	username	varchar	30	用户名
5	password	varchar	64	密码
6	phone	varchar	20	手机号码
7	email	varchar	64	邮箱
8	create_time	timestamp	-	创建时间

（9）预约时段表主要是用来定义场馆可预约的时间区间，供预约功能选择使用。主要包括时段范围、创建时间等字段。如表4-9所示。

表4-9 预约时段表

序号	字段名	类型	长度	备注
1	appointment_period_id	int	11	预约时段id
2	period_range	varchar	64	时段范围
3	create_time	datetime	-	创建时间
4	create_by	int	11	创建用户id
5	update_time	timestamp	-	更新时间

（10）网站公告表主要是用来存储管理员发布的系统通知内容，向用户传达重要信息。主要包括标题、正文、创建时间等字段。如表4-10所示。

表4-10 网站公告表

序号	字段名	类型	长度	备注
1	notice_id	mediumint	7	公告id
2	title	varchar	125	标题
3	content	longtext	4294967295	正文
4	create_time	timestamp	-	创建时间
5	update_time	timestamp	-	更新时间

5系统实现

5.1用户角色功能实现

5.1.1场馆信息查询

用户进入系统首页后能够查看场馆列表，列表按照场馆类型进行分类展示。系统根据用户当前所在位置或默认排序规则组织场馆显示顺序。用户可以在搜索框中输入场馆名称关键词进行模糊匹配，系统返回符合条件的场馆结果。点击任意场馆卡片后跳转至详情页面，页面顶部展示场馆轮播图与基本信息。详情页中部区域加载场馆介绍文本与设施说明，底部展示其他用户的评论内容。场馆信息查询界面如图5-1所示。

图5-1 场馆信息查询界面

5.1.2场馆预约

用户在详情页面选择预约日期后系统加载该日期的可预约时段列表。时段列表区分空闲时段与已满时段，空闲时段高亮显示可供选择。用户点击预约时段后进入信息确认页面，系统展示所选场馆与时段的具体信息。用户确认无误后提交预约申请，系统校验用户当日预约次数是否超出限制。通过校验的申请进入待审核队列，系统返回提交成功提示。场馆预约界面如图5-2所示。

图5-2 场馆预约界面

5.1.3预约取消

用户在预约记录页面找到需要取消的预约订单，点击取消按钮触发取消申请流程。系统弹出取消原因输入窗口，用户填写原因后提交取消请求。系统校验当前时间是否在允许取消的时间窗口内，超出时限的请求被拒绝并提示联系管理员。通过校验的取消操作将更新预约状态为已取消，同时释放对应时段的场馆容量。预约取消界面如图5-3所示。

图5-3 预约取消界面

5.1.4评论管理

用户在场馆详情页面底部可查看其他用户的评论内容，评论按照创建时间倒序排列。登录用户可在评论输入框中填写评价内容，提交后系统将评论与该用户账户关联保存。用户只能删除自己发表的评论，每条评论右侧显示删除按钮。管理员在管理端可以删除任意评论，置顶优秀评论。评论管理界面如图5-4所示。

图5-4评论管理界面

5.1.5反馈建议提交

用户在个人中心点击反馈建议菜单进入反馈页面，页面展示历史反馈记录列表。用户点击新增反馈按钮后填写反馈类型与详细内容，提交后系统生成状态为待处理的反馈记录。管理员回复后用户可以在列表中看到处理状态变更为已回复，点击详情查看管理员回复内容。用户可删除自己提交且尚未被管理员回复的反馈记录。反馈建议界面如图5-5所示。

图5-5 反馈建议界面

5.2管理员角色功能实现

5.2.1场馆类型管理

管理员进入场馆类型管理页面后查看已配置的类型列表，列表展示类型名称与创建时间。点击新增按钮弹出表单窗口，管理员填写类型名称后提交保存。编辑类型时支持修改类型名称，删除类型前系统检查该类型下是否关联场馆。存在关联场馆时系统阻止删除操作并提示先处理关联场馆。场馆类型管理界面如图5-6所示。

图5-6 场馆类型管理界面

5.2.2场馆信息管理

管理员在场馆信息管理页面查看所有场馆的完整列表，列表包含场馆编号、名称、类型、审核状态等字段。新增场馆时需要填写场馆名称、选择所属类型、上传场馆海报、编写场馆介绍。编辑场馆信息后场馆状态重置为待审核，审核通过后变更内容在前端生效。删除场馆操作需要二次确认，确认后系统同步删除该场馆的所有关联预约记录。场馆信息管理界面如图5-7所示。

图5-7 场馆信息管理界面

5.2.3预约信息审核

管理员进入预约信息管理页面后系统按提交时间倒序列出全部预约申请。页面顶部提供筛选器，支持按审核状态、预约日期、场馆名称组合筛选。管理员点击记录行的审核按钮弹出审核窗口，窗口展示预约详情与用户信息。批准预约时系统自动检查时段容量，容量充足则更新状态为已通过。驳回预约时需要填写驳回理由，理由将随系统消息发送给用户。预约信息审核界面如图5-8所示。

图5-8 预约信息审核界面

5.2.4取消记录监控

管理员进入取消记录管理页面后查看全部取消操作的历史记录。列表展示取消时间、用户姓名、场馆名称、预约日期、取消原因等信息。页面提供按日期范围与用户姓名的组合筛选功能。管理员可点击查看单条记录的完整详情，包括取消申请时的完整上下文信息。取消记录仅用于统计分析与管理监控，管理员无权修改或删除记录。取消记录监控界面如图5-9所示。

图5-9取消记录监控界面

5.2.5反馈建议处理

管理员进入反馈建议管理页面后系统按提交时间倒序列出所有反馈记录。页面提供按处理状态筛选的功能，未处理的反馈记录高亮显示。管理员点击处理按钮后查看反馈内容详情，在回复输入框中填写处理意见。提交回复后系统将处理状态更新为已回复，用户端可查看回复内容。对于恶意或不当反馈，管理员可直接删除。反馈建议处理界面如图5-10所示。

图5-10反馈建议处理界面

5.2.6网站公告管理

管理员进入公告管理页面后查看已发布的公告列表，列表按创建时间倒序排列。点击新增公告按钮后填写标题与正文内容，提交后公告立即在用户端首页置顶展示。编辑已发布的公告时系统更新最后修改时间，用户端显示更新后的内容。删除公告操作需要二次确认，删除后公告从用户端消失。网站公告管理界面如图5-11所示。

图5-11网站公告管理界面

6系统测试

6.1测试目的

测试目的主要是通过系统测试和验证，使软件或系统符合设计需求和功能要求，能够稳定、安全地运行。具体来说，测试的目的是发现并修复潜在的缺陷或问题，提高系统的质量和性能，减少在实际使用中的故障率。通过各种测试手段，如单元测试、集成测试、功能测试、性能测试等，软件在不同环境下的兼容性和可用性。测试还帮助确认系统的安全性，防止数据泄露、系统崩溃等风险问题。通过全面的测试，提升用户体验的顺畅，提升客户满意度，减少开发后的维护成本。因此，测试过程不仅是软件开发的重要一环，也是保障软件产品质量、满足用户需求的关键步骤。

6.2测试方法

测试方法是保障软件或系统质量的重要手段，通常根据测试目标和需求的不同，选择不同的测试策略。常见的测试方法包括黑盒测试、白盒测试、灰盒测试、回归测试和性能测试[19] 。

黑盒测试关注软件的功能表现，而非其内部结构。测试人员通过输入数据并观察输出结果来验证软件是否符合预期需求，适用于功能验证和接口测试。白盒测试则侧重于系统内部结构的验证，测试人员基于对代码的了解，进行详细的逻辑、控制流和数据流的测试，代码的每个路径和语句都被有效地覆盖，帮助发现潜在的逻辑错误或性能瓶颈。灰盒测试结合了黑盒和白盒测试的优点，测试人员在部分了解系统内部结构的基础上，既关注系统的功能，也关注其安全性和集成性。

回归测试是在软件进行修改或更新后，重新测试已完成的功能，新版本没有引入新的缺陷或问题。性能测试则主要评估系统在不同负载和压力下的表现，检查响应时间、并发处理能力等关键性能指标。

通过采用这些测试方法，可以有效评估和改进软件的功能、性能和稳定性，最终交付的系统满足用户需求，提升软件质量。

6.3测试内容

场馆信息模块的测试目标是验证场馆数据的增删改查功能是否正常工作，重点关注数据完整性约束与权限控制。该模块测试用例围绕新增场馆的数据完整性校验、编辑场馆的审核流程验证、删除操作的关联检查以及重复编号的冲突检测展开。表6-1展示了场馆信息模块的详细测试用例。

表6-1 场馆信息模块测试用例表

测试内容	测试步骤	预期结果	实际结果
新增场馆	填写完整场馆信息后提交	系统生成场馆记录并进入待审核状态	符合预期
编辑场馆	修改场馆名称后提交审核	审核通过后前端显示更新后的名称	符合预期
删除场馆	选择无预约记录的场馆执行删除	场馆记录从列表中移除	符合预期
重复编号	使用已存在的场馆编号新增场馆	系统提示编号已存在拒绝保存	符合预期

预约流程模块的测试覆盖从预约提交到审核完成的完整链路，验证时段冲突检测逻辑的正确性以及容量控制机制的有效性。测试用例涵盖正常预约流程、同一用户的时段冲突场景、场馆容量超限场景以及单日预约次数限制场景。表6-2展示了预约流程模块的详细测试用例。

表6-2 预约流程模块测试用例表

测试内容	测试步骤	预期结果	实际结果
正常预约	选择空闲时段提交预约申请	生成待审核预约记录	符合预期
时段冲突	同一用户重复预约同一时段	系统提示已存在预约拒绝提交	符合预期
容量超限	预约申请超过场馆容量限制	系统提示容量已满预约失败	符合预期
次数限制	单日预约次数超过设定上限	系统提示超出当日预约次数	符合预期

取消流程模块的测试关注取消时限控制与容量恢复机制，确保用户无法在截止时间后取消预约且取消后资源能够正确释放。测试用例包括正常取消操作、超出取消时限的拒绝处理、取消成功后场馆容量的恢复验证以及取消记录的生成检查。表6-3展示了取消流程模块的详细测试用例。

表6-3 取消流程模块测试用例表

测试内容	测试步骤	预期结果	实际结果
正常取消	在允许时限内提交取消申请	预约状态更新为已取消	符合预期
超时取消	超出取消时限后尝试取消	系统拒绝取消并提示联系管理员	符合预期
容量恢复	取消成功后查询场馆时段	被取消时段容量恢复为可用	符合预期
取消记录	取消操作完成后查询取消记录表	生成对应的取消记录条目	符合预期

权限管理模块的测试验证用户与管理员的接口访问权限是否严格隔离，未授权请求应当被正确拒绝。测试用例包括未登录用户访问受限页面的重定向验证、普通用户越权访问管理端接口的拒绝机制、JWT令牌过期后的重新认证要求以及不同角色登录后菜单加载的正确性。表6-4展示了权限管理模块的详细测试用例。

表6-4 权限管理模块测试用例表

测试内容	测试步骤	预期结果	实际结果
未登录访问	未登录状态下访问预约页面	系统重定向至登录页面	符合预期
用户越权	普通用户访问管理端接口	系统返回无权限错误	符合预期
令牌过期	使用过期的JWT令牌请求接口	系统返回令牌失效需重新登录	符合预期
角色切换	管理员使用用户端登录	系统识别角色加载对应菜单	符合预期

反馈处理模块的测试验证用户提交反馈后管理员能够收到通知并完成回复，同时确保用户能够查看回复内容。测试用例包括用户提交反馈的记录生成、管理员回复后的状态更新、用户查看回复内容的正确显示以及用户删除未回复反馈记录的功能。表6-5展示了反馈处理模块的详细测试用例。

表6-5 反馈处理模块测试用例表

测试内容	测试步骤	预期结果	实际结果
提交反馈	填写反馈内容后提交	生成状态为待处理的反馈记录	符合预期
管理员回复	管理员填写回复内容并提交	反馈状态更新为已回复	符合预期
用户查看回复	用户进入反馈页面查看详情	显示管理员回复内容	符合预期
删除反馈	用户删除未回复的反馈记录	反馈记录从列表中消失	符合预期

评论管理模块的测试验证用户只能操作自己的评论内容，同时管理员具备更广泛的评论管理权限。测试用例包括登录用户发表评论的正常流程、用户删除自己评论的权限验证、管理员删除其他用户评论的越权操作以及管理员置顶优质评论的功能实现。表6-6展示了评论管理模块的详细测试用例。

表6-6 评论管理模块测试用例表

测试内容	测试步骤	预期结果	实际结果
发表评论	登录用户填写评论内容并提交	评论在详情页底部显示	符合预期
删除自评	用户删除自己发表的评论	评论从页面中移除	符合预期
管理员删除	管理员删除其他用户的评论	评论从所有用户视角消失	符合预期
置顶评论	管理员将优质评论置顶	置顶评论显示在列表最上方	符合预期

批量审核模块的测试验证多条记录同时处理时的事务一致性与操作正确性。测试用例包括批量批准多条待审核记录的状态更新、部分记录因容量不足导致失败的容错处理、批量驳回时统一理由的填写与应用以及未勾选任何记录时的提示校验。表6-7展示了批量审核模块的详细测试用例。

表6-7 批量审核模块测试用例表

测试内容	测试步骤	预期结果	实际结果
批量批准	勾选多条待审核记录执行批量批准	所选记录状态均更新为已通过	符合预期
部分失败	批量批准中包含容量不足的记录	容量充足记录通过审核不足记录保持待审核	符合预期
批量驳回	勾选多条记录执行批量驳回填写统一理由	所有记录状态更新为已驳回	符合预期
空选择	未勾选任何记录时点击批量审核按钮	系统提示请先选择预约记录	符合预期

6.4测试结论

通过对系统进行全面的功能、性能、安全等方面的测试，确认软件在各种环境下的表现符合预期。若发现问题，已进行相应修复或提出改进建议。测试结果表明，软件基本满足设计要求，性能稳定，未发现重大缺陷，验证了系统的功能性、稳定性和兼容性。

7总结

高校体育馆在日常运行中面临着资源分配不均与管理效率低下的双重压力。本研究基于Python语言与Django框架设计了一套完整的校园体育馆预约管理系统，将传统人工预约模式转变为线上自助服务流程。系统解决了场地信息不透明、预约冲突频发、管理数据分散等实际问题，完成了预期设计目标。

研究过程按照需求分析、系统设计、编码实现、测试验证的标准软件开发流程推进。系统采用前后端分离架构，Django框架处理后端业务逻辑与数据持久化，Vue框架构建响应式用户界面。MySQL数据库存储核心业务数据，Redis缓存用于提升高频查询场景的响应速度。用户端实现了场馆查询、预约申请、预约取消、评论互动、反馈提交等功能，管理端完成了场馆配置、预约审核、数据监控、公告发布等功能。经过系统测试验证，各功能模块运行正常，预约流程数据一致。

当前系统在资源调度智能化方面存在不足，预约审核仍依赖管理员的主动操作，尚未引入自动分配算法。取消时段的资源再分配需要人工干预，无法实时通知排队用户。系统暂未集成邮件或短信通知渠道，用户需要主动登录系统查看审核结果。日志分析模块功能较为基础，缺乏对用户行为的深度挖掘。

后续工作可以在预约调度算法层面进行优化，引入优先级排队机制实现自动分配。通知渠道可扩展至微信消息推送，提升用户互动体验。数据可视化模块可增加场馆使用率统计图表，为管理决策提供数据支撑。系统设计思路与实现方法可推广至其他校园资源预约场景，具有良好的应用前景。

参考文献

1. 陆向艳,刘峻. 基于SpringBoot的机房预约系统的设计与实现[J].工业控制计算机,2025,38(07):128-129.
2. 刘振华. 基于低代码平台的劳动课预约系统的设计与实现[J].电脑编程技巧与维护,2025,(02):20-22+52.
3. 倪甜弟,周晓波,王相喜. 基于JSP图书馆自习室预约系统的设计与实现[J].现代计算机,2024,30(09):117-120.
4. 刘清岗. 高校实验预约系统的设计与实现[J].信息与电脑(理论版),2024,36(08):10-12.
5. 纪力.智慧场馆自动分配预约系统设计与实现[C]//中国智慧工程研究会,中国班迪协会,广东省体能协会.第十届中国体能训练科学大会论文集（下）.三峡大学体育学院;,2023:291-300. 
6. 桑冉航,李晓明. 基于Spring Boot的健身房管理系统的设计与实现[J].电脑知识与技术,2023,19(22):54-56.
7. Zhuang W ,Song B ,Li F Z M , et al. Dynamic resource allocation and scheduling for appointment-based systems with walk-ins[J].IISE Transactions,2025,57(8):976-993.
8. Ying H ,E. M J ,Xiaojun S , et al. A multi-appointment patient scheduling system with machine learning and optimization[J].Decision Analytics Journal,2024,10100392-..
9.  Integrating digital reservation systems and business models[J].Strategic Direction,2022,38(8):1-3..
10. 张峻熙. 基于Django的图书推荐系统的设计与实现[J].辽宁师专学报(自然科学版),2025,27(04):41-49.
11. 林聪,王龙洋,颜晨阳. 基于Vue.js与Django的虚拟化管理平台设计[J].科技创新与应用,2025,15(15):43-46.
12. 八度云计算(安徽)有限公司. 一种基于Vue框架的UI组件库构建方法:CN202311590956.7[P]. 2024-03-29.
13. 李晓薇. vue.js前端应用技术分析[J]. 网络安全技术与应用,2022(4):44-45. 
14. 庞敏. MySQL数据库的数据安全应用设计技术研究[J]. 数字通信世界,2024(9):25-27. 
15. 柳青,程晨. MYSQL数据库技术应用一体化课程开发研究[J]. 造纸装备及材料,2024,53(5):251-253. 
16. 陈倩怡,何军.Vue+Springboot+MyBatis技术应用解析[J].电脑编程技巧与维护,2020,(01):14-15+28.
17. 何金龙. 电子信息工程计算机数据库应用[C]//2024智慧施工与规划设计学术交流会论文集. 2024:1-3.
18. 张晓蕾,王斌,郭锡泉. "互联网"背景下数据库应用技术课程思政教学设计与实践[J]. 现代商贸工业,2024(23):251-253. 
19. 罗超,彭玉涛. 计算机软件测试方法的研究分析[J]. 长江信息通信,2023,36(2):83-85. 

致谢

在本次项目的完成过程中，我得到了许多人的帮助和支持，在此，我衷心感谢所有给予我帮助的人。

我要感谢我的指导老师。感谢您在项目的每个阶段给予我悉心的指导和宝贵的建议。每当我在项目中遇到困难和挑战时，您总是耐心地解答我的问题，并且通过详细的讲解帮助我深入理解相关的理论和实践知识。您的专业态度和严谨的教学方法，不仅让我掌握了项目中的技能，还启发了我对专业领域的更深思考。没有您的指导，这个项目无法如此顺利地完成。

我要感谢我的同学们。在项目实施的过程中，大家与我进行了深入的讨论，分享了各自的见解和经验，使我能够从不同的角度看待问题，帮助我更好地完成任务。虽然这个项目是独立完成的，但与同学们的交流让我收获了许多新的思路和灵感。我还要感谢我的家人。在我投入大量时间和精力进行项目研究时，家人始终给予我理解和支持，鼓励我在面对困难时坚持下去。你们的关爱是我不断努力和进步的动力源泉。感谢学校提供的优质学习平台和资源，使我能够顺利地完成项目并实现预期目标。通过本次课业项目，我不仅掌握了相关的专业知识和技能，也培养了独立思考和解决问题的能力。这些收获将对我未来的学习和发展产生深远的影响。

再次感谢所有在项目中给予我帮助和支持的人，是你们的帮助让我顺利完成了这次项目。

请关注点赞+私信博主，免费领取项目源码