企业官网建设流程全解析

前几年帮几个朋友做课程设计选题参考的时候，几乎每年都能遇到同一个需求：自习室座位不够用，一早去排队还不一定能抢到考研座位。后来我发现，与其做一个“后台管理展示型”的项目，不如把“预约”这个核心动作做扎实，于是就有了这套可复现的SpringBoot+Vue MVC自习室管理和预约系统平台。它不是简单的增删改查Demo，而是把用户注册登录、自习室与座位管理、按时段预约、签到与违约处理、后台数据统计串成了一条完整业务链，配套SQL脚本和接口文档，拿来做Java Web方向的毕业设计或课程设计，属于性价比很高的选题。

这篇文章会把整个项目从需求分析、技术选型、表设计、接口规范、联调踩坑到部署演示的完整过程记录下来。如果你正准备做一个类似场景的系统，或者只是在纠结毕设到底选什么方向，都可以照着这份思路落地。我会尽量把当时纠结过的点、改过的表、踩过的坑都写出来，而不是只讲正确的结论。

1. 自习室预约系统立项前的思考：这道题究竟在考什么

1.1 评审真正会看的三个维度

毕业设计这个东西，表面上是“做出来一个系统”，实际上老师评委心里有三条隐形的评分线：业务是否完整闭环、技术栈是否覆盖核心知识点、交付物是否齐全。很多同学在选题阶段就把路走窄了，比如选了“图书借阅管理”，做来做去就是借书、还书、查书三个页面，技术点只有单表操作，答辩时候根本没什么可讲的。

自习室预约系统天然就很适合做毕业设计，因为它有个关键字叫“预约”。预约一定会涉及时间、座位、用户、违约，四个实体一碰撞，数据模型就立体了。更关键的是，预约过程里有并发冲突问题，只要把这一层处理好，技术上就有东西可聊了。我自己见过太多选题，业务复杂但是技术平平，或者技术很炫但是业务空洞，这个系统恰好两头都占。

评审在验收时还会看另一件事：拿到你的源码能不能跑起来。这就要靠SQL脚本和接口文档来支撑。SQL脚本不是把表结构导出来就完事，还要有初始化数据、管理员账号、几间演示自习室、几十个座位样例；接口文档也不是随便贴几个Swagger注解就结束，得能让人知道每个接口的入参、出参、错误码。这三样东西，源码、SQL脚本、接口文档，本身就是分数。

1.2 自习室业务与图书管理的本质差异

如果和“图书管理”这类经典选题放在一起对比，自习室预约系统的优势会更明显。图书管理里的“预约”通常是弱需求，大部分操作还是借还，数据关系就是图书和读者两张表。自习室系统就不同，座位是稀缺资源，用户对“某个具体座位在某个时间段是否可用”是有强感知的，这就逼着你去思考时间片、状态、冲突这些抽象概念。

这个差异直接影响了表结构设计。图书管理只需要知道“这本书被谁借走了”，自习室预约却要回答“这个座位10月24日上午是谁的，下午是否空闲”。看似只是一问一答的区别，落到数据库里就是一组唯一约束和一条状态机的设计，复杂度和答辩话术都会不一样。对于要拿高分的人来说，选一个能让评委“看到技术含量”的题目，比选一个“最稳妥”的题目更重要。

1.3 项目边界：先把预约闭环做扎实

立项的时候还容易犯一个毛病：什么功能都想加。有人想接个门禁扫码，有人想加实时视频监控，还有人想对接一卡通支付。这些设想不错，但对于一个周期有限的毕业设计来说，只会把主流程拖垮。我当时给朋友定的边界很简单：不做打印、不做门禁、不做支付，把“选座—预约—签到—退座—违约处理”这条闭环做透，剩下的时间留给代码质量和文档。

守住边界之后，系统功能就非常清楚了。用户端能看自习室列表、看座位实时状态、预约座位、取消预约、签到、查自己的预约记录；管理端能维护自习室和座位、查看所有预约单、处理冲突和违约记录、做一些简单的统计。这一套下来，主流程清晰，演示的时候可以很顺畅地讲给评委听。

