Spring Boot相机租赁系统毕设实战：从数据库设计到答辩要点

很多人第一眼看到“Java Spring Boot + 相机租赁系统”这个选题，会觉得不就是个普通的管理系统吗？无非是CRUD、几张表、一个前端页面。但真正动手做的时候才发现，租赁业务跟传统的“买-卖-库存”逻辑完全不一样，它涉及时间维度、状态流转、押金和租金计算、逾期处理，每一个环节都能单独撑起一个毕业设计的核心章节。这篇文章我想以复盘的角度，把从选题、数据库设计、后端实现到答辩准备的完整过程拆开讲，给正在做类似毕设或者想快速上手Spring Boot项目的同学一条可以直接参考的路径。

1. 为什么“相机租赁系统”是毕业设计的好题目

1.1 业务场景真实的“麻雀虽小五脏俱全”

很多毕业设计题目看起来很高大上，比如“基于深度学习的某某识别系统”“基于大数据的某某分析平台”，但对大部分本科学生来说，这些题目要么过度依赖现成框架导致工作量集中在调参和套模型上，要么因为数据来源不真实、效果不可控，最后做出来的东西自己都说不清楚。相比起来，“相机租赁系统”是一个业务逻辑非常清晰、需求来源非常真实的题目——现在不管是个人摄影爱好者还是小型工作室，购买高端相机的成本都不低，租赁是实实在在存在的市场需求。

这个场景的好处在于：它有多个角色（管理员、普通用户）、有核心业务流（浏览相机、下单、支付押金、取机、归还、结算）、有异常分支（逾期、取消、相机损坏）、有统计需求（租赁收入、相机热度排行）。也就是说，一个合格的系统设计题该有的要素它基本都覆盖了，而每个要素的复杂度又刚好在本科毕业设计可以驾驭的范围之内。

1.2 技术栈的“稳”比“新”更重要

做毕业设计，技术选型的第一原则不是“哪个新用哪个”，而是“哪个我能完整解释清楚用哪个”。Spring Boot作为目前Java后端开发的事实标准，资料多、社区活跃、遇到问题基本都能搜到解决方案，非常符合毕设的需求。配合MyBatis-Plus操作数据库、Spring Security做权限控制、MySQL存数据，这套组合在国内的毕设和中小型项目中已经非常成熟，答辩的时候老师问到底层原理，你也能找到大量现成的资料去理解。

我见过不少同学一上来就选了微服务架构、分布式事务、消息队列这些中间件，结果光是搭建环境和处理各种报错就耗掉一大半时间，最后核心业务反而没做扎实。相机租赁系统这种单机应用加上合理的模块拆分，已经足够展示你对Spring Boot的掌握程度。如果学有余力，再引入Redis做缓存、RabbitMQ做延迟消息处理逾期提醒，属于锦上添花，但不加也完全不影响系统完整性。

1.3 功能全景：从用户端到管理端

围绕租赁业务，系统的功能模块大致可以分成四个块：

• 用户端：注册登录、浏览相机列表与详情、按分类或品牌筛选、下单租赁、查看订单状态、申请归还。
• 管理端：相机信息管理（新增、编辑、上下架）、库存管理、用户管理、所有订单的管理（审核、标记取机、标记归还、处理异常）。
• 订单核心流：提交订单 → 缴纳押金 → 确认取机 → 租赁中 → 申请归还 → 管理员验机结算 → 订单完成。
• 辅助功能：租赁时长和价格计算、逾期自动提醒、租赁收入统计、相机租赁次数排行。

这个功能清单看着不少，但落到数据库表上其实只需要六张左右的核心表。这也是这个题目的另一个好处——业务丰富度够，但数据模型不过度复杂，适合在有限时间内完成。

2. 数据库模型设计：租赁业务的核心是“状态”和“时间”

2.1 六张核心表的职责划分

数据库设计是最值得花时间打磨的部分，因为后端的接口逻辑、状态流转、统计报表全都建立在这几张表之上。当时我设计的是六张表：用户表、相机表、相机分类表、租赁订单表、押金流水表（后续合并到了订单表里，但拆分出来逻辑更清楚）、操作日志表。

