企业官网建设流程全解析

1. 项目概述与选题背景

1.1 核心需求解析

先把这个标题拆开来看：面向企业用户的复合型活动基地公共会议管理系统，加上一个加粗的会议室预订系统。说白了，这就是一个给企业或园区用的会议管理平台，负责会议室信息展示、在线预订、审批管理、使用记录统计这些事。放在复合型活动基地这个场景里，就是那种既有办公区、又有路演厅、还有洽谈室和培训室的综合型场所，会议室数量多、类型杂、使用频次高，靠人工在纸上登记或者用Excel排期，基本就是灾难现场。

这个选题在Java毕设里属于常青树级别，我每年都能看到好几个人做类似方向。为什么大家喜欢做这个？因为它的复杂度卡得刚刚好——比“图书管理系统”那种纯CRUD高出一截，又不至于像电商秒杀系统那样需要分布式事务、消息队列这些重型组件。它能完整覆盖一个真实项目该有的东西：权限控制、复杂查询、时间冲突检测、审批流、统计报表，恰好能把Spring Boot + MyBatis + Vue这套主流技术栈串起来。

对于做毕设的同学来说，选择Spring Boot而不是SSH或者Servlet原生的理由非常现实：Spring Boot的自动配置机制能把大量样板配置直接省掉，一个spring-boot-starter-web就搞定了Web环境，spring-boot-starter-data-redis就接入缓存，开发效率比SSH那套动不动就要写一堆XML配置的方式高出一个量级。而且现在企业的Java后端岗位，问的就是Spring Boot + 微服务这套东西，选这个技术栈做毕设，相当于提前把面试常见的技术场景演练了一遍。

1.2 这类系统要解决的现实问题

会议室管理听着简单，真正跑起来你会遇到一堆真实的问题。我见过一个做园区运营的朋友，他们那里8间会议室，高峰期一天要排40多场会议，原来用Excel排期，经常出现两个部门抢同一间会议室，或者会议开始半小时前才发现和另一场培训冲突。更麻烦的是，有些会议室设备不一样——有的有视频会议系统，有的有白板，有的能坐20人，有的只能坐6人，人工排期根本记不住这些细节。

所以这类系统真正要解决的核心问题有三个：

资源冲突问题：同一间会议室在同一时间段不能被预订两次。这个听起来简单，但判断冲突的逻辑有不少坑，后面我会详细讲。

设备与容量匹配问题：用户订会议室之前，得知道这间会议室能坐多少人、有什么设备、在几楼、有没有窗户。这些属性信息必须清晰地展示在预订页面上。

审批与权限问题：企业场景下，会议室的预订通常不是“点一下就行”的，订大会议室可能要部门经理审批，订普通洽谈室可能只需要管理员确认。怎么把审批流做得既灵活又不复杂，是个需要动脑子的设计点。

这个系统把这三个核心问题都覆盖了，所以它作为毕设选题的价值不只是“能交差”，而是你在写它的过程中，确实能接触到企业级应用开发的真实套路。

2. 技术选型与架构设计思路

2.1 后端框架选择：Spring Boot为什么是标准答案

Spring Boot在Java毕设里已经处于绝对统治地位，这个不用争。但我要说的是，它怎么就适合这个项目了。

第一，开发效率高。这个项目要涉及的角色有管理员、普通员工、审批人，涉及的功能跨预约、审批、统计、用户管理、会议室管理，如果你用传统的Spring MVC手动配一堆Bean和XML，光配置文件就得写几百行。Spring Boot的自动配置把这些都吃了，你只需要关注业务代码。

第二，生态完善。会议室预订系统天然需要这些组件：MyBatis或MyBatis-Plus操作数据库、Spring Security或Sa-Token做权限控制、Redis做缓存（比如监控当前谁在哪个会议室）、WebSocket做会议室状态实时推送。这些在Spring Boot生态里都有成熟的starter，直接引入依赖就能用。

