企业官网建设流程全解析

1. 项目全局梳理：目标与核心需求

1.1 这个系统到底要解决什么问题

我在带毕业设计的过程中，看到很多同学把"核酸检测预约系统"简单理解成"一个能填表单的网页 + 一张数据库表"，这是典型的思路跑偏。实际上，这个题目最核心的价值在于预约资源的分配逻辑，而不是页面长什么样。你回想一下平时用过的预约类产品——挂号、约车、订会议室——本质都是多用户争抢有限时段资源，核酸预约也不例外。

具体到这个项目，你要解决的无非是三个问题：

第一，用户怎么方便地查询可预约的时段和检测点，并完成预约；第二，检测机构怎么管理每天的预约名额、录入检测结果、处理爽约和取消；第三，管理员怎么统筹全局——检测点信息、每日放号量、历史数据统计。这三个问题拆开看都不难，但合在一起，就涉及用户认证、权限区分、状态流转、并发控制、定时任务、文件导出等一系列Spring Boot体系里的经典考点，这也是为什么导师和学生都喜欢拿它当毕业设计题目的原因。

1.2 技术选型，为什么是Spring Boot

先说一个很多新手困惑的问题：市面上有SSM、有Spring Cloud，为什么毕业设计几乎首选Spring Boot？我的回答很直接——因为它把项目从"配置地狱"里解放出来了。

我做过的项目里，SSM时代最痛苦的就是那一大堆XML配置，一个druid数据源配置能写三四十行，还要手动配置事务管理器、MyBatis的SqlSessionFactory、Mapper扫描路径。Spring Boot用自动配置和约定大于配置把这些全部收敛了，你只需要在application.yml里写几行连接信息，依赖引入后就能跑。这意味着你写业务逻辑的时间占比大幅提升，而毕业设计的时间本来就紧张，把精力花在堆配置文件上毫无意义。

具体到我推荐的技术组合，是这样的：

这套选型的原则是"每个组件都解决一个明确的问题，不搞花活"。比如Redis，很多人的项目里只是简单存个登录token，实际上它在预约场景下还有更重要的用途——后面我会专门讲。定时任务用Spring Task而不是Quartz，是因为这个项目的任务复杂度远没到需要Quartz管理集群调度和持久化任务的程度，Spring Task一个@Scheduled注解就搞定了，简单直接。

1.3 系统整体功能模块拆解

把需求翻译成功能模块表，是设计的第一步。我习惯先把所有角色和动作列出来，再划分模块边界。核酸预约系统里一共三类角色，各自的关注点完全不同：

• 普通用户：注册登录、查看检测点列表、选择日期时段预约、查看预约记录、取消预约、查看检测结果。
• 检测机构/医护角色：查看当日预约名单、录入检测结果（阴性/阳性）、调整可预约名额。
• 系统管理员：用户管理、检测点增删改查、放号规则配置、数据统计概览、系统日志。

对应地，系统的模块划分应该是：

• 认证与用户模块：负责注册、登录、权限拦截、个人信息维护。这是所有业务模块的入口，建议用JWT做无状态认证，减轻Session管理和分布式场景下的会话共享问题。如果前端是原生HTML或Thymeleaf，也可以直接用Session，但既然都上Spring Boot了，我建议用JWT，后续扩展移动端接口也方便。
• 检测点管理模块：维护检测点的名称、地址、工作时间段、每日最大预约量、联系电话等基础信息。
• 预约模块：核心中的核心，涉及时段查询、名额判断、预约创建、状态流转、取消预约。数据库设计的重点和并发控制的难点都集中在这个模块。
• 结果管理模块：检测机构录入结果、用户查看结果、结果状态变更通知。可以结合异步消息或定时任务实现"出结果后短信通知"的扩展功能。
• 统计报表模块：按日、按检测点统计预约量、完成量、取消量、阳性数。可以用ECharts展示，也可以用Apache POI导出Excel。

我见过不少人把模块细分到八九十来个，结果每个controller里就三五个接口，代码量没有，维护成本倒是不小。毕设项目保持在五到六个模块比较合适，既能覆盖核心业务，又不至于让工作量失控。

2. 数据库设计与核心建模

2.1 核心数据实体的设计思路