用户表不复杂，除了基本的id、用户名、密码、手机号之外，有一个role字段区分管理员和普通用户，还有一个credit_score字段用于记录信用分。信用分在租赁场景里是一个很有用的设计——如果用户有过逾期记录，信用分会降低，后面再下单时需要的押金比例可以提高，这个逻辑虽然简单，但是在答辩时是很好的业务亮点。

相机表需要重点关注的是状态字段和库存字段。我用的status取值为：0代表已下架、1代表在库可租、2代表全部租出、3代表维修中。注意这里"全部租出"是考虑到一个型号的相机可能有多台，所以不能简单用单条记录表示，而是用stock_total（总库存）和stock_rented（已租数量）两个字段来计算剩余可租数量。用这种设计模式，能够优雅地处理“同一款相机多台库存”的现实业务。

租赁订单表是整个系统中最核心的表，字段包括订单号、用户id、相机id、租赁开始日期、租赁结束日期、实际归还日期、订单状态、押金金额、租金单价、总费用、逾期天数、逾期费用等。我在设计时还加了一个camera_snapshot字段，用JSON格式把下单那一刻的相机名称、品牌、图片、租赁单价冗余存储了一份。这样做的原因是：如果管理员后续修改了相机价格或下架了该相机，历史订单依然能显示出下单时的真实信息，不会出现“订单里的价格跟着相机表一起变了”的尴尬情况。这是从电商系统里学到的“快照”思路，放在租赁场景同样适用。

2.2 租赁金额的计算逻辑

租赁金额看起来就是把单价乘以天数，但实际落地时有很多细节需要定义清楚。首先，租赁天数不是简单的结束日期减开始日期，而是需要遵循“按天计算、取整”的规则。比如用户选了7月1日上午10点到7月3日下午6点，如果不做约束，系统算出来是2.33天，到底收2天还是3天的钱？我的处理办法是：前端日期选择器只能选日期不能选时间，租赁天数 = 结束日期 - 开始日期，不足一天的部分按一天计算，同时通过字段校验保证结束日期必须晚于开始日期，两个日期相减至少为1。

其次，金额计算必须用BigDecimal而不是double。这算是Java开发中的经典坑了——double在计算金额时会出现精度丢失，虽然单笔订单看起来只差几分钱，但月度统计一汇总，误差就非常明显。在设计数据库字段时，金额相关字段统一使用DECIMAL(10,2)，Java代码中所有涉及金额的变量都声明为BigDecimal，这个习惯从一开始就要建立。

押金和租金的计算规则也需要提前定义清楚。我的设计是：押金 = 相机单价 × 押金比例（默认30%），可以在相机表里为每个相机单独设置押金金额，这样比统一比例更灵活。例如一台价值20000元的专业相机，每天租金可能只有200元，但押金需要6000元，这种高押金可以降低租赁风险。如果用户的信用分低于80，押金比例自动调整为50%，代码里只需要在创建订单时做一次判断。

2.3 逻辑删除与字段冗余的取舍

相机和用户表我都用了逻辑删除，也就是表中增加一个deleted字段，删除操作实际上是把deleted置为1。原因很现实：订单表通过外键关联了相机和用户，如果物理删除了相机记录，历史订单的关联查询就会出问题。虽然我们用camera_snapshot做了快照，但管理后台的订单列表仍然需要关联相机表来展示缩略图和品牌信息。如果记录被物理删除了，这些信息就只能去解析快照字段，逻辑复杂不说，还容易出错。

逻辑删除配合MyBatis-Plus使用非常方便，只需要在实体类的deleted字段上加上@TableLogic注解，框架就会自动在处理查询时追加deleted = 0条件，写入时自动管理该字段的值。但要注意一个反直觉的问题：如果某张表需要保留“已删除数据”和“未删除数据”同时参与计算的场景（比如统计累计注册用户数），逻辑删除就不适用了，这种情况下用物理删除并保留日志记录可能更合适。就这个相机租赁系统而言，逻辑删除是合理的选择。