2. 技术选型：SpringBoot+Vue的组合为什么适合本科毕设

2.1 后端：SpringBoot 2.7 + MyBatis-Plus + MySQL 8.0

后端选型有些人一上来就追求最新，Spring Boot 3.0出来就用3.0，JDK版本也直接上17，结果发现很多课程配套资料都是基于老版本的，遇到问题连查都查不了。我个人建议用Spring Boot 2.7.x，这个版本相当成熟，兼容JDK 8和JDK 11，学校机房、个人电脑、云服务器都不容易出兼容问题。

持久层我选的是MyBatis-Plus，理由是它能省掉大量样板代码。单表查询、分页、条件构造器都是现成的，写SQL的地方比原生MyBatis少很多。它也确实内置了防SQL注入、逻辑删除、自动填充这些实用功能，在毕设答辩里讲出来都是加分点。至于MySQL，直接选8.0版本，字符集用utf8mb4，中文存储没有乱码烦恼，和Spring Boot的驱动也兼容得比较好。这套组合最大的优势是资料多、踩坑少，出问题GitHub一搜基本都有现成答案。

2.2 前端：Vue 3 + Vite + Element Plus

前端的选型逻辑也类似。Vue 3现在是绝对的主流，配套的Vite构建工具比之前的webpack快太多，idev启动几乎是秒开。UI组件库直接用Element Plus，后台管理的表格、表单、弹窗、标签页这些组件都是现成的，不用自己写CSS调样式。状态管理用Pinia，比Vuex的写法更轻量，TypeScript支持也更好，本地开发体验很舒服。

有人可能会纠结要不要用TypeScript。我的建议是，如果你对TS不熟，就别在毕设里硬上。Vue 3本身用JavaScript写也完全能跑，Element Plus的组件提示在JS下一样好用。把精力集中在业务逻辑上，比在类型体操里挣扎更有价值。实操的时候一个比较舒服的前端组合是：Vue 3 + Vite + Vue Router + Pinia + Axios + Element Plus，这几个包装好就能很快搭出页面框架。

2.3 “后端MVC+前端Vue”的分工到底是什么

这个项目标题里写了“MVC”，很多同学对“SpringBoot+Vue”和“MVC”这两个概念的关系有点模糊。实际上这里说的是：后端保持传统的MVC分层结构，Controller是控制层，Service是业务层，Mapper是数据访问层，只是原来MVC里的View（也就是JSP页面）被前端的Vue项目替代了。

这个替代带来了前后端分离的模式。后端只提供JSON格式的接口数据，不关心页面长什么样；Vue负责渲染页面、收集用户输入、调用接口。两者的联调契约就是接口文档。这样的好处是开发和定位问题都更清晰，后端出Bug看日志，前端出Bug看控制台，不会再出现JSP页面里Java代码和HTML混在一起的情况。

标准MVC和后端分离式MVC的差别可以用下面这个表格直观表示：

这样一拆，“后端MVC+前端Vue”就变成了一个容易理解的结构。

2.4 环境准备清单与版本搭配

环境准备这步看着简单，实际每年都有人卡住。我整理了一份比较稳的搭配清单：

• JDK 8 或 JDK 11，不要用太新的版本
• Maven 3.8+，配置阿里云镜像可以加速依赖下载
• MySQL 8.0，本地推荐用安装版而不是免安装版，环境变量不容易出错
• Node.js 16+，Vite 3/4 都兼容
• 开发工具：后端用IntelliJ IDEA，前端直接用VS Code，数据库可视化用Navicat或者DBeaver
• Redis可以先不装，把Redis做成分阶段加分项，后面按需再加

这些版本组合我自己复现过很多遍，基本没有因为版本兼容问题导致项目跑不起来的情况。环境越简单，后面越不容易在联调阶段被各种莫名其妙的报错打断。

