说到 SpringBoot 毕业设计，很多同学的第一反应是“做一个简单的 CRUD 管理系统”，然后套个模板交差。但我一直建议身边的人选这类题目：有真实业务场景、有明确的状态流转、能讨论并发和事务一致性，而且放在简历上不虚。基于 SpringBoot 的某市出入境事务在线预约系统，就是典型的“看起来复杂、拆开了其实全是知识点”的题目。

这个系统要解决的核心问题并不难理解：过去办证需要在工作日去大厅排号，材料没带齐还得改天再来。预约平台做成以后，公民在手机上选业务类型、选日期时间段、提交材料预审，到了约定时间再去窗口办理。对管理者来说，每个时段放多少号、哪些材料必须携带、有没有爽约风险，都能通过后台配置和数据统计掌握。这篇文章就把我当时从需求分析到部署上线的完整过程拆开讲，包括数据库怎么建、时段冲突怎么防、权限怎么控、答辩要准备哪些说辞。

1. 项目整体拆解与需求分析

1.1 核心业务流程与角色定义

从业务流程看，这个系统本质上是一条“预约—核销—办理—结束”的闭环。用户侧做的事情看起来很简单：注册登录、选业务、选日期时段、填个人信息、提交预约、到时候去大厅扫码核销。但背后关联的数据和状态远不止一张预约单那么简单。

我习惯先把角色理清楚，再去画用例图和数据流。系统一共三类角色：

• 公民用户：前台注册登录，查询可预约时段，提交预约或取消预约，查看办理进度。
• 窗口工作人员：核销预约、叫号、开始办理、完成办理，也能按日期查看自己的工作量。
• 系统管理员：维护业务类型、设置时段与每日放号量、配置材料清单、查看全市预约统计数据、处理异常预约。

把角色盘清楚以后，功能模块的边界就很明确了。用户模块、预约模块、业务类型管理模块、时段管理模块、材料配置模块、统计报表模块，再加上通知提醒这类辅助能力，基本上就是系统的全部范围。很多同学一上来就急着写代码，结果写到联调时发现角色权限对不上、状态跳转逻辑乱，根源都是需求没拆透。

1.2 功能模块划分与核心用例

我列一个当时自己梳理的功能清单，这个表可以直接作为开题报告里“功能需求”部分的素材：

这个清单看起来简单，但有一个点特别容易被忽略：材料清单不是写死在页面里的。因为不同业务类型需要的材料不一样，而且政策调整后材料要求会变，所以材料的名称、数量、示例图片都应该能通过后台配置。做毕设时，哪怕管理员页做得简陋一点，也要把这个配置入口留出来，答辩时老师很爱问“如果材料要求变了，你怎么办”。

1.3 为什么选 SpringBoot 而非其他框架

选型说白了要回答三个问题：好不好写、好不好讲、好不好维护。SpringBoot 在这三点上的优势都很明显。

首先是免配置。SSM 时代光 springmvc.xml、applicationContext.xml 就能写几百行，很多同学光配环境就丧气。SpringBoot 用自动装配把这些默认项吃掉，一键启动。其次是生态整合，MySQL、Redis、MyBatis-Plus、Spring Security、验证框架，全都是官方或社区最成熟的那一套，遇到问题搜得到答案。最重要的是，答辩时老师默认你懂 SpringBoot 全家桶，用得太偏门反而容易被追问到底。

有人问过我用 SSM 行不行，我的回答是可以，但没必要。这个题目真正要考察的并发控制、状态机设计、权限安全，跟用哪个框架没有强关系，SpringBoot 能让你把精力花在核心逻辑上，而不是浪费在配置排查上。

2. 架构设计与数据库建模

2.1 分层架构与工程结构规划

工程结构我建议按经典的分层来组织，不要为了炫技搞复杂微服务。一个小项目拆成若干个微服务，部署时先把自己绕晕。我当时的目录是这样规划的：