关于字段冗余，除了刚才说的camera_snapshot，我在订单表里还冗余了username和cameraName两个字段。虽然这会违反严格意义上的第三范式，但在实际项目中，这种适度的冗余能显著减少联表查询的次数，让代码更直观，查询性能也更好。毕业设计阶段，老师更看重你能否把原理讲清楚、能否根据业务场景做出合理取舍，而不是纯粹的理论正确。

3. Spring Boot后端架构：包结构、核心接口和事务处理

3.1 按业务模块划分包结构

项目的包结构我采用的是按业务模块划分，而不是传统三层架构中按controller、service、mapper这样统一归类。两种方式各有道理，但就这个项目而言，按模块划分的代码可读性会好很多，因为每个模块的业务功能相对独立。

com.example.camerarental ├── common // 通用类：统一返回结果、异常处理、工具类 ├── config // 配置类：Spring Security、WebMvc等 ├── controller // 控制器层 ├── service // 业务逻辑层 │ └── impl ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 实体类 ├── dto // 前端交互的数据传输对象 ├── vo // 视图对象：组合了业务字段的展示对象 └── task // 定时任务：逾期检查、库存自动释放

在实际开发中，entity和dto/vo一定要分开。很多同学图省事，直接把数据库实体类返回给前端，这样做在后期会非常痛苦——比如用户信息接口如果直接把用户表实体返回，密码hash值也会跟着返回给前端，这是一个安全隐患。此外，前端需要的字段可能来自多张表的组合，比如订单列表需要订单信息加上相机封面图和品牌名，如果直接用实体类返回，每次都得手动组装Map，代码冗长且容易出错。正确的做法是定义专门的OrderVO类，在service层组装好数据后返回给controller。

3.2 下单接口：事务与库存检查的“临界区”设计

租赁下单是整个系统的核心接口，也是并发风险最高的地方，因为它涉及两步操作的原子性：扣减库存和创建订单记录。如果这两步中间发生了异常——比如库存扣了但订单创建失败——就会出现库存被白白扣掉的bug。Spring Boot解决这个问题的方式就是@Transactional事务注解。

需要注意的一点是，库存扣减不能简单用先查询再更新的方式，也就是不能写成“先select剩余的库存数量，大于0就减少1”。这种写法在高并发场景下会有严重的并发问题：多个请求同时读到相同的库存数量，同时执行减1操作，最后导致超卖。正确做法是使用乐观锁机制，在更新语句中带上条件判断，类似这样：

UPDATE camera SET stock_rented = stock_rented + 1, version = version + 1 WHERE id = ? AND (stock_total - stock_rented) > 0 AND version = ?

对应到MyBatis-Plus里，可以通过UpdateWrapper设置setSql("stock_rented = stock_rented + 1")来实现这种原子更新。执行UPDATE后再检查受影响的行数，如果为0，说明库存已不足，直接抛出业务异常让事务回滚。这个设计在答辩中属于高频亮点，一定要能够解释清楚“为什么先查再改会出问题”。

下单接口的整体流程是这样的：校验用户信用分是否正常 → 校验相机状态是否上架 → 校验租赁日期是否合法 → 使用乐观锁扣减库存 → 创建订单记录，初始状态为“待取机” → 生成押金流水。整个方法加上@Transactional(rollbackFor = Exception.class)，意味着任何一步抛出异常，前面的数据库操作都会回滚。

3.3 归还接口：业务流程比接口更复杂

归还功能的逻辑比下单要复杂得多，因为它不只是把订单状态改一下、把库存加回去这么简单，还涉及费用结算。我的实现流程是：