数据库设计是整篇论文里最容易被答辩老师盯上的部分。很多同学一上来就建表，边写代码边改表结构，这是一个非常不好的习惯。我会花四五个小时把ER图理清楚，把所有实体间的关联关系画出来，再动手建表。

核酸预约系统里至少有这些实体：用户表、检测点表、预约时段表、预约记录表、检测结果表、管理员操作日志表。数量不多，但每张表之间都有业务关联，设计时要注意：

• 用户表与预约记录表是一对多——一个用户可以有多次预约记录。
• 检测点表与预约时段表是一对多——一个检测点一天可以配置多个检测时段，比如8:00-10:00、10:00-12:00、14:00-16:00。
• 预约时段表与预约记录表是一对多——一个时段可以被多人预约，但不超过时段容量上限。
• 预约记录表与检测结果表是一对一——每条预约最终对应一条结果。

理清关系后再思考一个问题：什么字段适合冗余？我的做法是，把检测点名称冗余到预约记录表里。因为用户查询"我的预约列表"时，大概率只需要显示检测点名称，如果每次都要去关联检测点表，多一次JOIN不说，一旦检测点改名，历史预约记录展示也要跟着变。冗余字段在项目里是合理的取舍，不是设计缺陷，答辩时能说出来为什么这么做，反而是加分项。

2.2 关键表结构设计（含关键字段）

我不会把每张表的建表语句全部贴一遍，那太占篇幅，但核心的预约记录表和时段表要拿出来单独说，因为整个系统的业务核心都在这里。

先看时段表的设计：