3. 座位预约的核心难题：冲突、时间片与状态流转怎么设计

3.1 预约主流程拆解：一个预约单的生命周期

预约模块是整套系统的核心，我的拆法是把它拆成一个完整的主流程：用户进入自习室列表页，选中某间自习室，看到座位网格图，点击一个空闲座位，选择预约日期和时段，确认提交，系统生成预约单，预约单状态变成“待签到”。到了预约时间，用户在个人中心或者座位详情页点击签到，状态变成“已签到”。离开时点击退座，状态变成“已完成”。

如果用户在预约时间前取消了预约，预约单直接变成“已取消”。如果到了时间没有签到，预约单会被系统自动标记为“违约”，同时给用户记一条违规记录。这个主流程看起来简单，却是整个项目里最容易出Bug的地方，因为每一步都可能有人捣乱：重复提交、超额预约、迟到不签到、取消后座位状态不对。能把这条流程稳定跑通，项目质量就有了基础保障。

3.2 时间片划法：为什么我建议上午/下午/晚上

时间和座位的组合方式直接决定了系统复杂度，这一块有几种常见方案。第一种最简单，按整天约，座位一旦被预约，一整天都不能再约别人；第二种是把一天划分为上午、下午、晚上三个时段；第三种是精确到小时，比如可以约9点到10点。说实话，第一种对管理员和用户都太糙了，第三种表面看起来灵活，实际会带来一堆碎片时段，座位状态图和日程管理都会变复杂。

所以我最终选择了第二种：一天三个时段，上午是8点到12点，下午是13点到17点，晚上是18点到22点。这个划分有几个现实好处：和大多数高校自习室的开放时间吻合；管理端在做巡查和统计时，需要关心的状态数量极少；用户在页面上也不需要去调时间选择器，点一下“上午/下午/晚上”按钮就行。时间片越少，并发冲突的概率越低，演示的时候逻辑也越清楚。

3.3 并发冲突怎么兜底：前端防重、Redis预占与数据库唯一索引

座位预约最怕的是“两个人同时抢同一个座位”。如果只靠前端控制，用户A和用户B几乎同时点击提交，两个请求打到后端，数据库里可能就插入了两条相同座位的预约记录。所以我在设计时做了三层防护。

第一层是前端防重。用户点击“提交预约”之后，按钮立刻置灰，状态变成“提交中”，防止手误连点两次。第二层是用Redis做预占座，在写入数据库前先把“座位ID + 日期 + 时段”作为Key写入Redis，写入成功才允许继续。第三层也是最根本的兜底，在数据库建表时给座位时间字段加唯一索引，这一层防的是所有前面漏掉的极端情况。

这三层里面，最值得在答辩时讲的就是唯一索引。它是数据库层面最后的闸门，无论请求多么并发，只要是把相同座位和相同时间段插入两次，数据库就会抛出主键冲突异常，后端捕获这个异常后给用户返回“该座位已被预约”的提示。这个方案小而美，比用定时任务扫描加锁的实现方式可靠得多。

3.4 状态流转：待签到、已签到、违约如何切换

预约单的状态是一个典型的订单状态机，我把状态定义为：待签到、已签到、已完成、已取消、违约。初始状态是“待签到”，用户主动取消则进入“已取消”；用户到点签到进入“已签到”；签了到再点击退座，进入“已完成”；如果一直不签到，则由定时任务在时段开始后一小时内扫描所有超时未签到的记录，自动改成“违约”。

这里最需要注意的一个细节是“违约”不能被用户主动触发重置。后台只有管理员可以把“违约”改成“正常完成”，用于处理特殊情况。这样设计保证了信用的严肃性，也方便统计违约率。每个状态的变化在后端都写成了枚举和状态机校验器，而不是散落的各种if判断，后续改逻辑的时候会轻松很多。

3.5 核心预约代码示例与解释

预约的Service层是整个系统中最重要的几行代码，核心逻辑可以浓缩成下面这段伪代码风格的真实实现：