• 用户提交归还申请，订单状态更新为“待归还确认”。
• 管理员核对相机实际状况，如果外观和功能完好在可接受范围内，确认归还。
• 系统计算实际租赁天数：从取机日期（订单中的租用开始日期）到归还日期，而不是当初下单时预选的结束日期。
• 计算总租金，如果存在逾期，额外计算逾期费用（每日罚金 = 日租金 × 1.5）。
• 从押金中扣除租金和逾期费用后，剩余金额原路退回（模拟退款逻辑，记录流水）。
• 相机库存中的stock_rented减1，如果status因为“全部租出”变成2，则自动恢复为1。

在写归还接口时，要注意一个容易忽略的点：所有金额计算完成之后，一定要生成一条资金流水记录，包含原始押金、总扣款、退款金额、操作时间等字段。这不仅是业务流程的需要，也是审计的依据。退押金的金额如果有零有整，还要考虑是否需要进行人工确认，做一个简单的金额异动标记功能会显得系统更专业。

另外，整个归还操作同样需要加上事务控制。因为这里涉及多个表的更新：订单表修改状态和实际归还日期、相机表释放库存、流水表新增记录。任何一步失败，都可能导致用户押金被扣了但订单没完成、或者相机库存没释放的情况，这在实际业务中都是严重的事故。

4. 订单状态机：让租赁生命周期“看得见、管得住”

4.1 状态定义与流转规则

租赁订单的状态是系统业务逻辑的中枢，我在设计时定义了以下状态，用整数值存储在数据库的status字段中：

把这五种状态画成图，会发现它们的转换不是任意两个节点间都能互通的。从“待取机”可以取消或进入租赁中；从“租赁中”可以申请归还，也可能因为超过归还日期自动转为逾期；从“逾期”状态下用户仍可归还，但需要额外支付罚金。这些规则我直接以状态机的形式固化在代码中，把状态转换的逻辑集中在一个工具类或Service层方法中，而不是散落在各处。

4.2 状态流转代码实现的两种方式

第一种方式是简单地在Service方法中直接set status字段，每次流转都写一遍判断。开发速度快，但随着状态增多，代码里会出现大量重复的if判断，而且很容易漏判某条路径，导致非法的状态跳转。

第二种方式是定义一个专门的RentalOrderStateMachine类，把每种状态及允许执行的动作集中管理。比如定义一个Map来存储状态与可执行操作的映射关系，每次状态变更前先校验当前状态是否允许该操作。这种方式在代码层面更优雅，在答辩时也更有话讲——你可以展示状态机的设计思路、复杂业务下如何用状态模式保持代码整洁。我当时采用的是第二种方式的简化版：在OrderService里维护一个状态流转校验方法，每次调用更新状态的私有方法之前先调用它做校验。

有一个实际的坑要注意：状态更新操作不能先查对象、然后set状态、再用updateById保存，因为这样在多线程下会存在丢失更新的问题。正确做法是使用LambdaUpdateWrapper，以订单id和当前状态作为条件，执行更新时校验当前状态是否为期望的旧状态，如果更新影响行数为0，说明状态已经被其他请求改了，需要重新加载或抛出异常。

4.3 逾期处理：定时任务与延迟消息的取舍

逾期是租赁场景的特有需求。我的实现方案是使用Spring Boot自带的@Scheduled定时任务，每天凌晨2点扫描一次订单表，找出满足“订单状态为租赁中且计划归还日期早于当前日期”的记录，将其状态更新为已逾期并累计逾期天数。

不过定时任务有个缺点：扫描频率决定了响应的实时性。比如用户是晚上11点59分逾期的，定时任务到凌晨2点才扫描，那这段时间系统里该订单的状态还是“租赁中”，如果管理员刚好在前台查看订单，看到的可能就是不准确的状态。对毕业设计来说，这个滞后是可以接受的。但如果你想做得更精细，可以在用户归还时动态计算计划归还日期和当前日期的差值，即使状态还没被定时任务扫到，系统在计算逾期费用时依然能正确算出金额。

另外，不要在归还接口里直接修改逾期费用字段，而是在每次计算时根据实际归还日期和计划归还日期实时计算。这样做的好处是，如果管理员调整了归还确认日期，逾期费用能自动正确更新，不会出现手改数据导致的不一致。