CREATE TABLE `appointment_slot` ( `id` bigint NOT NULL AUTO_INCREMENT, `site_id` bigint NOT NULL COMMENT '检测点ID', `slot_date` date NOT NULL COMMENT '可预约日期', `start_time` time NOT NULL COMMENT '时段开始时间', `end_time` time NOT NULL COMMENT '时段结束时间', `total_quota` int NOT NULL DEFAULT 50 COMMENT '总容量', `booked_quota` int NOT NULL DEFAULT 0 COMMENT '已预约数量', `version` int NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态：1启用 0停用', PRIMARY KEY (`id`), KEY `idx_site_date` (`site_id`, `slot_date`) ) COMMENT='预约时段表';

这里的total_quota和booked_quota是一对关键字段。判断"是否还能预约"本质上就是比较booked_quota < total_quota。但注意，我加了一个version字段，这个不是装饰，它是我做并发控制的基础。在高并发场景下，两个用户同时预约最后一个名额，如果只做booked_quota < total_quota判断再更新，极大概率会出现超卖。这个问题放到第五章详细展开。

再看预约记录表：

CREATE TABLE `appointment_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `appointment_no` varchar(32) NOT NULL COMMENT '预约编号', `user_id` bigint NOT NULL COMMENT '用户ID', `slot_id` bigint NOT NULL COMMENT '时段ID', `site_id` bigint NOT NULL COMMENT '检测点ID', `site_name` varchar(100) NOT NULL COMMENT '检测点名称（冗余）', `appointment_date` date NOT NULL COMMENT '预约日期', `time_slot` varchar(32) NOT NULL COMMENT '时段描述，如08:00-10:00', `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0待检测 1已检测 2已取消 3已过期', `real_name` varchar(50) NOT NULL COMMENT '真实姓名', `id_card` varchar(18) NOT NULL COMMENT '身份证号', `phone` varchar(11) NOT NULL COMMENT '手机号', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_appointment_no` (`appointment_no`), KEY `idx_user_id` (`user_id`), KEY `idx_slot_id` (`slot_id`) ) COMMENT='预约记录表';

这里有几个细节值得一提。第一个是appointment_no预约编号，我建议做成日期 + 随机数或日期 + 自增序列的格式，不仅业务上需要用户凭预约编号到现场核验，数据库层面有唯一索引约束，也能从根源上防止重复预约记录的产生。第二个是身份证号和手机号这两个字段，在演示项目里直接明文存储问题不大，但如果你论文里想提隐私保护，可以加一段AES加密存储，讲起来也是一个亮点。第三个是status状态字段，我给它赋予了四个枚举值，这个状态机设计直接影响业务代码的复杂度，需要单独说明。

2.3 状态机设计：预约状态如何流转

状态机是数据库设计里最容易忽视但最影响代码质量的部分。我把预约记录的状态设计了四个：0待检测、1已检测、2已取消、3已过期，流转路径如下：

• 用户成功提交预约，状态置为待检测。
• 用户在规定时间前主动取消，状态从待检测变为已取消，同时时段表的booked_quota要减一，释放名额。
• 用户按时到场完成检测，机构录入结果，状态变为已检测。
• 用户预约了但没来，也没有提前取消，系统通过定时任务扫描，将超过预约日期且仍为待检测的记录批量置为已过期。

为什么要单独设计已过期而不是直接已取消？因为两者的业务含义不同——取消是用户主动行为，过期是系统判定行为。而且后续如果要做"爽约次数统计"来限制用户后续预约资格，靠状态区分就能轻松完成，不需要额外加字段。这就是状态机的价值：用确定的枚举值表达清晰的业务语义，代码里永远不出现硬编码的魔法数字。

我在代码里建议加一个AppointmentStatusEnum枚举类，把状态值和描述集中管理，后续无论写判断逻辑还是做前端下拉选项，都从这里取。这是很小的设计习惯，但答辩时如果老师问"你为什么要用枚举而不用数字常量"，你完全可以说出一套规范化的理由。

3. 核心流程落地：预约业务的关键实现

3.1 项目结构与分层

很多人拿到题目就开始写Controller，这是大忌。先把包结构设计好，写代码才有条理。我推荐一个标准的四层结构，它也是业内最主流的MVC变体：

com.example.nucleic ├── controller // 接口层，接收参数、调用service、返回结果 ├── service // 业务层，核心业务逻辑全部在这一层 │ └── impl ├── mapper // 数据访问层，继承MyBatis Plus的BaseMapper ├── entity // 实体类，对应数据库表 ├── dto // 传输对象，接收前端参数、响应前端结果 ├── config // 配置类，如MyBatis Plus分页插件、跨域配置 ├── common // 公共类，统一返回结果、状态码、异常处理 └── util // 工具类，如JWT工具、日期工具

Controller层只负责参数接收和结果包装，业务逻辑一律下沉到Service层，Mapper层只做数据操作，这个边界要守住。我在评审毕设代码时经常看到业务逻辑写在Controller里的情况，一个接口几百行，复用性为零，出了问题还难定位。示例代码虽然长，但至少思路清晰、职责分明。

3.2 预约接口的实现细节（含并发控制方案）

预约接口是核心中的核心，我专门写一个完整示例来演示。先看Service层的主逻辑：

@Override @Transactional(rollbackFor = Exception.class) public AppointmentResult createAppointment(AppointmentCreateDTO dto) { // 1. 校验用户是否已登录（登录信息从请求上下文取） Long userId = UserContext.getUserId(); // 2. 查询时段信息，判断是否还有名额 LambdaQueryWrapper<AppointmentSlot> slotQuery = new LambdaQueryWrapper<>(); slotQuery.eq(AppointmentSlot::getId, dto.getSlotId()) .eq(AppointmentSlot::getStatus, 1); AppointmentSlot slot = appointmentSlotMapper.selectOne(slotQuery); if (slot == null) { throw new BusinessException("预约时段不存在或已停用"); } // 3. 防止重复预约：同一用户在同一日期（同一天任意时段）只能预约一次 LambdaQueryWrapper<AppointmentRecord> dupQuery = new LambdaQueryWrapper<>(); dupQuery.eq(AppointmentRecord::getUserId, userId) .eq(AppointmentRecord::getAppointmentDate, slot.getSlotDate()) .in(AppointmentRecord::getStatus, Arrays.asList(0, 1)); Long count = appointmentRecordMapper.selectCount(dupQuery); if (count > 0) { throw new BusinessException("您已预约该日期，请勿重复预约"); } // 4. 并发控制：使用MyBatis Plus的乐观锁插件 // update ... set booked_quota = booked_quota + 1, version = version + 1 // where id = ? and booked_quota < total_quota and version = ? LambdaUpdateWrapper<AppointmentSlot> updateWrapper = new LambdaUpdateWrapper<>(); updateWrapper.eq(AppointmentSlot::getId, slot.getId()) .eq(AppointmentSlot::getBookedQuota, slot.getBookedQuota()) .lt(AppointmentSlot::getBookedQuota, AppointmentSlot::getTotalQuota); AppointmentSlot updateEntity = new AppointmentSlot(); updateEntity.setBookedQuota(slot.getBookedQuota() + 1); int rows = appointmentSlotMapper.update(updateEntity, updateWrapper); if (rows == 0) { throw new BusinessException("名额已满，预约失败"); } // 5. 插入预约记录 AppointmentRecord record = new AppointmentRecord(); record.setAppointmentNo(generateAppointmentNo()); // ... 其余字段赋值省略 appointmentRecordMapper.insert(record); // 6. 返回预约编号 return new AppointmentResult(record.getAppointmentNo()); }

这版代码的关键在第4步。假设booked_quota当前是9，总量是10，两个用户同时发起预约：

• 用户A先执行UPDATE，booked_quota从9变成10，影响行数为1。
• 用户B再执行同样的UPDATE，此时booked_quota已经是10，不满足booked_quota < total_quota条件，影响行数为0，预约失败。

这就是基于条件更新的乐观锁，它不需要在数据库事务里显式加锁，靠UPDATE语句的条件判断保证数据一致性。SPRING BOOT就这么一个简单的写法，就把超卖问题堵死了。我在很多项目里都用这个方案，包括商品秒杀、活动报名，原理是一样的。

3.3 取消预约与名额释放的细节

取消预约表面上只是改一个状态字段，但有两个坑必须处理：

第一个坑是时段的名额要回补。用户取消了，booked_quota不减回去，后续名额就白白浪费。但要小心，回补操作必须在同一事务里完成，否则可能状态改了、名额没减，数据不一致。我见过有同学在Service方法上不加@Transactional，两个数据库操作中间隔了一次远程调用，结果事务控制全部失效。特别注意：事务只对同一个方法内的数据库操作有效，如果用this.xxx()调用本类方法，事务注解会失效，正确做法是注入自身代理或者拆分到不同类中。

第二个坑是取消的时间限制。业务正常应该是"检测当天的可预约时段开始后不能取消"，不然临开场被放鸽子，机构很难安排补位。这个判断逻辑放在Service前缀层做：如果当前时间已经晚于时段的开始时间，就抛业务异常，拒绝取消。

3.4 定时任务：过期检测与放号提醒

过期检测是一个典型的定时任务场景。我用Spring Task的@Scheduled注解实现，代码非常简洁：

@Component @Slf4j public class AppointmentExpireTask { @Resource private AppointmentRecordMapper appointmentRecordMapper; /** * 每天凌晨1点，将所有预约日期早于今天且仍为待检测状态的记录置为已过期 */ @Scheduled(cron = "0 0 1 * * ?") public void processExpiredAppointments() { LambdaUpdateWrapper<AppointmentRecord> updateWrapper = new LambdaUpdateWrapper<>(); updateWrapper.lt(AppointmentRecord::getAppointmentDate, LocalDate.now()) .eq(AppointmentRecord::getStatus, AppointmentStatusEnum.PENDING.getCode()) .set(AppointmentRecord::getStatus, AppointmentStatusEnum.EXPIRED.getCode()); int rows = appointmentRecordMapper.update(null, updateWrapper); log.info("过期预约处理完成，共处理 {} 条记录", rows); } }

这里的cron表达式0 0 1 * * ?表示每天的1点整执行。为什么选凌晨？因为半夜业务量最低，批量扫描不会跟白天的预约操作争抢数据库资源。另外用lt（小于）而不是le（小于等于）判断日期，保证当天还没结束的预约不会被误判，细节要注意。

同理，如果你想做"检测结果出来后短信通知用户"，也可以加一个类似的定时任务，轮询检测结果表，把新增的结果推送给用户，或者用订阅发布模式实时通知。毕设里用定时轮询就够了，讲起来也算一个合理的异步实现。

4. 工程化细节与部署实践

4.1 多环境配置管理

一套代码在本地跑、在服务器上跑，数据库地址、Redis地址都不同，不可能每次手动改配置文件。Spring Boot的profiles机制就是干这个的。我在项目里维护三个配置文件：

• application.yml：公共配置，比如应用名、日志级别。
• application-dev.yml：本地开发环境，指向本地MySQL和Redis。
• application-prod.yml：生产环境，指向云服务器上的数据库和缓存。

启动时用--spring.profiles.active=dev指定环境，或者打成jar包后用java -jar xxx.jar --spring.profiles.active=prod传入参数。这个技巧实操性很强，而且几乎是企业级项目的标配，写进论文里能体现工程意识。

敏感信息的加密也可以提一嘴，比如数据库密码不要明文写在application-prod.yml里，可以用jasypt框架加密，答辩时讲出来是一个亮点。

4.2 接口参数校验与统一返回

后端接口如果不对前端传的参数做校验，用户的任意输入都可能直接落到SQL里，轻则报错，重则引入注入风险。Spring Boot的@Validated参数校验非常方便：

@PostMapping("/appointment") public Result createAppointment(@Validated @RequestBody AppointmentCreateDTO dto) { return Result.success(appointmentService.createAppointment(dto)); }

DTO类里用注解声明约束：

@Data public class AppointmentCreateDTO { @NotNull(message = "时段ID不能为空") private Long slotId; @NotBlank(message = "真实姓名不能为空") private String realName; @Pattern(regexp = "^[1-9]\\d{5}(18|19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}[\\dXx]$", message = "身份证号格式不正确") private String idCard; @Pattern(regexp = "^1[3-9]\\d{9}$", message = "手机号格式不正确") private String phone; }

校验失败时，Spring Boot会抛出MethodArgumentNotValidException，我在全局异常处理器里统一捕获，返回业务码和具体错误信息，而不是给前端一个500的HTTP状态加一段晦涩的堆栈信息。这样前端拿到的永远是统一的JSON结构，调试体验直接提升一个档次。

4.3 部署与压测注意事项

本地调试通过之后，部署到云服务器是另一个考验。我的建议是买一台2核4G的入门级云服务器，装一个宝塔面板或直接命令行部署，内存够用。部署步骤我列一下，这是最简路线：

1. 服务器安装JDK 8或11、MySQL、Redis、Nginx。
2. Maven打包，用mvn clean package -DskipTests生成jar包。
3. 用nohup java -jar nucleaic-system.jar --spring.profiles.active=prod > app.log 2>&1 &启动应用。
4. Nginx反向代理：前端静态文件放在/usr/share/nginx/html，/api路径代理到http://localhost:8080。
5. 云服务商安全组放行80端口和数据库端口，数据库端口尽量不要对公网暴露，用Nginx层挡在前面即可。

压测上，用JMeter模拟100个并发用户同时提交预约，重点观察两个指标：一是接口响应时间的均值，二是预约成功后booked_quota有没有超卖。我实测过，按上面的乐观锁方案，100个并发抢10个名额，最终成功预约数精确等于10，一条不多一条不少。数据一致性验证通过后，整个项目的核心质量就有保障了。

我还会额外加一层Redis缓存，把"查询某检测点某日期剩余名额"这种高频读接口缓存起来，设置30秒过期，减轻数据库压力。这是非常贴合真实场景的优化方案，能讲出来的话，技术水平一眼就能看出来。

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

5.1 高并发下预约数据不一致

这是预约系统里出现频率最高的Bug，我讲一个真实案例。

有学员做测试时发现，数据库里时段表的booked_quota为10，总量也是10，但预约记录表里有11条成功的记录。排查过程如下：

第一步，看日志。打开应用日志，搜索"名额已满"，发现根本没有抛出过这个异常，说明代码走的路径并不是我上面演示的乐观锁版本，而是先SELECT查询数量、再判断、再UPDATE的三步逻辑。问题就出在这里——三个步骤之间有时间窗口，用户A和用户B同时通过SELECT看到剩余名额是1，都判断"可以预约"，然后都执行UPDATE，结果两个都成功。

第二步，看数据库隔离级别。MySQL默认的REPEATABLE_READ并不会锁住SELECT的区间，所以两个事务读到的数据是一致的，也不会互相等待。

第三步，修复方案。把先查后改换成条件更新，用UPDATE ... WHERE booked_quota < total_quota，影响行数为0就说明名额已被抢走。改造后复测，并发场景下数据完全一致。

这个Bug的教训是：读改写三步操作在并发场景下必须合并为一步原子操作，否则加再多的锁都不一定能解决。

5.2 定时任务在生产环境重复执行

Spring Boot的@Scheduled默认是单机单实例的，看起来没什么问题。但有学员部署时用了两台服务器做负载均衡，结果发现过期任务每天执行两遍，部分记录的update_time被刷新了两次，虽然业务结果不脏，但日志里大量重复告警。

解决方案有三种：第一种，部署层面确保@Scheduled任务只在单台机器上启用，用配置文件开关控制；第二种，引入分布式任务锁，比如用Redis的SETNX命令抢锁，抢到的实例才执行；第三种，如果用的是Spring Cloud生态，加@Scheduled和分布式锁配合，或者直接上Quartz结合数据库锁表。毕设场景下，第一种方案就够了，加一个nucleic.task.enabled配置项，生产环境只有一台机器为true。

顺带说一个细节：定时任务里如果有批量操作，一定要控制单批大小并记录日志。假设你有十万条过期记录要处理，一条UPDATE语句直接跑可能锁表，影响在线预约接口，分批处理是个好习惯。

5.3 接口查询慢，如何通过索引优化

预约记录表的数据量一旦上来，用户查询"我的预约列表"就会变慢。我见过最离谱的例子：一张表只几万条数据，查询竟然要800毫秒，原因是appointment_date字段没有索引，每次查询都是全表扫描。

排查步骤很简单：

第一步，用EXPLAIN SELECT * FROM appointment_record WHERE user_id = 1 ORDER BY appointment_date DESC查看执行计划。如果type是ALL，说明遍历了全表，需要加索引。

第二步，建立复合索引：

ALTER TABLE appointment_record ADD INDEX idx_user_date (user_id, appointment_date);

第三步，再次EXPLAIN，确认type变成ref或range，查询耗时通常能缩短到几十毫秒内。

在这个项目里，我从一开始就在表设计阶段预埋了这些索引——appointment_slot表的idx_site_date、appointment_record表的idx_user_id和idx_slot_id，就是为了避免数据量上来之后再返工。索引设计必须在建表时想清楚，否则后期加索引要锁表，线上环境风险很大。

5.4 接口返回了成功的状态码，但数据库没数据

这算是事务方面非常经典的坑。我当时排查过一个学员的问题：预约接口返回了200和预约成功的提示，但数据库里就是查不到记录。排查到最后，发现他写的Service方法里，先执行了预约记录插入，然后调用了一次外部接口（短信通知），短信接口超时抛了异常，但由于方法上没有@Transactional注解，前面的插入操作已经被自动提交了，异常发生后数据还是落库的——等等，如果他说是"数据库没数据"，那问题更可能出在别处。

最后真相大白：他插入的数据，主键用的是手动生成的UUID字符串，字段类型在数据库里是bigint，插入时MySQL自动做了类型转换，没报错但也没真正写入，实际上看一下日志，数据库是报了一个隐式转换警告的。所以这里要强调：实体类的主键类型必须和数据库主键类型严格对应，字符串主键用varchar，长整型主键用bigint，不要依赖MySQL的隐式转换。

每次遇到这类"状态码正常但数据不对"的问题，我建议的第一步永远是看应用日志里的SQL执行情况，打开MyBatis的SQL日志输出，一秒钟就能定位是SQL没执行、执行了没提交、还是提交到了错误的库表。

写在最后，按个人经验来收个尾

做这个项目，我自己最大的感受是：技术栈其实都很常规，Spring Boot那一套查文档都能写出来，真正拉开差距的是对业务并发和数据一致性的理解。你愿不愿意为"两个用户同时抢最后一个名额"这种极小概率事件多写两行代码，决定了你的方案是课程作业级别还是工程实践级别。

如果你正在做这个毕设，我给三个建议：第一，把数据库设计重新画一遍，重点标出每个表的索引和状态字段；第二，用JMeter把预约接口的并发场景测一遍，亲眼确认数据不会错；第三，论文里写清楚方案选型时为什么不用悲观锁、为什么不用纯Redis做存储、为什么选择Spring Boot而不是SSM——这些思考过程比结果本身更有说服力。

再分享一个小技巧：答辩演示的时候，提前准备好一个"线上故障修复"的小故事，比如并发压测时发现超卖，然后怎么定位、怎么修复、复测结果如何。答辩老师特别吃这一套，因为它证明你不是只会写代码，而是真的具备排查问题的能力。祝顺利。