@Transactional(rollbackFor = Exception.class) public Result<Long> reserve(ReserveDTO dto, Long userId) { // 基础校验：座位是否存在、自习室是否开放 Seat seat = seatMapper.selectById(dto.getSeatId()); if (seat == null || !seat.getStatus().equals(SeatStatus.AVAILABLE)) { return Result.error("座位不可用"); } // 查用户是否有未结束的预约，避免重复占位 int activeCount = reservationMapper.countActiveByUser(userId, ReservationStatus.WAIT_SIGN, ReservationStatus.SIGNED); if (activeCount > 0) { return Result.error("你已有待签到或使用中的预约"); } // 插入预约记录，如果并发冲突，这里会抛出 DuplicateKeyException Reservation reservation = new Reservation(); reservation.setUserId(userId); reservation.setSeatId(dto.getSeatId()); reservation.setReserveDate(dto.getReserveDate()); reservation.setTimeSlot(dto.getTimeSlot()); reservation.setStatus(ReservationStatus.WAIT_SIGN); try { reservationMapper.insert(reservation); } catch (DuplicateKeyException e) { throw new BizException("该座位在该时段已经被预约"); } return Result.success(reservation.getId()); }

这段代码里我觉得最有价值的是事务注解和唯一索引配合的写法。@Transactional保证了插入失败时不会留下半截数据，唯一索引保证就算两个请求同时到达，也只有一条能插入成功。你不需要写任何加锁代码，数据库本身就帮你把最难处理的问题解决掉了。

4. 数据库建模：从表设计到SQL脚本的几次关键调整

4.1 五张核心表的字段设计与说明

数据库设计是这类系统的骨架。我最后沉淀下来的是五张核心表：用户表、自习室表、座位表、预约记录表、违规记录表。用户表存登录账号、密码、昵称、角色；自习室表存名称、位置、开放状态、座位总数；座位表存所属自习室ID、座位编号、朝向/楼层位置等描述信息；预约记录表就是前面说的那套状态字段；违规记录表存违约用户、违约时间、关联预约单编号。

关键的字段我整理成了一张表，方便直接对着建表：

这套表结构设计的原则是“少而精”。每张表都有它能回答的业务问题，不存在冗余度失控的情况。座位表单独存在而不是在自习室表里塞一堆座位字段，是因为座位是预约的最小单位，必须拥有自己的生命周期状态。

4.2 三个调整过的表结构决策

第一个调整是座位表要不要保存“自习室名称”这个冗余字段。一开始我认为只需要room_id就可以，查询时再关联自习室表拿名称；后来发现前端座位列表、预约记录、后台管理表格几乎每页都要显示自习室名称，连着做几次表关联不仅让SQL变得啰嗦，还容易在分页统计时出问题。最终我在座位表上增加了room_name字段，代价是多存一点冗余数据，换来的是查询性能明显变好，接口也简单了。

第二个调整是预约记录表的时间字段，最初设计成开始时间和结束时间两个datetime，后来改成reserve_date加time_slot两个字段。前面说的时间片方案在这里就体现出来了：用datetime存储，用户自由度太高，数据库很难统一约束；用日期加枚举时段，天然限制了预约粒度，表结构还更清晰。唯一索引也是基于这两个字段加的。

第三个调整是状态字段的类型。一开始我用的是int，0、1、2、3，后来发现代码里到处是魔法数字，非常难维护。后来改成varchar存状态名称，并且全部用枚举类管理。虽然存储上稍微多占一点空间，但代码可读性和后续扩展性好了太多，这在项目中期回过头来看是非常值得的一次改动。

4.3 初始化数据脚本与演示数据的意义

SQL脚本里除了建表语句，设置初始化数据也要花心思。不是随便插入几行数据就完事，而是要让评审在第一次启动项目时就能看到效果。至少需要一条管理员账号，密码可以是123456但建议在文档里标注“登录后请修改”；再准备3到5间自习室，每间有15到30个座位；座位状态最好有一部分是“空闲”，一部分是“占用”，这样才能在首页立刻展示出座位状态的区别。

预约记录也可以准备几条历史数据，方便管理端打开预约列表时就有东西看。需要提醒的是，测试数据的时间不要写死成固定日期，尽量用相对日期，比如“当天”“明天”，否则数据库演示到第二天就会出现数据过期的尴尬情况。SQL脚本的组织还要区分成库脚本和数据脚本两个文件，命名清楚，别人导入的时候不会一头雾水。

4.4 SQL脚本文件怎么组织

交接项目时最怕的是给对方一个几十行的混乱SQL文件。我会把SQL脚本拆成三个文件：建库脚本、建表脚本、初始化数据脚本。建库脚本里写好CREATE DATABASE和字符集设置；建表脚本里放所有表和索引定义；初始化数据脚本里放管理员账号、自习室、座位和示例预约记录。每个文件头部写清楚这个文件的作用和执行顺序。

关于字符集这里多说一句，所有表都统一用utf8mb4，排序规则用utf8mb4_general_ci。很多同学用默认的latin1，导入数据后中文全部变成问号，排查起来还非常费劲。这个问题在答辩场景中经常出现，提前统一字符集能省掉一大类故障。

5. 接口文档规范与前后端联调中踩过的坑

5.1 接口文档的两种形态：在线调试与离线文档

接口文档在毕业设计里往往被当成一个摆设，但它其实是连接前后端两个人的关键交付物。我建议准备两种形态：一种是在线的Knife4j接口文档，后端启动后访问固定路径就能看到所有接口的在线调试页面；另一种是离线的Markdown文档，里面包含每个接口的请求地址、请求方式、入参字段、出参结构、错误码说明。

在线文档的好处是答辩时可以现场演示接口调用，评委能直观看到数据在流动；离线文档的作用是作为项目交付报告的一部分，打印出来或者转成PDF放进附件。两种形态对应的内容是一样的，但组织方式不同。在线文档依靠Swagger注解生成，离线文档则需要专门编写，不能偷懒。写离线的接口文档时，我会把每个接口的demo请求和响应都贴出来，避免空泛的字段描述让人看不懂。

5.2 统一响应结构 Result

前后端联调最容易出乱子的地方是各自的返回格式不统一。有的接口返回{code:200,data:{}}，有的返回{success:true,data:{}}，前端拿到数据就要写一堆兼容逻辑。我在这个项目里用了统一响应结构，所有接口都返回相同的格式。

{ "code": 200, "message": "操作成功", "data": {} }

出参保证始终包含code、message、data三个字段。成功时code是200；参数错误时code是400；未登录时code是401；业务异常比如座位被抢时code是5001，message里写明具体原因。前端axios拦截器统一处理code，非200的情况直接弹出错误提示，页面代码因此变得非常干净。后端还配了一个全局异常处理器，把校验异常、业务异常、系统异常分别映射到对应的code和message，不会出现错误信息泄露给用户的低级问题。

5.3 接口分组与重点接口说明

接口按照业务模块可以分成四组：认证模块、自习室模块、预约模块、管理端模块。认证模块负责登录注册和用户信息查询；自习室模块负责自习室列表、座位网格图、途径状态查询；预约模块负责创建预约、取消预约、签到、查我的预约；管理端模块负责座位增删改查、预约单管理、违约记录、统计报表。

这四组接口加起来大概30个左右，其中我认为有两个接口需要在文档中重点说明。第一个是“创建预约”接口，它涉及并发问题和状态变更，文档里要写明可能返回的业务错误码，比如“当天重复预约”“用户有未完成预约”“座位已被预约”；第二个是“签到”接口，它包含对预约状态的转移，文档里需要说明什么情况下允许签到、什么情况下返回“已超过签到时间”。接口文档越细，联调时来回问话的次数就越少。

5.4 联调实测踩坑记录：Long精度、CORS、日期格式

第一次前后端联调时最让我头疼的问题是Long类型主键的精度丢失。数据库里自增主键存储的是雪花算法生成的BigInt，传到前端以后被JavaScript的Number类型截断了，最后的几位数字全部变成0，导致编辑座位时永远匹配不上记录。解决办法是在实体类的主键上加上@JsonSerialize(using = ToStringSerializer.class)注解，把Long序列化为字符串，前端拿到的是字符串，就不会丢失精度了。

第二个坑是跨域问题。前端跑在5173端口，后端跑在8080端口，浏览器默认会拦截跨域请求。解决办法是后端加一个CorsFilter配置类，把前端的地址加进允许列表。需要注意的是，既要配置允许的域名，也要配置允许的请求头和请求方法，否则登录接口可能通了，带token的鉴权接口又会被拦。

第三个坑是日期格式。后端返回的LocalDateTime默认格式是一长串带T的字符串，前端显示的时候会多出个T，非常难看。我是在全局配置里统一设置了时间格式化，把它们转成yyyy-MM-dd HH:mm:ss格式。这三个坑都是典型的“不联调根本发现不了”的问题，写进文档里可以让后来的人少走很多弯路。

6. 打包部署与演示交付的实操要点

6.1 从源码到可运行的构建流程

项目写完不代表结束，能拿到一台干净机器把它跑起来才算真本事。后端打包命令很简单，跳转到项目根目录执行mvn clean package -DskipTests，完事后在target目录下会生成一个可执行的jar包。前端打包要先进入vue项目的目录，执行npm install安装依赖，再执行npm run build，生成的静态文件会输出到dist目录。

打包过程中容易遇到的问题是后端jar包依赖的资源文件路径不对，前端打包后接口地址写得不对。我的习惯是前端项目里建一个配置文件，打包时不写死接口地址，而是读取环境变量，如果没有则默认使用/api这个相对路径，这样静态文件部署到哪里都能用，方便迁移。

6.2 服务器部署的简化路径

部署方式我比较推荐两种，一种是直接java -jar方式，简单直接，适合演示和本地跑；另一种是用nginx部署前端，把后端jar包单独运行，适合模拟真实线上环境。我第一次给朋友搭的时候用的就是nginx方案，原因是这个方案能在答辩时顺便展示“我懂一点运维”，评委看到前端静态资源由nginx分发、后端接口由Spring Boot提供服务，会觉得项目的实战味道更足。

数据库部分的步骤也很清楚：在服务器上安装MySQL 8.0后执行SQL脚本，建好库和表并导入初始数据，然后检查一下后端配置里的数据库账号、密码、ip和端口是否匹配。应用启动后先用在线接口文档自测一遍核心接口，确认预约、取消、查询都正常了，再开始对接前端页面。

6.3 演示顺序与评审关注点的对应

演示环节的顺序是有讲究的。上来先不要一进系统就点这几个页面，最好按照业务逻辑的先后顺序走：先演示注册登录和角色区分，然后展示自习室列表和座位状态图，接着现场预约一个座位，演示签到的完整过程，最后切到管理端看看预约单和统计报表。

这个顺序实际上就是评审心中的业务闭环顺序。每一步演示我还会配合说一句话，比如注册登录时强调“密码用了BCrypt加密”，预约座位时强调“这里靠唯一索引防止并发抢座”，管理端统计时强调“这里能看到每间自习室的使用率”。在关键节点说关键术语，比讲完所有代码都管用。别忘了在演示结束前提一句项目里带了完整的SQL脚本和接口文档，这些都是交付物的一部分。

6.4 答辩问答题：我预演过的几个问题

答辩环节大家都会紧张，最好的应对方式就是提前把高频问题练熟。我把自己被问到的问题和准备的答案整理了几个：老师可能会问“为什么用SpringBoot而不用传统SSH”，回答可以围绕配置简化、内嵌容器、生态整合三点展开；还可能问“座位并发冲突怎么处理”，这就是前面讲的唯一索引和事务；还经常被问“如果预约人数特别多怎么办”，可以从索引优化、异步写、消息队列排队这几个方向回答。

还有一个容易忽略的点是“这套系统的不足”。千万不要说什么“没有不足”，也不要说“代码太烂”，而是准备一个可以接受的改进方向，比如“当前没有做消息通知，后续可以用WebSocket推送预约结果和签到提醒”。这样回答既显得你有反思能力，又展现了后续的扩展意识，评委观感会好很多。

7. 复盘：这个项目还能长出哪些二期能力

7.1 从“预约成功”到“实时占位图”的升级路径

目前的座位状态图是用户手动刷新才能拿到的最新状态，如果要做成二期能力，可以引入服务端主动推送。简单方案是前端每隔几秒轮询一次座位状态接口，进阶方案是使用WebSocket建立长连接，让座位被预约后所有在线用户马上看到状态变化。轮询适合课程设计，WebSocket是加分项，代码量其实不大，就是需要考虑连接管理和断线重连的问题。

实时占位图的意义在于“感知预约结果”，用户不用反复刷新页面猜座位状态，预约成功的那一刻，其他人页面上的座位格子自动变红。这个体验在演示时非常出效果，答辩时可以作为“业务优化”来讲。唯一的坑是要控制推送频率，不然一小时几万次无效消息，容易把服务器拖垮。

7.2 消息通知：把“快到时间了”变成可感知的提醒

预约迟到和违约是真实场景里的高频问题。现在的系统只能靠用户自己记住预约时间，属于被动提醒。二期可以加消息通知模块，在预约开始前15分钟给用户发站内信或者邮件提醒，提醒他“你预约的位置即将开始签到”。这条链路不复杂，用一个Spring定时任务扫15分钟后的预约记录，再调邮件接口发送即可。

这块的价值在于防止投诉和提升系统人性化程度。管理员希望尽量少的违约记录，学生又容易因为复习忘记时间，一个简单的提醒就能让双方都受益。代码上的难点是要处理好发送记录的去重，避免同一个预约被提醒两次。

7.3 统计报表：给管理员的“驾驶舱”

现在的管理端只有基础的预约列表和违约列表，统计数据很单薄。二期可以做一个统计驾驶舱，按天展示各自习室的预约人数、入座率、违约率趋势，按周或按月做横向比较。比如计算一间自习室每个时段的平均满座率，判断哪个时段需要增加座位，哪个自习室的热度在下降。

这种统计报表在毕设中很有分量，因为需要写聚合SQL、封装查询DTO、前端画折线图和柱状图。ECharts组件库接入起来也很顺畅，后端只需要提供几个统计接口，把维度、日期范围作为入参，返回聚合好的数据。这一块做好了，系统就从一个“业务管理系统”往上走了一层，变成“辅助决策平台”。

7.4 如果重新做一遍，时间会花在哪里

复盘下来，如果让我重新做一遍，我会把更多时间花在接口文档和异常逻辑上，而不是继续加新页面。因为前后端只要开始联调，需求就一定会变，文档先行的习惯能大幅减少返工；异常逻辑则决定系统在实际使用中能不能扛住各种奇怪操作，比如同一用户用两个浏览器同时预约、管理员把座位禁用后已有预约怎么处理，等等。

还有一件事我一直觉得遗憾：当时没有给项目写一个像样的README。后来想分享给别人时，光靠记忆去重新配环境、改配置，花了不少时间。如果你做这个项目，请在第一天就留一个README.md，把运行步骤、账号密码、环境要求、常见问题都写进去，这会成为整个项目交割时最值钱的文档之一。

做毕业设计的过程本质上是一次完整的工程训练，能写完一个可用的系统是基础，能讲清楚为什么这样设计才是提升。这套自习室预约系统没有什么“神秘黑科技”，每一步都是常规技术栈的合理组合，但只要吃透了预约这条主流程上的设计和取舍，你收获的就不只是一份代码，而是一套解决实际问题的思考方式。