5. 权限控制与前端交互：区分“谁在用什么功能”

5.1 Spring Security的集成

一个完整的租赁系统必须区分管理员和普通用户，否则任何登录用户都能执行管理员操作，系统就失去了意义。为完成权限控制，我引入了Spring Security框架，这是Spring家族中最成熟的安全方案。

配置上主要做四件事：自定义登录接口的路径和参数格式；配置请求路径的权限规则；集成自定义的UserDetailsService来加载用户信息；用BCryptPasswordEncoder对用户密码进行加密存储。

配置路径权限的核心代码在SecurityConfig中，需要明确哪些精确匹配的路径需要哪些角色。比如/admin/**前缀的路径需要ROLE_ADMIN角色才能访问，其他所有接口只需要登录即可。我使用的Spring Security版本是基于Spring Boot 3的，配置类需要继承WebSecurityConfigurerAdapter的方式已经被废弃，改为以SecurityFilterChain的Bean方式来定义。这个细节很重要，因为网上大量旧教程还在用已经过时的写法，照着抄会直接启动报错。

5.2 JWT还是Session？

对前后端分离的毕设项目来说，JWT和Session两种方案都可行。我最终选择的是JWT方案，原因是它不需要在服务端存储会话状态，后端只需要在过滤器里校验token的签名和过期时间，实现更简单，也更符合现在业界的主流趋势。

具体过程是：用户登录成功后，后端生成一个包含用户id和角色的token返回给前端。前端将token存储到本地，在后续请求的Authorization头中带上。后端写一个OncePerRequestFilter的子类，在每次请求时从请求头中解析token，校验合法性后把用户信息存入上下文，供后续调用获取。

需要注意的一个坑是：JWT从生成那一刻起就确定了过期时间，如果用户在此期间被管理员禁用，原有的token在过期前依然有效。所以在每次请求校验时，我还会查一次用户表确认用户的status字段为正常状态，被禁用用户的请求会被立即拒绝。这种“双重校验”把无状态token的有状态检查补上了，业务层面会更安全。

5.3 接口返回结构的统一处理

这个系统涉及几十个接口，如果每个接口返回的数据结构都不一样，前端对接时会非常痛苦。我定义了一个统一的返回类Result，包含code、message和data三个字段，一切正常返回时code为200，业务异常时抛出自定义的BizException并返回对应的错误码。

用@RestControllerAdvice做全局异常处理，是让代码简洁的关键。在Controller中不需要手写try-catch捕获业务异常，只需要抛出BizException（携带错误码和提示信息），全局异常处理器会统一捕获并封装成Result对象返回。这样既统一了错误返回格式，也避免了大量重复的异常处理代码。作为加分项，这个全局异常处理器还处理了参数校验异常和系统内部异常，参数校验异常返回400和具体的错误提示，系统内部异常则统一返回500并记录日志，不会把详细的堆栈信息暴露给前端。

6. 定时任务与统计报表：让数据“说话”

6.1 租赁统计报表的设计思路

毕业设计如果能有一个像样的统计模块，整体会给人留下“这系统不只是一个CRUD”的印象。我的统计模块实现了三个核心指标：

相机租赁热度排行：通过订单表按camera_id分组统计租赁次数，同时关联相机表获取名称和品牌，按租赁次数降序排列。可以用MyBatis-Plus的queryWrapper加上groupBy和orderByDesc实现。

每日营收趋势：统计每天完成的订单金额总和，实现方式是查询已归还订单按日期分组求和。这里会遇到时区的问题——订单的创建时间和完成时间之间有几天甚至更长的跨度，统计时选择的基准日期用create_time还是actual_return_time，两者反映的统计口径完全不一样，需要自己先明确选哪个。

热门分类分布：统计各类目下的相机租赁次数占比，用饼图展示效果最好。这个查询需要订单表关联相机表，再关联分类表，可以在SQL中使用join，也可以在后端用Java代码分步查询再组装。数据量不大的情况下，后者的可读性和维护性反而更好。

6.2 定时任务与缓存更新

统计数据和实时性之间存在一个矛盾：查询操作如果每次都实时计算，虽然数据最新，但会给数据库带来不必要的压力（尤其在数据量增大后）。一个折中方案是定期把统计结果缓存起来，比如每天凌晨用定时任务重新计算并存入一张统计表，或者存入Redis缓存。在毕业设计中，我采用的是定时任务每天早上计算一次存入缓存，统计页面直接读取缓存数据展示。

同时，系统还有一个定时任务专门处理“逾期提醒”。每天早9点扫描所有租赁中的订单，如果发现计划归还日期到今天已经不足1天（明天到期），就给该订单的用户发送提醒通知。这里我用的是模拟短信记录，也就是往提醒记录表里插入一条记录并在用户端展示，不会真的接第三方短信接口。但因为这个逻辑的存在，系统把一个真实的业务功能闭环完整做出来了，而不仅是停留在数据库层面。

需要注意一个细节：定时任务的执行默认是单线程串行的。如果系统中存在多个定时任务，需要留意它们是否互相影响，比如统计任务比较耗时，逾期任务的执行会被延后。这种情况下可以给不同类型的任务指定不同的线程池执行，这也是可以在答辩时提到的优化点。就这个系统而言，数据量不大，单线程完全够用。

7. 开发过程中踩过的坑和调试技巧

7.1 MyBatis-Plus自动填充时间字段的坑

在设计用户表和订单表时，我设置了create_time和update_time两个字段，希望通过MyBatis-Plus的自动填充功能来统一管理。实现方式是在实体类的时间字段上加上@TableField(fill = FieldFill.INSERT)和@TableField(fill = FieldFill.INSERT_UPDATE)注解，然后定义一个MetaObjectHandler接口的实现类来处理插入和更新时的字段赋值。

这个方案一开始非常顺利，但后来发现了一个奇怪的现象：在归还接口里，我用UpdateWrapper更新订单状态的同时，update_time字段并没有自动更新。查阅文档后发现，MetaObjectHandler的自动填充只对通过实体对象的方式执行更新时生效。如果用UpdateWrapper指定了更新setSql，实体对象的字段已经不完全对应数据库的更新逻辑了，自动填充自然就失效了。

解决办法是在调用update方法前，手动往UpdateWrapper的set部分添加update_time字段的值为当前时间。这个坑很小，但调试起来花了几个小时才找到原因，作为经验分享给正在做同类型项目的同学，能节省不少排查时间。

7.2 初始化数据的重要性

一个只包含空表数据的系统，不管功能多完整，演示效果都会大打折扣。为了给前端开发和毕业答辩提供足够的展示数据，我在resources目录下放了一个data.sql脚本，里面包含：

• 8个分类：单反相机、微单相机、卡片相机、镜头、三脚架、摄影灯、无人机、运动相机。
• 20台相机，价格从几百元的脚架到几万元的专业摄影机都有覆盖。
• 10个测试用户，账号统一用password123密码，方便演示时快速切换角色。
• 若干条订单数据，覆盖各种订单状态，让首页和统计页在第一次打开时就有内容可看。

Spring Boot通过配置spring.sql.init.mode=always可以自动执行data.sql，这样每次部署后能快速得到一个数据完整的环境，前端的联调效率也会大幅提升。顺便要说的是，data.sql里的数据如果和表结构的主键策略冲突，有可能插入失败。解决的办法是采用显式的主键值（各数据行指定明确id），避免依赖自增策略，这样每次执行都能稳定插入。

7.3 前端页面调试的真实体验

这个项目的前端我用的是一套基于原生HTML+CSS+JavaScript的管理模板，页面由后端渲染。前端代码不复杂，但开发中最耗时间的反而不是功能，而是各种微小的样式问题，比如支付弹窗在不同分辨率下的适配、表格在窄屏下的滚动、状态标签在不同状态下显示不同颜色的逻辑等。这些不会出现在教科书里，但恰恰是实际开发中最真实的体验。

如果前端基础比较薄弱，最省力的方式是直接使用现成的开源后台模板，像基于Bootstrap或Layui的免费模板可选项很多，拿到以后只需要替换接口请求部分，页面样式已经现成。做毕设的核心还是后端业务实现，前端页面够用即可，不要以“写一个惊艳的前端”为目标来分配时间。

7.4 日志：解决疑难杂症的关键

在整个开发过程中，真正帮助我定位问题的不是debugger也不是冥想，而是日志。我在项目里采用了SLF4J+Logback作为日志框架，在关键业务节点（创建订单、归还确认、状态流转、定时任务的执行结果）都加了info级别的日志，在catch块里加了error级别的日志并输出完整堆栈。

启动时报错、接口返回异常、数据不一致……这些问题排查的第一步永远是去看日志。很多同学遇到运行报错习惯性地把报错信息直接复制到搜索引擎，但往往真正有用的线索在日志更早的位置。学会从堆栈中定位到具体是哪个类的哪一行代码出问题，是后端开发的基本功，这个项目就是训练这个基本功的好机会。

8. 答辩准备：怎么讲清楚这个项目

8.1 讲述主线的设计

答辩时切忌把PPT上所有页面从头到尾念一遍，也不要把系统的每个功能都拿出来讲。正确做法是围绕一条主线展开：先说业务痛点（相机价格高、租赁需求存在），再说系统功能如何响应该需求，最后落到关键技术点是如何实现业务目标的。

我的展示顺序是：业务背景与需求分析 → 功能架构图与用例图 → 数据库ER图设计思路 → 核心流程（下单、归还、逾期）演示 → 技术难点与解决方案。答辩陈述大概控制在8到10分钟，时间分配上可以先快速带过基础功能，把主要时间留给核心业务逻辑和项目亮点。

8.2 高频问题的应答思路

答辩老师综合提出的问题往往集中在几个方向。数据库设计相关：为什么相机表要拆出分类表？为什么订单表中要冗余相机快照字段？业务逻辑相关：订单状态是如何管理的？逾期和归还的边界情况怎么处理？并发相关：库存扣减如何保证不超卖？解决思路要结合前面的乐观锁方案来解释。安全相关：如何防止普通用户通过接口篡改订单？

其中“如何防止普通用户直接调用管理员接口”是个经典必问题。除了Spring Security的角色权限控制，还需要在业务层校验数据归属——比如用户A不能查看或操作自己订单之外的订单，可以在接口中先获取当前登录用户id，再比对订单表中的用户id，如果不一致就拒绝访问。这种“接口级归属校验”在答辩中特别能体现对安全的思考深度。

8.3 源码演示时的演示路径预设

答辩现场最怕的是演示时数据不友好、操作路径不清晰。我建议提前准备一条完整的演示路径，并在答辩前反复走两遍。我当时的演示路径是：用管理员账号登录 → 浏览统计页面，展示营收报表 → 进入相机管理，新增一台相机 → 切换到用户账号 → 浏览相机，下单一台 → 管理员端审核订单，确认取机 → 用户端申请归还 → 管理员确认归还 → 回到订单列表展示状态流转 → 切回统计页面展示数据变化。

整条路径把系统的主要业务全部串起来了，而且过程直观，老师可以看到每一步操作如何影响系统状态。如果在演示过程中出现数据异常，也要能从容地展示出你排查问题的思路——准备几条日志定位、数据修正的应急方案会让答辩过程更有底气。

最后再分享一个实际开发中的体会：这个系统的业务复杂度不算高，但它完整走过了需求分析、表结构设计、后端实现、前端联调、测试与部署的整个流程。你亲手写完的不只是一个毕业设计，而是一套标准的Web项目开发方法。做完这个项目，你再去看市面上其他管理系统类的项目，无论是Spring Boot的还是别的技术栈的，会发现核心逻辑大同小异。把基础打扎实，后面不管是找工作还是继续深造，这份项目经验都能转化成你的底气。