第三，部署简单。毕设答辩的时候，你大概率需要现场演示。Spring Boot应用打成一个可执行JAR包，java -jar一行命令就能跑起来。你要是用传统的Tomcat部署WAR包，还得先装Tomcat、配置数据源、调整JVM参数，演示现场出问题的概率高得多。

这个项目里我推荐的技术组合是：

• 后端：Spring Boot 2.7.x（稳定、资料多，别追新版本）
• ORM：MyBatis-Plus（比原生MyBatis少写大量XML，分页插件好用）
• 权限：Sa-Token（比Spring Security上手简单太多，代码侵入性低）
• 前端：Vue 2 + Element UI（Vue 3 + Element Plus也行，但Vue 2的教程和案例多，毕设阶段更容易找到参考）
• 数据库：MySQL 8.x（别用5.7了，8.0的窗口函数做统计报表方便）
• 缓存：Spring Data Redis（用来缓存用户会话和会议状态，可选，但加了能加分）

2.2 前后端分离还是服务端渲染

这是个必须做选择的点。我见过不少毕设项目，前端用Vue全家桶，后端纯提供JSON接口，但这种模式在答辩的时候有个尴尬的问题：你现场演示的时候，前端和后端要同时启动两个服务，万一网络配置不对、端口冲突、跨域没配好，演示就卡住了。

我的建议是：如果做纯后台管理系统，前端用Vue + Element UI 做前后端分离没问题，但要提前把跨域问题解决干净；如果求稳，用Thymeleaf服务端渲染也行，尤其是你要在演示的时候省心一点。

不过说实话，现在毕业设计的主流做法已经是前后端分离了，企业里也这么干。这篇博文的代码结构，我按前后端分离来设计——前端一套Vue工程，后端一套Spring Boot工程，中间通过RESTful API通信。

工程结构大致是这样：

• meeting-admin：后端Spring Boot工程
  • controller：接收前端请求，返回JSON
  • service：业务逻辑层，处理预订冲突检测、审批流等核心逻辑
  • mapper：MyBatis-Plus的数据访问层
  • entity：数据库实体类
  • dto：前端传参的封装对象
  • config：配置类（跨域、拦截器、异常处理）
• meeting-web：前端Vue工程
  • views：页面组件（登录、会议室列表、预订日历、审批中心、统计报表）
  • api：封装Axios请求
  • router：前端路由
  • store：Vuex状态管理

等一下，有些同学听到“Vue工程”就头疼，觉得自己前端不行。这里我多说一句：如果时间紧，你可以不用Vue CLI那套复杂工程化流程，直接引入Vue 3的CDN + Element Plus的CDN，写单页HTML文件就能把页面做出来，后端提供接口就行。这种方式在毕设里完全够用，还省去node_modules的安装时间。

2.3 数据库设计：会议室预订的核心表结构

数据库设计是这类系统的重头戏。表设计得好不好，直接决定你后面的业务逻辑是写得顺还是写得痛苦。我直接把这套系统的核心表结构拆给你看。

先明确我们有哪些实体：用户表（User）、会议室表（MeetingRoom）、预订记录表（Reservation）、审批记录表（ApprovalLog）、通知表（Notification）、会议室设备表（RoomDevice，可选）。

用户表

用户表不能只存个username和password，你需要冗余一个部门字段，因为在企业场景里，会议室预订通常要区分部门，而且后面做统计报表也要按部门维度统计。字段设计如下：

• id：主键，自增
• username：登录名，唯一
• password：BCrypt加密后的密码
• real_name：真实姓名，展示在预订记录里
• department：所属部门，用于按部门统计和权限控制
• role：角色，建议用整数表示，1=超级管理员，2=部门管理员，3=普通员工
• email/phone：联系方式，用于预订成功或冲突时的通知
• status：账号状态，0=禁用，1=正常

会议室表

会议室表需要有足够的属性让用户在做预订决策时参考。字段设计如下：