src/main/java/com/example/exitentry ├── controller # 接口层，只做参数接收与结果包装 ├── service # 业务逻辑层，存主要状态机与事务控制 ├── mapper # 数据访问层，MyBatis-Plus ├── entity # 数据库实体 ├── dto # 请求对象，带校验注解 ├── vo # 返回对象，按前端需要的结构设计 ├── config # 安全配置、Redis配置、跨域配置 ├── common # 统一返回结果、异常处理、常量 └── utils # JWT、日期工具等

分层最重要的是约束依赖方向：Controller 只能调 Service，Service 调 Mapper，不能出现 Controller 里直接写 SQL 或者拼字符串的情况。这个约束看起来基础，但实际写代码时，我见过不少同学为图省事，在 Controller 里直接操作数据库对象，结果后面一改表结构，整个控制层跟着报废。

2.2 核心数据表设计与字段含义

数据库是整个系统的地基。我围绕预约闭环设计了以下核心表：

用户表 user

• id、手机号（登录账号）、密码密文、姓名、身份证号、角色类型（USER/EMPLOYEE/admin）、状态。

业务类型表 business_type

• id、业务名称（如普通护照申请、补换发）、描述、是否启用、联办机构编号。

材料配置表 material_config

• id、业务类型 id、材料名称、是否必须、备注。

时段表 period_slot

• id、业务类型 id、可预约日期、开始时间、结束时间、总名额、已预约名额、窗口编号。

预约主表 appointment

• 预约单号、用户 id、业务类型 id、period_slot id、办理日期、时段、状态、创建时间、核销时间。

预约材料表 appointment_material

• id、预约单 id、材料名称、是否已上传/已确认、图片 URL。

通知记录表 notice_log

• id、用户 id、关联业务 id、通知类型、内容、发送状态、发送时间。

这里有一个很容易踩的坑：不要只设计 appointment 表，用日期字符串加时间段字符串去表示预约时段。虽然查询时也能过滤，但放号逻辑会变得非常难写。正确的做法是把“时间段”抽象成 period_slot 资源表，每一项代表某一天某个时段的固定名额，预约操作本质上是去扣减这个资源。

还要强调身份证号和手机号这类敏感信息，在展示列表时要做脱敏处理，比如138****1234，手机号前三位后四位明文，中间星号。虽然毕设没有真实生产数据，但代码设计上体现这个意识，是加分项。

2.3 预约状态机的显式设计

预约不是一个“有/无”的布尔状态，从用户提交到窗口办结，中间要经历很多阶段。我用一个枚举类定义所有状态：

