1. 项目整体设计与思路拆解
1.1 课题背景与Why：咖啡厅为什么需要座位预约
先说结论：咖啡厅座位预约管理系统，本质上解决的是“座位供需在时间维度上的错配问题”。很多没开过店的朋友可能会觉得，咖啡厅座位预约不就是个“在线取号”嘛，用得着单独做个系统？但实际上，你只要在高峰期走进一家热门咖啡厅就会发现，真实痛点远比想象中复杂——客人到店发现没座、有人占着四人桌喝一杯美式聊一下午、预约用户到店发现座位被占、店员靠手写本子记录预约信息经常漏记错记，这些问题单靠“排队叫号”根本解决不了。
我做这个课题时，梳理下来核心要解决三件事：
- 座位可视化：让用户在线上就能看到哪些座位空闲、哪些被占用，而不是到店碰运气。
- 预约冲突检测：同一个座位在同一时间段，绝不能分配给两个用户，这是整个系统的核心业务规则。
- 到店履约管理：预约不是“约了就完事”，还要处理取消、超时未到、到店核销等状态流转。
这个课题的定位很清晰：它既不是纯电商系统，也不是纯进销存系统，而是一个“资源时间片管理”系统。咖啡厅的“座位”就是核心资源，“时间片”就是资源可以被预约的粒度。理解了这层本质，后面所有表结构设计和业务逻辑设计都会围绕“座位”和“时间片”展开，而不是像普通电商那样围绕“商品”和“订单”展开。
1.2 技术选型：为什么是SpringBoot而不是其他
选SpringBoot作为基础框架，放在今天来看仍然是做这类业务系统的首选，原因很实在。
第一，开发效率。SpringBoot通过自动配置（Auto Configuration）把Spring家族繁琐的Bean配置和XML配置大量简化，你引一个spring-boot-starter-web依赖，内置Tomcat，写一个@RestController就能跑起接口。做毕设或者做企业内部的小型业务系统，核心诉求就是“快速把业务跑通”，而不是从零搭一套配置地狱。SpringBoot内置的配置项基本覆盖了数据源、Redis、定时任务、模板引擎这些常用场景，开发节奏会舒服很多。
第二，生态成熟度。做座位预约系统必然要涉及用户认证、数据持久化、缓存、定时任务、前端联调，这些场景SpringBoot都有非常成熟的starter支持——Spring Security或JWT做认证、MyBatis-Plus做持久层、Spring Data Redis做缓存、@Scheduled做定时任务。遇到问题搜索引擎一搜一大把，踩坑成本极低。
第三，前后端分离的天然适配。现在做这类系统基本都会采用前后端分离模式，SpringBoot天然适合只做后端API，返回JSON数据，前端用Vue、小程序甚至H5都无所谓。我在最初设计时就直接确定用SpringBoot + Vue前后端分离的架构，后端只管业务逻辑和数据，前端只管展示和交互，两者通过RESTful API通信，开发和调试时可以完全并行，效率比单体JSP方案高出一大截。
有人可能会问，为什么不选SSM（Spring + SpringMVC + MyBatis）或者SpringCloud？我的想法是：SSM的配置成本太高，对新手不友好；SpringCloud微服务对单机部署的咖啡厅场景来说纯属过度设计。做项目讲究“技术选型服务于业务复杂度”，一个中小型管理系统的复杂度，SpringBoot单机应用完全扛得住，再加Redis做缓存优化性能，性价比恰好。
1.3 功能拆解与角色边界
整个系统按用户角色分为两端，每个角色的功能边界必须一开始就划清楚，否则后面开发会扯皮。我实际设计时是这样拆的：
用户端（普通用户/顾客）：
- 注册登录：手机号或用户名注册，密码加密存储。
- 座位浏览：按区域、时段、容量筛选可预约座位，可视化展示座位状态。
- 在线预约：选择座位、时间段，提交预约。
- 我的预约：查看历史预约、取消未开始的预约、查看预约状态（待核销/已核销/已取消/已过期）。
管理端（咖啡厅管理员）：
- 座位管理：新增、编辑、删除座位，设置座位编号、区域、容纳人数、座位类型（单人桌、双人桌、卡座等）。
- 预约管理：查看全部预约记录，支持按日期、状态筛选；可手动取消预约。
- 核销管理：到店核销预约订单（扫码或手动核销）。
- 数据统计：按天/周/月统计预约量、到店率、热门座位、高峰时段等。
这里有一个细节特别注意：座位状态和预约状态是两个维度的概念，不能混为一谈。座位状态是实时物理状态（空闲/待核销/占用），预约状态是业务状态（已预约/已核销/已取消/已过期）。一对多的关系——一个座位在不同时间段可以有多个预约记录，但同一时间片只能有一个有效预约。这个设计要是没想清楚，后面写冲突检测一定会出逻辑漏洞。
2. 核心技术点解析与选型思考
2.1 SpringBoot自动装配原理：项目“零配置”背后的逻辑
SpringBoot刚上手的时候，很多人都觉得“明明啥都没配，为什么依赖就能用”？我一开始也好奇，后来研究了一下，其实搞清楚自动装配（Auto Configuration）原理之后，你对整个框架的掌控感会完全不一样。
SpringBoot启动类上的@SpringBootApplication注解，实际上是一个组合注解，核心是@EnableAutoConfiguration。这个注解会去加载META-INF/spring.factories文件里声明的所有自动配置类（在SpringBoot 2.7+版本改成了AutoConfiguration.imports文件）。自动配置类上通常带有@ConditionalOnClass、@ConditionalOnMissingBean之类的条件注解，意思就是：“当classpath里有某个类的依赖时，我就自动配置对应的Bean；如果你已经自己定义过这个Bean，我就不覆盖。”
以数据源为例：你引入spring-boot-starter-data-jpa或MyBatis相关依赖后，classpath里会出现DataSource相关的类，DataSourceAutoConfiguration等配置类就会自动生效，再结合你在application.yml里配置的spring.datasource.url、username、password，框架就能自动创建数据源对象。
理解了这个原理之后，你在做项目时至少有两个实际好处：第一，遇到“为什么我改了配置没生效”这类问题，会习惯性去查是不是条件注解没满足；第二，如果有些自动配置你不想要，可以用exclude属性排除，比如@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)。另外补充一句，SpringBoot版本差异在某些合并的依赖管理上会有影响，当时用到的自动配置机制在2.x和3.x之间也有一些模块调整，遇到了就去查对应版本的官方文档，比自己瞎猜快得多。
2.2 数据库选型与表结构设计：座位预约的核心是“时间片”
数据库层面我选的是MySQL，理由不用多说——通用、稳定、资料多。但表结构设计才是这块的重点，我花了很长时间反复改，最终设计出以下核心表：
用户表（user）
- 主键id、用户名、密码（BCrypt加密存储）、手机号、昵称、头像、创建时间。
座位表（seat）
- 主键id、座位编号（seat_no，如A01、B02）、所在区域（area）、座位类型（type，单人/双人/四人/卡座）、容纳人数（capacity）、座位描述、状态（status，0禁用 1启用）、创建时间。
设计时一定要把“座位编号”设为唯一索引，因为用户在前端界面看到的就是座位的编号，按编号检索比按主键id检索更直观。座位类型和容纳人数要分开存，因为有可能存在“双人桌但可容纳4人”的灵活情况。
预约表（reservation）
- 主键id、预约单号（reservation_no）、用户id（user_id）、座位id（seat_id）、预约开始时间（start_time）、预约结束时间（end_time）、预约日期（reserve_date）、状态（status：0待核销/1已核销/2已取消/3已过期）、创建时间、更新时间。
预约表是整个系统的核心，索引设计非常关键。我当时建立了联合索引(seat_id, status, start_time, end_time)，因为查询很快就能命中索引，同时把start_time和end_time这种查询条件字段落在索引里，避免回表。
为什么不把座位表和预约表合并？因为座位是一个相对稳定的物理实体，预约是不断新增的记录流，合并会导致大量冗余和更新异常。保持一对多关系，一个座位对应多条预约记录，才能支撑“同一座位不同时间段多次预约”的业务模型。
2.3 Redis缓存与并发控制：防止“一座多约”的硬仗
咖啡厅预约最怕的就是双十一式的并发场景——两个用户同时抢同一个座位、同一个时间段，结果都预约成功了。处理这种并发冲突，我一开始用的是数据库层面的排他校验：在插入预约记录前查询有没有重叠的有效预约。这个方案在低并发下没问题，但在高并发下会有严重的性能瓶颈——查询和插入之间存在时间窗口，两个请求可能同时通过校验。
我后来采用了两层控制：
第一层，Redis预占座。用户发起预约时，先在Redis里设置一个key，比如seat:1001:2024-01-01:14:00-16:00，用setIfAbsent（SETNX）命令尝试写入。如果写入成功，说明这个时间片还没有被抢占；如果写入失败，说明已被其他用户预占，直接返回“该时段已被预约”。这个操作是原子性的，可以在毫秒级完成，有效挡住大部分并发请求。
第二层，数据库最终校验。当Redis预占成功后，再执行数据库侧的时间重叠校验，确认确实没有冲突后插入预约记录。这里用的是数据库的悲观锁（SELECT ... FOR UPDATE）——查询重叠预约时把相关座位记录锁住，其他事务必须等待，直到当前事务提交。虽然性能有损耗，但保证了最终一致性。
这里的坑点在于：Redis预占座位的时间要设置一个合理的过期时间（比如5分钟或10分钟），防止用户发起预约后一直不提交或中途崩溃，导致key永远占着不放。我当时设置的是预约时间段的开始时间作为自动过期时间，同时配合定时任务扫描清理已过期但状态未更新的预约记录。
2.4 时间重叠冲突检测：这个逻辑你绕不开
时间重叠检测是预约系统的算法核心，公式其实很简单：判断两条预约（起始时间s1, 结束时间e1）和（起始时间s2, 结束时间e2）是否重叠，条件是NOT (e2 <= s1 OR s2 >= e1)，展开等价于s2 < e1 AND e2 > s1。注意边界条件是开区间还是闭区间需要约定好，我当时的约定是“结束时间不被占用”，也就是说一个预约到14:00结束，另一个预约14:00开始，两者不冲突。所以在SQL里写的是start_time < ? AND end_time > ?，其中？是查询区间的开始和结束时间。
这条SQL虽然简单，但容易踩坑的地方是查询状态条件——不能把所有预约记录都拿出来做内存比较，否则数据量一大就废了。正确的姿势是在SQL层面加WHERE seat_id = ? AND status IN (0, 1) AND start_time < 传入结束时间 AND end_time > 传入开始时间，然后LIMIT 1，只要查出一条就说明有冲突。数据库层面查不到才算真正没有冲突。
3. 实操过程与核心环节实现
3.1 项目环境准备与初始化
我的开发环境如下，供参考：
- JDK 1.8（如果你用Spring Boot 3.x，就必须JDK 17+，我当时用的是2.7.x所以JDK8完全够用）
- IDEA 2022+
- Maven 3.8+
- MySQL 5.7+
- Redis 6.x
- Vue 2.x + Element UI
创建项目时推荐直接去Spring Initializr（start.spring.io）生成基础工程，选择Web、MySQL、MyBatis相关依赖，或者用IDEA自带的Spring Initializr插件。生成完后把pom.xml里的关键依赖补充完整，核心依赖如下：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.83</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency>这里提醒一下：JWT依赖不要忘记引入，否则后续做登录认证时还得再补。建议一次性把依赖补齐，项目跑起来之后再补依赖虽然也能行，但会打断写代码的思路。
3.2 项目结构分层设计
我采用的是经典三层结构，但为了后续扩展和上线部署，加了config、common、dto等包：
com.cafe.reservation ├── config // 配置类：CORS配置、Redis配置、MyBatis配置 ├── controller // 控制层：接收前端请求 ├── service // 业务层：业务逻辑处理 ├── mapper // 数据访问层：MyBatis的Mapper接口 ├── entity // 实体类：对应数据库表 ├── dto // 数据传输对象：请求参数和响应结果 ├── common // 公共类：统一返回结果、异常处理、JWT工具类 ├── utils // 工具类：日期处理、Redis工具等 └── ReservationApplication.java // 启动类这个结构从Service层到Mapper层再到Controller层，职责清晰，不会出现业务逻辑写在Controller里的灾难。特别提醒：Controller里永远只做参数接收、参数校验、调用Service、返回结果，不要写SQL、不要写计算逻辑，不然项目一大基本没法维护。
3.3 application.yml配置：这几项配置我踩过坑
创建好项目后，第一个重点工作就是把application.yml配置好：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/cafe_reservation?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 database: 0 timeout: 3000ms jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这里有几个细节值得展开说一下：
serverTimezone=Asia/Shanghai这个参数非常容易踩坑。MySQL 8.x的时区默认是美国时区，如果不设置，你存入数据库的时间会比北京时间早8个小时。如果你在本地开发环境遇到查询出来的时间差8小时，先检查这里，别先去怀疑Jackson或者LocalDateTime的配置。- MyBatis-Plus开启
map-underscore-to-camel-case后，数据库字段start_time才能自动映射到实体类的startTime，如果你没开这个配置，要么全部字段用下划线命名，要么每个字段都加@TableField注解，非常麻烦。 - 开发阶段把SQL日志打开（
StdOutImpl），会方便非常多。上线前再把这个日志关掉，不然对性能有影响。 - Jackson的全局时间格式统一成
yyyy-MM-dd HH:mm:ss，避免前端拿到的时间戳还得自己格式化。如果某个字段需要带毫秒级精度，再用@JsonFormat单独指定。
3.4 用户注册登录实现：JWT + BCrypt的完整方案
用户模块是所有业务模块的基础，我实现的是基于JWT的认证方案，和传统Session方案相比，优势很明显：无状态、不占Session内存、天然适合前后端分离。
密码存储必须用BCrypt加密，不能用MD5。MD5虽然哈希不可逆，但撞库攻击和彩虹表攻击的风险太高，BCrypt内置随机盐，相同密码加密后的密文都不同，安全性高一个数量级。Spring Security中自带BCryptPasswordEncoder，但如果你没有引入Spring Security全家桶，也可以直接引入spring-security-crypto包单独使用，代码很简单：
BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); // 注册时加密存储 String encodedPassword = encoder.encode(rawPassword); // 登录时校验 boolean matched = encoder.matches(rawPassword, encodedPassword);登录成功后生成JWT：
String token = Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(secretKey) .compact();前端拿到token后存在localStorage或cookie里，每次请求在Header 加Authorization: Bearer <token>。后端用拦截器统一校验token有效性，把userId放入ThreadLocal，方便后续业务逻辑获取当前用户。这个思路和很多主流项目的做法一致，实测下来开发效率和安全性都比较理想。
3.5 座位管理模块：管理员端的CRUD与座位状态联动
座位管理相对简单，就是标准的CRUD操作。用MyBatis-Plus的IService和ServiceImpl封装好的方法，不需要自己写SQL：
// 新增座位 boolean save = seatService.save(seat); // 分页查询 Page<Seat> page = seatService.page(new Page<>(current, size), wrapper); // 根据id修改 boolean update = seatService.updateById(seat); // 删除座位（优先做逻辑删除） boolean remove = seatService.removeById(id);但要强调的是座位状态和预约状态的联动：当一个座位有进行中或待核销的预约时，这个座位不能被管理员直接删除或禁用，因为这样会影响到已经预约的用户。我当时的处理方式是在删除前先查询预约表中有没有这个座位的有效预约记录：
long count = reservationMapper.selectCount( new LambdaQueryWrapper<Reservation>() .eq(Reservation::getSeatId, seatId) .in(Reservation::getStatus, 0, 1) ); if (count > 0) { return Result.error("该座位存在未完成的预约，无法删除"); }这个限制要在Service层强制，保证业务完整性，不能只依赖前端按钮的禁用状态。
3.6 预约流程实现：从预占到最终落库的完整链路
预约接口是整个系统的核心中的核心，我以一个用户预约为例，说完整链路。
第一步，参数校验：校验时间是否符合规则，比如不能预约过去的时间、预约时长不能超过系统上限。
第二步，座位状态检查：查座位是否启用（status=1），查这个座位是否已被删除。
第三步，Redis预占座：
String key = "cafe:seat:" + seatId + ":" + reserveDate + ":" + startTime + "-" + endTime; Boolean success = redisTemplate.opsForValue().setIfAbsent(key, userId.toString(), Duration.ofMinutes(10)); if (Boolean.FALSE.equals(success)) { return Result.error("该时间段已被预约，请选择其他时间"); }第四步，数据库冲突校验：
Reservation existing = reservationMapper.selectOne( new LambdaQueryWrapper<Reservation>() .eq(Reservation::getSeatId, seatId) .in(Reservation::getStatus, 0, 1) .lt(Reservation::getStartTime, endTime) .gt(Reservation::getEndTime, startTime) .last("LIMIT 1") ); if (existing != null) { redisTemplate.delete(key); return Result.error("该时间段已被预约，请选择其他时间"); }第五步，插入预约记录：
Reservation reservation = new Reservation(); reservation.setReservationNo(generateReservationNo()); // 生成唯一业务单号 reservation.setUserId(userId); reservation.setSeatId(seatId); reservation.setStartTime(startTime); reservation.setEndTime(endTime); reservation.setReserveDate(startTime.toLocalDate()); reservation.setStatus(0); reservationMapper.insert(reservation);第六步，异步通知（可选）：通过消息队列或定时任务向前端推送预约成功通知。因为这是课程设计/毕设级别的系统，我直接用了WebSocket推送座位状态变化，实时性体验好很多。
这里要提醒一个容易忽略的点：生成预约单号时要注意并发唯一性。我当时采用yyyyMMddHHmmss + 随机数 + 用户ID后四位的格式，并在数据库里对reservation_no加了唯一索引，双重保险。
3.7 定时清理过期预约：用Spring Schedule实现
预约状态为“待核销”的订单如果在预约开始时间之后一直没到店核销，需要自动变为“已过期”。用Spring自带的@Scheduled定时任务就能搞定，不需要引入额外的调度框架：
@Scheduled(cron = "0 */5 * * * ?") // 每5分钟执行一次 public void updateExpiredReservations() { LocalDateTime now = LocalDateTime.now(); reservationMapper.updateExpired(now); }对应的SQL是：
UPDATE reservation SET status = 3 WHERE status = 0 AND start_time < #{now}每隔5分钟把已到预约开始时间但仍未核销的记录批量置为过期状态。@Scheduled需要启动类加@EnableScheduling注解，这个细节非常容易被忽略。实际开发中如果你不想引入额外的框架，Spring自带的定时任务对单机应用来说真的完全够用。
这个定时任务上线后有一个体验问题要提前想好：如果用户预约了14:00到15:00的座位，结果14:20才到店，此时预约已经被置为“已过期”，管理员无法正常核销。我后来加了一个“宽限期”机制——到预约开始时间后仍允许核销30分钟，超过30分钟才标记为过期。这个调整对实际业务来说更合理，也和现实中咖啡厅的人性化管理逻辑一致。
4. 常见问题与排查技巧实录
4.1 时间差8小时问题：从数据库连接到JVM一个都别放过
这个是我在开发中实实在在踩过、也帮很多同学排查过的经典问题。现象就是：前端显示时间比实际时间少8小时或多了8小时。排查路径按照下面顺序看：
- 数据库连接URL：确认
serverTimezone=Asia/Shanghai有没有加。 - MySQL全局时区：执行
SELECT @@global.time_zone, @@session.time_zone;查看数据库时区。如果是SYSTEM，要确认系统时区本身就是Asia/Shanghai。 - JVM时区：在启动参数中加
-Duser.timezone=Asia/Shanghai。 - Jackson序列化时区：检查
application.yml里的time-zone: GMT+8，只写date-format不写time-zone的话，序列化出来的时间可能是UTC标准时间。
如果上面都排查完还没解决，最后检查实体类字段类型：如果你用java.util.Date，查询拿到的时间是Date类型，会被Jackson转换成时间戳再格式化；如果你用LocalDateTime，MyBatis的映射逻辑和java.util.Date不一样，容易出时区偏移。我最终的方案是：数据库字段用datetime，实体类用LocalDateTime，配合连接URL的serverTimezone=Asia/Shanghai，Jackson配置GMT+8，实测下来没有任何偏移。
4.2 并发预约超卖问题：从“直觉方案”到“靠谱方案”
在我最初写的版本里，冲突校验和插入是两个先后独立的操作，结果我用JMeter模拟50个并发请求预约同一个座位同一个时间段，最终有3个请求都返回“预约成功”——典型的超卖问题。原因就是并发请求同时通过了冲突校验，然后相继插入记录。
优化后的方案就是前面提到的“Redis预占座 + 数据库乐观锁”双层控制。这里我再展开讲一下为什么只靠数据库的UNIQUE约束不行——因为预约冲突的条件是时间区间重叠，你无法对“时间区间不重叠”建立简单的唯一索引。必须靠锁或预占机制来保证原子性。
当然，对于课程设计和毕设场景，如果你的系统并发量不大（比如小于10QPS），那么只用数据库查询+插入也是勉强能跑的。但是我一贯的原则是：作为系统性学习，把并发控制的方法学会，会让你的系统比别人高一个档次，面试时也更有东西聊。
4.3 MyBatis-Plus LambdaQueryWrapper几个易错点
MyBatis-Plus的LambdaQueryWrapper很好用，但还是有些细节值得注意：
第一，in函数（不是eq）不要写错。第二，last("LIMIT 1")是在SQL末尾拼接，但如果你前面已经用了limit相关方法就冲突了。第三，eq、lt、gt这些方法的参数顺序别搞混：lt(字段, 值)表示“字段值 < 值”，不要反了。
还有几个更隐蔽的坑：lambdaUpdate().set()更新时，如果前端传过来的实体类是null，MyBatis-Plus默认不会把null字段更新到数据库里（默认策略是NOT_NULL），所以更新操作基本不会误清空字段，这既是好事也是坑——如果你真的想把某个字段置为null，得手动指定UpdateStrategy。另外selectCount返回的是Long类型（新版本）而不是Integer，直接赋值给int会编译报错，强迫症别把它改成long。
做分页时记得配置MyBatis-Plus的PaginationInnerInterceptor，不配置分页插件的话，page()方法查出来的其实是全量数据然后内存分页，数据量小看不出来，数据量大起来性能直接崩掉。
4.4 前后端联调跨域问题：CORS的合理配置
前后端分离模式下，前端跑在http://localhost:5173，后端跑在http://localhost:8080，跨域问题几乎一定会遇到。解决方式很简单，在后端加一个CORS配置类：
@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)和allowedOrigins("*")不能同时使用，浏览器会拒绝这种配置。要允许携带Cookie和跨域凭证，就必须用allowedOriginPatterns("*")，而不是allowedOrigins("*")。
还有一个细节：如果你用了登录拦截器，一定要把OPTIONS请求放行，因为跨域预检请求（preflight request）就是发OPTIONS，你如果拦截了它，跨域请求永远过不去：
if (HttpMethod.OPTIONS.equals(request.getMethod())) { chain.doFilter(request, response); return; }4.5 JWT拦截器放行路径的常见配置问题
使用拦截器校验登录态后，最容易出的一个问题是前端页面白屏或登录接口401。原因是拦截器把登录、注册、座位列表、座位详情这些不需要登录的接口也拦截了。正确做法是使用WebMvcConfigurer的addInterceptors时配置excludePathPatterns：
registry.addInterceptor(jwtInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/user/register", "/api/seat/list", "/error");还有一个容易被忽略的点：你的定时任务或内部工具类调用的接口如果在Controller层，也会被拦截器拦。所以内部调用接口不要走Controller，直接在Service层调用，或者给这些接口单独加一个内网前缀，配合拦截器过滤掉。我在开发定时清理任务时就没走Controller，直接在Service层写了一个@Scheduled方法，避免被JWT拦截器误伤。
4.6 接口安全与密码加密的进阶思考
关于接口安全，至少有两点我建议在课题中体现出来，这也是答辩时很容易被老师问到的点。
第一，密码绝不能明文存储。前面已经提到用BCrypt加密，这个没什么可犹豫的。有人说那我用MD5加密呢？也能做，但容易被彩虹表破解。我实测过，同一个密码用MD5加密得到的密文完全相同，批量撞库后很容易得到原始密码；而BCrypt因为每次随机盐不同，密文完全不同，同样的密码存两条记录密文都不一样，碰撞难度大了很多。
第二，参数校验要放在Service层而不能只依赖前端。前端做了校验，如果用户绕过前端直接发HTTP请求，还是可能提交非法数据。所以后端Service层同样要做时间非空、时间先后顺序、时长上限、座位是否存在等校验。参数校验、业务校验、并发校验，这三层校验一个都不能少。
5. 项目开发流程与进度管理建议
5.1 从开题到答辩的6周节奏安排
作为开题报告也是毕业设计的选题，很多同学拿到题目后最大的疑问是“我该怎么安排时间”，我按自己的经验帮你理了一份实际可执行的节奏表，给你做个参考：
- 第1周：需求分析与架构设计。明确角色、功能模块、数据库表初步设计，画出核心用例图和ER图（也可以理解为业务概念图）。这一周的目标是让自己和指导老师都对“系统到底是做什么的”形成完全一致的认知，别急着写代码，想清楚再动手。
- 第2周：项目初始化与基础环境搭建。创建SpringBoot工程，配置数据库连接，实现用户注册登录模块，把JWT拦截器跑通，确保前后端能够正常联调。这一周的里程碑是“项目能跑起来”。
- 第3周：座位管理模块与座位列表展示。后端实现座位CRUD、座位状态查询接口，前端实现座位可视化展示。周报里程碑是“管理员能管座位，用户能看到座位”。
- 第4周：预约模块与冲突检测逻辑。这是整个项目最核心的部分，实现预约接口、取消预约、我的预约列表，并发冲突校验也从数据库校验升级到Redis预占座方案。周报里程碑是“能预约，且不会超卖”。
- 第5周：核销、统计、定时任务与优化。上线核销功能，用
@Scheduled实现预约过期处理，扩展数据统计模块。周报里程碑是“预约闭环完整”。 - 第6周：测试、文档、部署与答辩准备。编写功能测试用例，整理项目文档（数据库设计说明、用户手册、项目总结），尝试Docker部署，写答辩PPT。周报里程碑是“系统可演示、文档可提交”。
5.2 Docker部署：从本地到服务器的最后一公里
很多同学的毕设止步于“本地能跑”，实际上用Docker把项目部署到云服务器上，不仅让课程设计看起来完整很多，也会让你自己对项目的理解上一个台阶。
SpringBoot项目的Dockerfile其实不复杂：
FROM openjdk:8-jre-alpine WORKDIR /app COPY target/cafe-reservation-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]配合docker-compose.yml把MySQL和Redis也编排进去，一条docker-compose up -d就能启动整套服务。部署时需要注意服务器内存，如果只有2G内存，MySQL+Redis+Java应用极限操作会比较紧张，可以把JVM堆内存调小一点，比如-Xmx512m：
ENTRYPOINT ["java", "-Xmx512m", "-jar", "app.jar"]这个环节对没有服务器实操经验的同学来说，可能需要踩一些连接、防火墙、安全组的坑，但README里写出部署步骤，对整个项目的完整性帮助极大。
5.3 课题的局限性——我做了什么取舍
没有任何系统是完美的，我也在这个课题里做了一些取舍，顺便说清楚哪些地方是被“课程设计/毕设”这个场景限制住的：
- 没有做消息队列：预约成功后的短信/邮件通知，我直接用了WebSocket推送，完全够用。引入RocketMQ或RabbitMQ需要额外的Broker，对单机项目来说太重了，而且会增加环境搭建复杂度。
- 没有做微服务拆分：单机应用把所有业务模块放在一个进程里，对于咖啡厅座位预约这种中小型业务量完全足够。微服务带来的服务发现、负载均衡、分布式事务等复杂度在这个场景下毫无必要。
- 没有做复杂权限模型：系统的角色只有普通用户和管理员两种，用JWT中的角色字段区分即可，没有引入Spring Security复杂的权限注解体系。
- 没有做退款支付流程：座位预约在真实商业化场景可能涉及预付款、押金、退款等流程，我只实现了预约履约环节，没有接入支付网关。
这些取舍的本质是“用最小成本满足核心需求”。如果你做的是毕业设计，这个大方向是完全对的——把核心业务闭环做扎实，比堆砌一堆华而不实的技术点更有价值。
6. 写在最后：一点实操心得
做完这个SpringBoot咖啡厅座位预约管理系统，我最深的体会是：一个项目的成败，不取决于你用了多少新技术，而取决于你把核心业务逻辑想得多清楚。座位预约的核心就是“资源的时间片管理”，只要把时间冲突检测、并发控制、状态流转这三件事想透，系统就成功了一大半。
另外有一个非常实用的建议给正在做类似项目的同学：所有时间字段一律用LocalDateTime，所有状态字段一律用数字枚举并写清楚注释，所有数据库表必须加上create_time和update_time。这三条规约我实测下来可以帮你省掉后面至少一半的调试时间。
如果你打算在这个课设基础上继续扩展，比较容易出彩的方向有：可视化热力图展示座位使用率、基于历史预约数据的时段预测、小程序端适配、预约签到提醒、扫码核销等。这些方向都不需要换技术栈，在现有SpringBoot基础上就能独立成章，非常适合作为系统的亮点来展开。
最后再说一句，代码写不下去的时候先别急着上网搜答案，把业务场景画出来，对着流程推一遍，很多逻辑问题在纸面上就能发现。这招我一直在用，对理清思路真的很有帮助。