• id：主键
• room_name：会议室名称，比如“一号路演厅”“三楼洽谈室”
• location：具体位置，比如“A栋2层206”
• capacity：容纳人数，整数
• room_type：会议室类型，可选项：小型洽谈室、标准会议室、大型路演厅、培训室
• equipment：设备清单，用逗号分隔存储，比如“投影仪,视频会议系统,白板”
• open_time/close_time：开放时间段，比如08:00-22:00
• status：是否启用，管理员可以停用某些正在装修的会议室
• description：补充说明，比如“窗户朝南，采光好”

这里有个设计细节要注意：设备清单建议直接用一个文本字段存，不要拆成单独的设备表。为什么？因为设备信息对业务逻辑没有强约束，你只需要在展示时列出来就行，拆表反而增加复杂度。毕设项目要用“够用就好”的设计原则，不要为了追求范式搞得自己写起来痛苦。

预订记录表

这是整个系统的核心表，字段设计直接关系到冲突检测怎么写。字段如下：

• id：主键
• room_id：外键，关联会议室表
• user_id：外键，关联用户表，预订人
• meeting_title：会议主题
• meeting_date：会议日期，只存日期，比如2025-06-15
• start_time：开始时间，比如09:00
• end_time：结束时间，比如11:30
• status：预订状态，1=待审批，2=已批准，3=已拒绝，4=已取消，5=已完成
• create_time：预订创建时间
• remark：备注，比如参会人数、是否需要特殊布置

为什么日期和时间字段要分开存？因为预订的冲突判断是“同一日期下同一会议室的时间段重叠”，日期单独存，查询当天所有预订记录只需要WHERE meeting_date = ?，索引效率高，逻辑也清晰。

审批记录表

审批记录表用来追踪一条预订申请的审批链路，字段如下：

• id
• reservation_id：关联预订记录表
• approver_id：审批人ID
• approval_comment：审批意见
• approval_status：审批结果，1=通过，0=拒绝
• approval_time：审批时间

很多毕设不做这张表，审批状态直接写在预订表里。但我觉得加上会更好：它让系统支持“多人审批”的扩展可能，还能在详情页展示完整的审批历史，答辩的时候老师问起来你能多说两句。

关键索引设计

预订记录表需要建复合索引：(room_id, meeting_date, start_time, end_time)。这个索引能保证按天查某会议室预订记录的时候走索引，速度会快很多。

单用户的一天预订记录，可以建(user_id, meeting_date)索引，用于用户在个人中心查看“我的预订”。

2.4 前后端接口设计规范

前后端分离的开发模式，接口设计必须一开始就定好规矩。我给自己定的规范是这样：

• 所有接口统一返回Result对象，结构为{ code: 200, message: "success", data: {} }
• 分页接口返回{ total: 100, records: [] }
• 时间参数统一用字符串，格式yyyy-MM-dd HH:mm:ss，避免前后端时区不一致的坑
• 所有需要登录的接口，在Header里带上token（Sa-Token默认机制）

写接口文档的话，接口路径可以这样规划：

3. 核心功能模块设计与实现

3.1 登录认证与权限控制：Sa-Token的简单做法

权限控制这块，我强烈建议不要用Spring Security。不是说它不好，而是对一个毕设规模的系统来说，Spring Security的学习成本太高了——过滤器链、UserDetailsService、AuthenticationManager这些概念能把人绕晕，而且配置写错了查错特别费劲。

Sa-Token就简单得多。核心就三步：

# 引入依赖，Maven坐标如下 cn.dev33:sa-token-spring-boot-starter:1.34.0

登录的时候调用StpUtil.login(userId)，框架会生成一个token返回给前端。前端存到localStorage，每次请求在Header里加satoken: 这个token。后端在配置类里注册一个拦截器：