public enum AppointmentStatus { RESERVED, // 已预约，待核销 CHECKED, // 已到窗口核销 PROCESSING, // 窗口办理中 COMPLETED, // 已完成 CANCELLED, // 用户已取消 NO_SHOW // 爽约，未在约定时段核销 }

状态变化路径要显式画出来，然后写进 Service 里做校验。我当时在第一版代码里只写了“预约成功→取消”，结果过两天想想不对劲：已核销的单子还能取消吗？办理完成之后还能取消吗？这就是状态机缺失导致的逻辑漏洞。

正确的流转规则是：只有 RESERVED 状态下用户才能取消；员工只允许核销 RESERVED 状态的单；CHECKED 之后进入 PROCESSING；PROCESSING 结束后 COMPLETED；另外通过定时任务，把超过了办理日期仍然停留在 RESERVED 状态的单批量置为 NO_SHOW，并释放对应名额。

我建议把状态更新做成一个单独的 Service 方法，比如changeStatus(appointmentId, fromStatus, toStatus)，用“来源状态+目标状态”双重校验来防止非法跳转。代码里前一个状态匹配不到就直接抛业务异常，这样脏数据很难混进来。

3. 核心功能实现与避坑记录

3.1 预约时段防超卖的处理

这是这个系统最核心的技术点，也是答辩时最能展示深度的一环。假设某窗口某时段放号 20 个，100 个人同时点击预约，如果没有控制并发，数据库的“已预约名额”字段会被反复覆盖，最终可能预约成功 200 个人。怎么解决？说三种实际可用的方案。

方案一：数据库原子 UPDATE 扣减

int updated = appointmentMapper.reduceAvailableCapacity( slotId, LocalDate.now()); if (updated == 0) { throw new BusinessException("该时段名额已满"); }

对应 SQL 的核心逻辑是：

UPDATE period_slot SET booked_count = booked_count + 1 WHERE id = #{slotId} AND date = #{date} AND booked_count < capacity

这条语句靠数据库的行锁来保证并发安全，booked_count < capacity是硬性条件，执行后返回受影响行数，等于 0 就说明没名额了。这个方案代码少、思路清晰，推荐作为毕设的主实现。

方案二：悲观锁/分布式锁

用 Redis 分布式锁在进入业务逻辑之前先抢锁，抢不到就提示稍后重试。展示这个方案时，要讲清楚锁的粒度怎么设。粒度要是到整张表，那并发直接降到 1；正确做法是锁到时段资源维度，比如lock:period:20250610:09:00这个 key。

方案三：唯一索引兜底

给预约表加一条规则：同一用户同一时段不能有两条有效预约。这个用数据库唯一索引做成硬约束，即使上层代码漏判断，数据库也不会放行。

我自己在实际编码时三种都写了一遍，最终保留方案一作为主路径，方案三作为兜底。因为事务里先查后改容易产生间隙问题，直接 UPDATE 是最不容易出错的。如果你时间紧张，至少把方案一做扎实，讲明白“为什么一条 UPDATE 能防超卖”就够了。

3.2 取消预约与名额释放

取消看起来简单，实际上有两个隐藏问题。第一个是释放名额的时机，第二是取消之后同一用户能不能马上重约。

用户 A 取消了一个 09:00 点时段的预约，如果不及时把 booked_count 减回去，这个名额就凭空消失了。所以取消接口里除了改 appointment 状态，还要同时把 period_slot 的已预约数减一。这两个操作必须在同一个事务里，否则要么状态改了名额没释放，要么名额释放了但没改状态。

再往深一层考虑，用户的预约可能涉及已上传材料、已产生的通知记录，取消后这些关联数据怎么处理？我的做法是保留这些记录，因为将来查操作日志或做数据统计时，这些“已取消”的数据也有价值，只是给预约单打上 CANCELLED 标记，不物理删除。物理删数据在真实业务系统里是大忌。

3.3 预约提醒与通知机制设计

通知模块不必真接短信服务商，尤其是毕设阶段，但要把接口设计对。我用一个 SmsService 接口，本地实现里把发送内容打到日志里，同时往 notice_log 表写一条记录。将来如果要接真实短信平台，只要在实现类里改成调第三方 SDK，Controller 和 Service 层完全不用动。

public interface SmsService { void sendAppointmentSuccess(String phone, String bizName, LocalDateTime time); void sendCancelNotice(String phone, String appointmentNo); void sendRemind(String phone, LocalDate date, TimeRange range); }

需要提醒的时间点有三个：预约成功后的即时通知、办理前一天下午的临期提醒、取消成功后的通知。临期提醒要设计一个每日定时任务，扫出第二天的所有 RESERVED 状态预约，按用户手机号推送。这就把定时任务和大批量消息循环也顺带完成了，技术点更完整。

4. 接口设计、鉴权控制与前端配合

4.1 接口风格与统一返回结构

接口设计直接影响前后端协作效率。我采用 RESTful 风格，基础路径统一加/api/v1，方便将来版本迭代。所有接口返回统一包装：

public class Result<T> { private Integer code; private String message; private T data; }

正常返回code = 200；业务异常时抛BusinessException，由全局异常处理器统一转换成code = 400或自定义业务码。比如“该时段已满”用3001，“预约状态不允许取消”用3002。不要用 HTTP 状态码硬扛业务错误，也不要在 Controller 里到处写try-catch塞返回体，那样代码会丑到没法维护。

我列几个核心接口示例，方便你照着设计：

4.2 典型接口代码：创建预约

创建预约是链路最长的接口，我给出核心 Service 代码：

@Transactional(rollbackFor = Exception.class) public AppointmentVO createAppointment(CreateAppointmentDTO dto) { // 1. 校验用户今日是否已有有效预约（可选规则：一人一天只能约一个业务） long validCount = appointmentMapper.countValid( userId, LocalDate.now(), AppointmentStatus.RESERVED); if (validCount > 0) { throw new BusinessException("您当天已存在有效预约"); } // 2. 校验业务类型有效 BusinessType businessType = businessTypeMapper.selectById(dto.getBizTypeId()); if (businessType == null || !businessType.getEnabled()) { throw new BusinessException("业务类型不可预约"); } // 3. 扣减名额，原子操作防超卖 int updated = periodSlotMapper.reduceCapacity(dto.getSlotId()); if (updated == 0) { throw new BusinessException("该时段余票不足"); } // 4. 创建预约单 Appointment appointment = new Appointment(); // ... 设置字段 appointment.setStatus(AppointmentStatus.RESERVED); appointmentMapper.insert(appointment); // 5. 保存材料上传情况 // 6. 发送通知 smsService.sendAppointmentSuccess(phone, bizName, time); return AppointmentConverter.toVO(appointment); }

这段代码里有几个细节要注意。第一，申请参数要用 DTO 加校验注解，比如预约日期不能是过去日期、手机号格式要合法。第二，如果第 3 步扣减成功了，但第 4 步插入失败，整个事务会回滚，名额不会白白消失，这正是@Transactional的意义。第三，通知最好放在事务外做，或者用最终一致的方式处理，不要在事务里调第三方网络请求，避免拖长数据库锁时间。

4.3 登录鉴权与水平越权防护

权限这块我用的是 JWT + Spring Security 拦截器的方式，没有引入太重的认证框架。

登录成功后，服务端签发一个 token，里面带上 userId 和角色。后续请求在 Header 里带Authorization: Bearer xxx，拦截器解析 token，把用户信息放进 ThreadLocal，业务代码里直接取当前登录人。

口令存储方面，密码必须用 BCrypt 加密，别用 MD5。哪怕只是毕设，写 MD5 在答辩时很容易被老师一票否掉，因为那是常识性的安全问题。

除了登录鉴权，更要命的是水平越权。比如用户 A 预约成功后，返回了一个预约单 ID，用户 A 如果把请求里的 ID 改成用户 B 的单号，系统能不能拦下来？很多第一版代码都会漏掉这一点。解决办法是在取消、查询详细等接口里，除了校验“是否登录”，还要校验“这条预约数据是否属于当前用户”。

Appointment appointment = appointmentMapper.selectById(id); if (!appointment.getUserId().equals(currentUserId)) { throw new BusinessException(403, "无权操作该预约"); }

前端隐藏按钮只是体验层面的处理，后端必须要做数据归属校验，这个意识放在简历和答辩里都是亮点。

5. 常见问题与排查技巧实录

5.1 开发期高频问题清单

做这个项目时，我把自己踩过的坑做成了一张速查表，每次联调出问题先查一圈，效率高很多。

5.2 联调阶段的前后端协作经验

前端和后端联调，最烦的事情之一就是接口字段对不上。我第一版经常把 entity 直接返回给前端，数据库字段叫什么前端就用什么，结果后面为了安全加一个字段，前端也要跟着改，两边都很痛苦。

后面我调整策略：接口返回值一律以 VO 为准，VO 里只放前端真正需要展示的字段。查询可约时段时，返回的数据结构应该是前端直接能渲染的：日期、时段、剩余名额、是否已约满。不要返回一个后端内部的period_slot对象让前端自己算。

另外，接口文档从一开始就要写。不需要用什么复杂工具，直接在代码注释里写清楚请求参数、响应示例、错误码即可。联调的时候谁也别装了，先盯接口文档对齐，再动代码。

5.3 数据统计与报表设计的一些提醒

管理员端要看的统计，听起来很简单，无非是每日预约量、各业务类型预约量、各窗口办理量。但我第一版踩了一个坑：直接在查询接口里写一大堆 count 和 group by，页面加载时每次都要全表扫描，数据量一大就卡。

更合理的是把统计结果做汇总表，比如daily_statistics表，每天晚上定时任务或者每次预约状态变化后增量更新。窗口工作人员每核销一单，当日统计的办理数就加一。这样查询报表时只需要select * from daily_statistics where date = ?，速度极快。这个“预统计”的思路，在毕业设计里同样是加分项。

6. 测试、部署与答辩准备

6.1 并发模拟与核心测试用例

做毕设最怕的就是老师问“你怎么验证系统是对的”。千万别说“我自己点了一下能跑通”，要把测试记录拿出来。

并发测试我推荐先用 JUnit 单元测试保证基本逻辑正确，再用 JMeter 或代码模拟并发请求。以“防超卖”为例，当年我是这样做的：设置某个时段容量为 30，然后用 200 个线程同时发起预约，最终统计预约成功数量。正确结果是 30，多余线程全部收到“名额已满”的提示，数据库中的最终预约记录数也是 30。

我把这个结论直接截图放进毕业论文的“系统测试”章节，老师看完基本上不会再追问“你这个系统安全吗”这种问题。

还有几个必测的用例：同一个人重复预约同一时段、取消后重新预约、窗口核销后再次核销、已过期的预约能否取消。这些边界用例全过一遍，逻辑上就基本稳了。

6.2 环境部署与运行保障

部署方式上，毕设不需要特别复杂的容器编排，我用 Docker Compose 解决了环境和发布问题。一个简洁的docker-compose.yml大概长这样：

services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: exit_entry_db ports: - "3306:3306" backend: build: . depends_on: - mysql ports: - "8080:8080"

本地用这套环境跑通之后，部署到云服务器也基本是一条命令的事情。不需要花太多时间折腾太云原生的内容，项目本身的技术含量在哪里，老师心里有数，别把力气花偏了。

6.3 答辩时的展示思路与说辞准备

答辩准备的核心不是把代码讲一遍，而是挑出设计层面的亮点。我给自己列了三个主题，每个主题准备了两三句话：

• 预约防超卖：用原子更新 + 数据库唯一索引双重保障，并发情况下不会出现同一时段多人抢同一个名额。
• 状态机兜底：所有状态变化都走统一方法，非法的流程跳转会在代码层面被拦截；系统还通过定时任务自动识别爽约单。
• 运营配置能力：业务类型、材料清单、放号时段都是可配置的，管理员不需要改代码就能调整业务规则。

现场演示的路径我建议按“业务闭环”走一遍：用户注册登录 → 查看业务类型 → 选择可约时段 → 提交预约 → 收到通知 → 退出登录 → 员工登录核销 → 完成办理。每个操作之间留两秒停顿，让老师看清楚数据变化，而不是点完一键直达，那样看不出流程。

最后的一点个人体会

这个项目做完之后，最大的收获其实不是学会了 SpringBoot 的某个注解怎么用，而是把一个模糊的业务问题翻译成了具体的技术方案。最初拿到题目时，我脑子里就是一张预约表单；做完之后再回头看，才发现每一个环节都在考验处理并发、保证数据一致性和约束用户行为的能力。

如果让我给后来的人一个建议，我会说：别急着写代码，先把状态流转图画清楚，把数据库字段定下来，把“什么情况下算异常”列出来。设计阶段多花两天，写代码阶段能省两周。这个题目做一个完整的业务闭环，放在简历上是能和面试官聊十分钟的，前提是真的把每一步都理解透，而不是只把课程模板改了个皮。