@Configuration public class SaTokenConfigure implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new SaInterceptor(handle -> { // 登录验证 StpUtil.checkLogin(); })).addPathPatterns("/**") .excludePathPatterns("/api/auth/login", "/api/rooms/list"); } }

这样就实现了“不登录不允许访问接口”的效果。角色权限控制用StpUtil.checkRole("admin")，在需要管理员权限的接口上加一行就行。

3.2 会议室列表展示与条件筛选

会议室列表页几乎是所有用户的入口页面。这里要支持按room_type、capacity、equipment等条件筛选，还要展示每个会议室的今日空闲时段。

后端接口设计如下：

@GetMapping("/api/rooms") public Result<PageResult<RoomVO>> listRooms(@RequestParam(required = false) String roomType, @RequestParam(required = false) Integer minCapacity, @RequestParam(required = false) String date, @RequestParam(required = false) String equipment) { PageResult<RoomVO> page = roomService.selectRoomPage( roomType, minCapacity, date, equipment); return Result.ok(page); }

查询逻辑里有个关键点：如果传了date参数，查询时要LEFT JOIN预订记录表，把当天已预订的时间段列表一并返回。前端拿到会议室数据后，直接渲染一个卡片列表，每张卡片上标注“今天空闲时间段：09:00-11:00，14:00-17:00”。

在Service层做这个联查时，我记得第一次写的时候踩了个坑：如果某会议室当天没有任何预订记录，LEFT JOIN会得到一条null记录，前端拿到的occupiedTimeRanges是null而不是空数组。处理方式是在VO里把occupiedTimeRanges初始化成空列表，或者用MyBatis-Plus的@TableField(fill = FieldFill.INSERT)自动填充，但这些细节问题要提前处理好。

3.3 时间冲突检测：这套系统的核心难点

会议室预订系统的灵魂就是时间冲突检测。很多第一次做这类项目的同学，检测逻辑写得一团糟：查出来当天所有预订，然后一条条写if判断。这么做能出结果，但边界情况容易漏，而且代码看着就不专业。

正确的检测思路是这样的：判断两条预订是否冲突，只有一种情况不冲突——新预订的开始时间 >= 已有预订的结束时间，或者新预订的结束时间 <= 已有预订的开始时间。也就是说，不冲突的条件是：

new_start >= existing_end 或 new_end <= existing_start

那么冲突条件就是：

new_start < existing_end 且 new_end > existing_start

等价于：

new_start < existing_end AND new_end > existing_start

这个判断一定要在数据库查询里做，不能把当天所有预订记录全查到内存里再循环判断。性能是一方面，更重要的是代码优雅。用MyBatis-Plus写这个条件：

LambdaQueryWrapper<Reservation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reservation::getRoomId, roomId) .eq(Reservation::getMeetingDate, meetingDate) .in(Reservation::getStatus, Arrays.asList(1, 2)) // 待审批和已批准都算占用 .lt(Reservation::getStartTime, endTime) // 已有的开始时间 < 新结束时间 .gt(Reservation::getEndTime, startTime); // 已有的结束时间 > 新开始时间 Integer count = reservationMapper.selectCount(wrapper); if (count > 0) { throw new BizException("该时间段已被预订，请更换时间或选择其他会议室"); }

这里注意一点：status字段必须加限定，把已取消和已拒绝的记录排除掉，否则会影响正确性。

表中字段start_time和end_time，在数据库里我用的是TIME类型，在Java实体里用LocalTime来接收。这样在做时间比较时，MyBatis-Plus会自动生成start_time < ?这样的SQL，不会出字符串比较的坑。

3.4 预订审批流设计：不搞复杂工作流，但要有状态机思维

企业场景里的会议室预订，一般不可能是纯自助。我设计了一套简单够用的审批流：

• 普通会议室：提交预订后，直接到管理员审批，状态变为“待审批”
• 大型会议室（容量 > 20人）：需要两级审批，先部门负责人审批，再到管理员审批
• 特殊时段（非工作时间）：直接拒绝，不进入审批流

这个规则在Service层通过策略模式实现。定义接口：

public interface ApprovalStrategy { boolean support(ReservationRequest request); void process(ReservationRequest request); }

然后实现三个策略类：NormalRoomStrategy、LargeRoomStrategy、SpecialTimeStrategy。通过一个策略工厂根据请求参数选择合适的策略。这种设计的好处是，如果你后面想加新规则，比如“跨部门会议需要两个审批人”，只需要新增一个策略类就行，不需要改原有代码。这就是答辩的时候可以和老师讲的“扩展性”。

审批操作本身就是一个状态流转，要重点考虑并发场景。比如管理员A和管理员B同时处理同一条预订，一个通过一个拒绝，怎么办？我的方案是：在审批记录表插入一条记录之前，用乐观锁检查当前预订状态：

Reservation reservation = reservationMapper.selectById(id); if (reservation.getStatus() != 1) { // 不是待审批状态 throw new BizException("该预订已被处理，请勿重复操作"); } reservationMapper.updateById(reservation); // MyBatis-Plus默认带乐观锁

3.5 统计报表模块：会议室使用率分析的SQL写法

统计报表是答辩时很讨巧的加分项。图纸上“系统能统计每个会议室的使用率”这句话，落在代码里其实就是几条SQL。主要做这几个统计：

会议室使用率（按月）

统计口径：某会议室当月已批准预订的总时长 / 会议室开放总工作时长。

SELECT room_id, SUM(TIMESTAMPDIFF(MINUTE, start_time, end_time)) / 60 AS used_hours FROM reservation WHERE status = 2 AND meeting_date BETWEEN '2025-06-01' AND '2025-06-30' GROUP BY room_id;

会议室开放工作时长，可以在会议室表里配一个字段work_hours_per_day，比如每天8小时，当月20个工作日，就是160小时。然后用used_hours除以160，就是使用率。

部门预订排行

统计哪个部门用的会议室最多，这个SQL很简单，按部门分组统计预订次数即可。

会议平均时长

SELECT AVG(TIMESTAMPDIFF(MINUTE, start_time, end_time)) AS avg_minutes FROM reservation WHERE status = 2;

统计报表的前端展示我用的是ECharts的饼图和柱状图，展示效果挺好。后端返回JSON数据，前端直接渲染，不需要额外的图表库配置。

4. 项目管理与开发交付

4.1 项目初始化与目录规划

开发开始之前，先花半小时把工程结构搭好，后面能少走很多弯路。

Spring Boot工程的pom.xml里，必装的依赖如下：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>cn.dev33</groupId> <artifactId>sa-token-spring-boot-starter</artifactId> <version>1.34.0</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson2</artifactId> <version>2.0.25</version> </dependency> </dependencies>

application.yml里几个关键配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/meeting_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 sa-token: token-name: satoken timeout: 86400 is-concurrent: true is-share: false

注意serverTimezone=Asia/Shanghai必须加，否则连MySQL会报时区错误。这是新手最容易踩的坑之一。

4.2 核心代码实现：后端Service层的完整示例

我挑三个核心的Service方法，完整贴出来，这样你可以直接对照着抄。

预订提交的完整逻辑

@Service public class ReservationServiceImpl implements ReservationService { @Autowired private ReservationMapper reservationMapper; @Autowired private MeetingRoomMapper meetingRoomMapper; @Override @Transactional(rollbackFor = Exception.class) public Long createReservation(ReservationRequest request) { // 1. 校验会议室是否存在并启用 MeetingRoom room = meetingRoomMapper.selectById(request.getRoomId()); if (room == null || room.getStatus() != 1) { throw new BizException("会议室不存在或已被停用"); } // 2. 校验预订时间合法性 if (request.getStartTime().isAfter(request.getEndTime())) { throw new BizException("开始时间不能晚于结束时间"); } LocalTime openTime = room.getOpenTime(); LocalTime closeTime = room.getCloseTime(); if (request.getStartTime().isBefore(openTime) || request.getEndTime().isAfter(closeTime)) { throw new BizException("预订时间不在会议室开放时段内"); } // 3. 时间冲突检测 LambdaQueryWrapper<Reservation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reservation::getRoomId, request.getRoomId()) .eq(Reservation::getMeetingDate, request.getMeetingDate()) .in(Reservation::getStatus, Arrays.asList(1, 2)) .lt(Reservation::getStartTime, request.getEndTime()) .gt(Reservation::getEndTime, request.getStartTime()); Integer conflictCount = reservationMapper.selectCount(wrapper); if (conflictCount > 0) { throw new BizException("该时间段已被预订，请更换时间或会议室"); } // 4. 组装预订记录并入库 Reservation reservation = new Reservation(); BeanUtils.copyProperties(request, reservation); reservation.setStatus(1); // 待审批 reservation.setUserId(StpUtil.getLoginIdAsLong()); reservationMapper.insert(reservation); return reservation.getId(); } }

会议室占用时间的查询

@Override public List<TimeRangeVO> getOccupiedRanges(Long roomId, LocalDate date) { LambdaQueryWrapper<Reservation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reservation::getRoomId, roomId) .eq(Reservation::getMeetingDate, date) .in(Reservation::getStatus, Arrays.asList(1, 2)) .orderByAsc(Reservation::getStartTime); List<Reservation> reservations = reservationMapper.selectList(wrapper); return reservations.stream() .map(r -> new TimeRangeVO(r.getStartTime(), r.getEndTime(), r.getMeetingTitle())) .collect(Collectors.toList()); }

这两个方法基本覆盖了预订模块最重要的业务逻辑。

4.3 前端页面实现：会议室预订页面的核心交互

前端这块不用把代码全贴出来，我挑最关键的预订交互逻辑说。

会议室列表页用Vue组件渲染，每个会议室卡片上有一个“预订”按钮。点击预约后，弹出对话框，用户选择日期、开始时间、结束时间，填写会议主题。选择日期后，前端要立即请求GET /api/rooms/{id}/occupied?date=xxx接口，拿到当天已经被占用的时间段，然后在前端做一次过滤，把不可选的时间在时间选择器里禁用掉。

Element Plus的el-date-picker组件，可以通过disabled-hours和disabled-minutes属性来禁用具体时间点。前端拿到占用时间段后，比如10:00-11:00被占了，那就在10:00、10:30这些时间点上禁用，用户就无法选择了。这是一种“前端提示+后端校验”的双保险做法，前端交互体验好，后端兜底保证数据正确性。

前端拦截的伪代码逻辑：

// 把占用时间段转换成不可选择的小时数组 const occupiedRanges = this.occupiedTimeRanges; const disabledHours = []; for (let hour = 8; hour <= 21; hour++) { const hh = hour < 10 ? '0' + hour : String(hour); for (const range of occupiedRanges) { const startHour = range.startTime.substring(0, 2); const endHour = range.endTime.substring(0, 2); if (hour >= parseInt(startHour) && hour < parseInt(endHour)) { disabledHours.push(hour); break; } } }

4.4 “完整交付物”包含什么：论文、LW、调试定制

标题里写了“完整前后端代码+说明文档+LW”，这里我要给毕设的同学提个醒：一套完整的毕设交付物，远远不止源码，通常包含以下四块：

源码与数据库脚本：完整可运行的前后端工程代码、SQL初始化脚本，包括建库建表语句和初始数据。如果你的环境有问题，还得有配套的环境安装文档。

说明文档：包括项目介绍、技术选型、环境搭建步骤、功能演示说明。我见过不少同学的说明文档写得极简，就两页纸，答辩的时候老师问“你的系统怎么跑起来”，他答不上来。把运行步骤写清楚，是对自己负责。

LW（即论文）：论文结构通常包括：选题背景和意义、国内外研究现状、需求分析、系统设计（架构图、功能模块图、数据库ER图）、系统实现（截图+代码描述）、系统测试、总结与展望。这个结构是固定的，主题不要偏，把“复合型活动基地”、“面向企业用户”、“会议管理系统”这三个关键词在论文里反复强化。

演示视频与答辩PPT：录一段系统演示视频，主要功能都操作一遍，建议用OBS录屏，画质清晰，标注关键操作步骤。答辩PPT控制在10页左右，不要贴大段代码，多用架构图、功能截图和数据流图。

调试定制这块，我想多说一句：你在实际做项目时会发现，前后端联调是最大的时间黑洞。后端接口返回的数据结构和前端预期不一致、跨域没配好、日期格式解析失败……这些问题一调就是一下午。我的经验是：先定好接口返回数据结构，前后端并行开发，定期联调。接口文档用Apifox或者Postman维护，每个人改动接口都要同步更新文档。

5. 常见问题与调试经验

5.1 时间字段比较的坑

这是会议室预订系统里最容易翻车的点。MySQL的TIME类型，在Java里如果用String接收，会出现一个经典问题："09:00"和"9:00"虽然语义一样，但字符串比较结果不同。更危险的是，如果你把TIME映射成了LocalTime，在SQL里生成的条件是start_time < '10:00'，MySQL会自动把字符串转成TIME，不会出错。

但有个场景会翻车：如果你用String接收，然后用compareTo做时间比较，那你得到的结果基本是靠运气。解决方法是：实体类中时间字段全部用LocalTime，前端传参时用HH:mm格式，JSON序列化时配置@JsonFormat(pattern = "HH:mm")。

5.2 跨域配置的正确姿势

前后端分离的情况下，跨域问题基本都会遇到。正确配置方式是写一个WebMvcConfigurer的CorsRegistry：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意：allowCredentials(true)和allowedOriginPatterns("*")要配套使用，如果只写了allowedOrigins("*")，带凭证的请求会报错。

如果你用了Sa-Token，还要注意一个细节：Sa-Token的拦截器会拦截OPTIONS请求，导致跨域预检失败。解决办法是在拦截器配置时，把OPTIONS请求放行：

registry.addInterceptor(new SaInterceptor(handle -> { if (handle.getRequest().getMethod().equals("OPTIONS")) { return; } StpUtil.checkLogin(); })).addPathPatterns("/**");

5.3 MyBatis-Plus逻辑删除导致的查询异常

如果你启用了MyBatis-Plus的逻辑删除（logic-delete-field: deleted），那么所有查询都会自动带上deleted = 0的条件。在写复合查询的时候，如果用了自定义SQL（比如@Select注解），逻辑删除的自动拼接可能不生效，你要自己手动加上deleted = 0。我踩过一次坑：会议室列表一直查询出来是空的，排查了半天，才发现是自定义SQL没带逻辑删除条件。

5.4 端口占用与启动失败

java -jar启动的时候报端口被占用，先执行netstat -ano | findstr 8080查看占用进程的PID，然后在任务管理器里结束对应进程；或者直接改application.yml里的server.port。这种情况经常发生在反复启动调试的时候，不复杂，但很烦人。

服务器上部署时，MySQL数据库可以连接不通。主要原因有两类：一是MySQL没启动，二是配置文件里的url写错。jdbc:mysql://localhost:3306/meeting_system这里的3306是MySQL默认端口，如果你安装时改过端口，务必同步修改。

5.5 演示现场环境问题的应急方案

毕设答辩和演示的时候，最怕电脑出问题。我总结了三条建议：

• 提前一天用java -jar把后端启动，浏览器打开前端页面，完整走一遍主流程，确认没问题
• 数据库导出SQL脚本，在U盘里备一份，如果现场MySQL挂了，可以快速重建数据库
• 前端建议打包成静态文件放在后端的resources/static目录下，这样启动一个服务就能访问完整系统。具体做法可以参考“vue打包放进springboot”的那个思路——把Vue工程的dist目录内容复制到Spring Boot的src/main/resources/static下，后端启动后直接访问8080端口就能看到前端页面。这是最稳妥的演示方案。

6. 可扩展方向与个人体会

6.1 往这个系统上还能加什么功能

如果你的时间有富余，想把这个毕设做得更有亮点，这几个方向值得考虑：

消息通知模块：预订状态变化时，通过邮件或者短信提醒用户。这个功能不需要写死，先做个邮件通知就够了。用Spring Boot的spring-boot-starter-mail，配置好邮箱SMTP，代码就十几行。这是“锦上添花”的功能，但答辩的时候说“我们提供了邮件自动通知服务”，档次立马上来了。

二维码签到：给每场会议生成一个二维码，参与人扫码签到。这个用Google ZXing库生成二维码，存到数据库里，前端展示，扫码后把状态改成“已签到”。功能不复杂，但能体现移动化思维。

会议纪要模块：每次会议结束后，用户可以上传会议纪要文件（PDF、Word），关联到预订记录上。这个东西解决“会议结束后的资料归属”问题，也是企业场景的真实需求。

大屏展示：如果基地有运营大屏，可以做一版大屏可视化页面，用ECharts展示当前各会议室使用状态、今日会议数量、本月使用率排行。大屏页面以炫酷为主，多用一些深色背景+发光边框的样式设计，答辩效果很好。

6.2 命名规范与代码习惯：面试官会很看重的东西

最后说一点可能听着老生常谈但实际很重要的东西。我审过不少Java毕设的代码，很多项目功能做出来了，但是代码风格惨不忍睹：类名大饼一样拼在一起、方法名和参数名没有语义、Controller里塞了几百行SQL、Service方法又长又臭。哪怕功能全通，论文写得也还行，但代码这关一旦被细问，就会暴露问题。

几个基本要求你做到，就算出彩了：

• 类名大驼峰，方法名小驼峰，常量全大写下划线分隔
• Controller别写业务逻辑，只做参数接收和结果返回
• 异常统一抛出BizException，在全局异常处理器里统一捕获
• 每一个Service方法，写完以后回头读一遍，看能不能用一句话说清楚它在干什么。说不清，说明逻辑太复杂，需要拆分

我自己的习惯是写代码前先画一张“状态流转图”贴在显示器旁边，比如预订状态从“待审批”到“已批准”到“已完成”，哪些操作能触发状态变化，画清楚再写代码，效率高很多。

6.3 写在最后的一些建议

做这个项目下来，我最大的体会是：会议室预订系统看似简单，但它是把企业真实业务的一个缩影——有资源管理、有权限控制、有状态流转、有冲突处理、有数据统计，每块都不算难，叠在一起就考验你的系统思维和代码组织能力了。

如果你现在正在做这个选题，我给你的行动建议是：先把数据库的表建好，再写后端接口，接口都通了再写前端页面，最后写论文。不要一上来就研究Vue的动画效果或者研究Sa-Token的高级玩法，先把主流程跑通，后面的优化才有意义。

碰到调试不动的情况，先看后端日志。Spring Boot的日志默认会打印SQL（前提是你配了log-impl: StdOutImpl），看到SQL就能定位问题一大半。别盯着浏览器控制台看，前端报错很多时候只是表象，真实原因在后端接口返回的数据里。

我做过的类似系统里，会议室预订这个需求我还扩展过空间管理（把会议室、工位、停车位都纳入资源池）和会议服务关联（茶水、投影、速记服务一并下单）的版本。如果以后你到企业里做类似的后台系统，这套思路完全可以平移过去——核心都是“资源-时间-人”三者的关系处理。

希望这篇写得够细，你能从中找到可以抄作业的部分，也希望能帮你避掉几个我当年踩过的坑。动手写起来吧，代码这东西，看十篇博文不如自己跑通一个接口来得实在。