企业官网建设流程全解析

1. 项目概述与整体设计思路

做毕设选题的时候，很多同学都会在“管理系统”这类题目里打转。图书管理、学生管理、仓库管理系统这些题目被做了无数遍，功能雷同、逻辑单一，答辩的时候老师一眼就能看出工作量够不够。我当时选汉服租赁系统，就是看中它跟传统CRUD管理系统有一个本质上的区别——它带了一条完整的业务链路：用户浏览汉服、下单租赁、支付押金、平台发货、用户穿着归还、平台检查验收、退还押金。这条链路涉及的不仅仅是增删改查，还有库存、订单状态流转、押金结算、逾期费用计算等真实商业场景里的核心逻辑。

1.1 项目定位与需求拆解

先明确一下这套系统的定位。它不是电商平台那种“卖货”模式，而是“租赁”模式，核心差异在于商品的所有权不发生转移，用户只购买一段时间的穿着权。这个定位决定了系统的关键需求：

• 库存管理不是简单的“有货/无货”，而是需要区分“可租库存”和“在租库存”。一套汉服被租出去之后，它就不再处于可租状态，归还且验收合格后才能重新上架出租。
• 订单不是“支付完成就结束”，而是基于状态机流转——待支付、已支付（待发货）、租赁中（已发货）、待归还、已归还（待验收）、已完成、已取消、已逾期。
• 押金处理是独立于租金的资金流。用户下单时需要同时支付租金和押金，归还验收通过后才能退押金，如果产生逾期或损坏，需要从押金中扣除相应费用。
• 尺码库存是一个独立的维度。一套汉服通常有S、M、L、XL等多个尺码，用户选择不同尺码实际上是选择了不同的库存单元，下单时需要锁定对应尺码的库存。

从技术实现的角度，这些需求落到系统里其实就对应着几个核心难点：库存扣减与释放的时机控制、订单状态的闭环流转、押金和费用的精确计算。这几个点恰恰是毕设答辩时最能展示业务理解能力的地方。

1.2 技术选型：为什么用Spring Boot

技术选型可能是整个毕设里第一个决定性的选择。我最终确定的技术栈是：Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis（用于验证码缓存）+ JWT（用于身份鉴权），前端用的是Vue 3 + Element Plus。

这个组合几乎是当前Java毕设的主流配置，但不是跟风，而是有实际理由的。Spring Boot的优势在于“开箱即用”——内嵌Tomcat，不用单独部署外部容器；自动配置机制让数据源、事务、静态资源映射这些杂事都变成了几个注解的事。它自带的spring-boot-starter-validation可以优雅地处理参数校验，spring-boot-starter-aop配合自定义注解可以实现权限切面。对毕设来说，最重要的是它的社区生态足够成熟，遇到任何问题几乎都能搜到现成的解决方案，这对独立完成项目的学生来说价值很大。

MyBatis-Plus选了它而不选Spring Data JPA，原因是租赁系统的查询场景很杂。管理员后台需要按状态、按日期、按关键字组合筛选订单，用户端需要按分类、按价格排序筛汉服。MyBatis-Plus的LambdaQueryWrapper写着顺手，分页插件配置起来也简单，而且它自带的逻辑删除功能可以直接应对“汉服下架但不删历史订单关联数据”的需求。相比之下，JPA的规范方法名推断在这种复杂查询场景下反而有点费劲。

1.3 系统角色与权限划分

系统分三类角色：普通用户、管理员。为了答辩时有展示空间，我还在管理员里细分了“运营管理员”和“超级管理员”的权限差异。

普通用户能做的操作：注册登录、浏览汉服列表和详情、按分类筛选、加入购物车、创建租赁订单、支付（模拟）、查看订单进度、确认收货、发起归还申请、查看押金退还记录、提交评价。

管理员能做的操作：汉服管理（上架、下架、编辑库存、设置租金和押金）、分类管理、订单管理（发货、验收、确认归还、处理逾期）、押金管理（退还、扣款）、用户管理（禁用/启用）、数据统计（租赁热度、营收、逾期率）。

权限这块我用的是JWT + 拦截器。登录成功后后端签发JWT，里面包含userId和role两个核心声明，前端把token存到localStorage里，每次请求在Authorization头带上。拦截器解析token后把用户信息放到ThreadLocal里供后续业务使用，同时校验访问的接口是否需要特定角色权限。

注意：很多毕设的权限就做个登录校验，所有登录用户都能访问管理接口，这不叫权限设计。建议至少区分“用户”和“管理员”两类角色，用注解或拦截器做接口级别的权限控制，答辩时这块是个加分项。

1.4 架构分层与服务规划

代码结构上我严格按照MVC分层来组织。controller层只做参数接收和响应封装，service层承载核心业务逻辑，dao层通过MyBatis-Plus的BaseMapper提供数据访问。额外加了一个handler包放全局异常处理，一个config包放配置类（跨域、拦截器、MyBatis-Plus分页插件），一个utils包放JWT工具类、订单号生成器等通用组件。

很多人觉得毕设代码分层不重要，功能跑通就行。但我想说的是，答辩时老师有可能会翻你的代码结构。清晰的包结构、有意义的类名方法名、统一的返回结果封装，这些“表面功夫”能直接影响老师对你代码能力的判断。我在controller里所有接口都返回统一的Result对象（code + message + data），前端处理起来非常统一，全局异常处理器把业务异常和系统异常分开处理，返回给前端的是友好的提示而不是一堆堆栈信息。这套规范看起来简单，但如果你做过联调就会被各种不统一的返回结构折磨到崩溃，提前统一能省非常多的沟通成本。

2. 数据库设计与核心表结构

数据库是整个系统的地基。我见过太多毕设把所有的费用、状态都设计成用户表里的一个字段，这看起来很省事，但业务一旦复杂起来就会出问题。租赁系统的数据模型核心是一个相对标准的电商式模型加上租赁特有的字段扩展。

2.1 核心数据表概览

我的数据库一共设计了10张表，核心的几张如下：

2.2 关键设计：SPU与SKU的拆分

表设计中一个必须讲清楚的点是SPU和SKU的拆分。简单来说，SPU是商品，SKU是具体可卖的库存单元。一套“齐胸襦裙”是SPU，它有“S码 红色”“M码 蓝色”等多个SKU。租赁场景下，一套汉服的不同尺码在物理上是不同的实体衣物，用户选择了哪个尺码，就必须锁定哪个尺码的库存。

hanfu_sku表里的stock_total代表这个尺码的总库存，stock_rented代表当前正在被租借的数量。可租数量 = stock_total - stock_rented。为什么不直接在订单表里做个数量扣减就算完事？因为租赁和购买不一样，购买是永久性的库存扣减，租赁的库存在归还后要恢复。如果直接把stock_total减掉，归还的时候还得再加回来，而如果中间有人下单又取消，库存恢复的时机就会非常混乱。用stock_rented单独记录在租量，下单时增加stock_rented，归还验收后减少stock_rented，stock_total永远不变，可租量永远可以通过计算得出，逻辑既清晰又不容易出错。

2.3 订单状态机的表设计实现

lease_order表里的status字段是整个系统业务流转的核心。我定义了一组状态常量，用int值存储，在代码里定义成一个枚举类：

public enum OrderStatus { PENDING_PAYMENT(0, "待支付"), PAID(1, "已支付待发货"), RENTING(2, "租赁中"), PENDING_RETURN(3, "待归还"), RETURNED(4, "已归还待验收"), COMPLETED(5, "已完成"), CANCELLED(6, "已取消"), OVERDUE(7, "已逾期"); private final int code; private final String desc; }

为什么用int而不是字符串？一个是节省存储，另一个是状态流转时判断更方便。但一定要建一个状态流转表或者在代码注释里写清楚每个状态允许流转到哪些状态。比如：PENDING_PAYMENT可以流转到PAID（用户支付成功）或CANCELLED（用户取消或超时未支付），但RENTING绝对不能跳回PENDING_PAYMENT。这个约束在代码里拦截，前端按钮根据状态控制显隐，后端接口也要校验状态合法性，不能完全信任前端传过来的参数。

2.4 时间字段与租期计算的陷阱

租赁业务离不开日期计算，这块有几个细节很容易翻车。用户下单时选择租期天数（比如3天、5天、7天），系统根据下单时间生成startDate和endDate。startDate我设置为下单日期加一天，因为当天下单当天发货需要一个缓冲，endDate = startDate + leaseDays。

归还日期的判断逻辑是：用户发起归还申请时，系统比较当前日期与endDate。如果当前日期在endDate之前，按正常归还处理；如果超过endDate，需要计算逾期天数。逾期天数直接用java.time.temporal.ChronoUnit来计算：

long overdueDays = ChronoUnit.DAYS.between(order.getEndDate(), LocalDate.now());

这里有一个坑：用Date类做日期计算时，跨天、时区的问题很容易搞出偏差。我自己一开始用的是java.util.Date，后来索性全部改成LocalDate和LocalDateTime。LocalDate只处理日期不处理时间，非常适合租期这种“按天算”的场景。数据库对应字段也用date类型，MyBatis-Plus会自动转换，省去了手动解析的麻烦。

押金退还时也需要计算时间，但这块我说一句实话：毕设里不需要把利息、资金占用费这些东西加进去，押金记录表里记录原始押金、扣除金额、退还金额就够了，时间只作为一个审计字段保留。

3. 核心功能模块与关键实现细节

功能模块是整个系统的血肉，每个模块拆开来看都有值得细讲的实现逻辑。这一章我会把最核心的几个模块逐个过一遍，重点不是“做了什么”，而是“怎么做、为什么这么做”。

3.1 登录鉴权与JWT落地

登录功能表面上简单，但要做到“可答辩”的程度，有几个点必须处理干净。密码存储绝对不能明文，我用的是BCrypt加密，Spring Security自带的BCryptPasswordEncoder可以直接拿来用。

// 注册时加密存储 String encodedPassword = passwordEncoder.encode(user.getPassword()); user.setPassword(encodedPassword); // 登录时校验 boolean matches = passwordEncoder.matches(rawPassword, user.getPassword());

为什么要单独拿出来说？因为很多同学图省事用MD5加密，然后给老师解释“MD5是不可逆的”。但MD5其实是可逆的——彩虹表可以秒破弱密码，而且相同密码加密结果相同，这是很明显的问题。BCrypt是加盐的哈希算法，同样的密码每次加密结果都不同，安全性高了一个档次，而且用法跟MD5一样简单，没有任何理由不用它。

JWT的生成和校验我封装成了一个工具类。生成时往payload里放userId、username、role三个信息，设置2小时的过期时间。每次请求到达后端，拦截器通过OncePerRequestFilter实现，从Authorization头里取出token，解析成功后把userId和role放入ThreadLocal。

有个关键细节：ThreadLocal用完一定要remove，否则高并发下线程池复用会导致用户信息串号。这个问题很隐蔽，但一旦出现就是线上大事故。我在拦截器的afterCompletion方法里强制remove，养成这个习惯比出了问题再排查要省事得多。

3.2 用户端下单选款流程

用户的下单流程是我花了最多心思设计的环节。核心链路是：从汉服详情页点击“立即租赁”→ 选择尺码、租期天数 → 后端校验库存 → 创建订单（状态为待支付）→ 用户支付租金+押金 → 发货。

这里有一个业务设计的选择：是先锁定库存还是支付后再锁定库存？真实租赁平台的做法是支付后锁定，因为如果下单就锁定，用户不支付会导致库存被白白占用。但完全等到支付再锁定也有风险——用户支付成功后才发现库存被别人抢走了。我采用的方案是：创建订单时锁定库存（即stock_rented + 1），订单超过30分钟未支付则自动取消并释放库存。这个方案兼顾了用户体验和库存利用率，实现上需要配合定时任务：

@Scheduled(fixedRate = 60000) public void autoCancelExpiredOrders() { LocalDateTime deadline = LocalDateTime.now().minusMinutes(30); List<LeaseOrder> expiredOrders = leaseOrderService .list(new LambdaQueryWrapper<LeaseOrder>() .eq(LeaseOrder::getStatus, OrderStatus.PENDING_PAYMENT.getCode()) .lt(LeaseOrder::getCreateTime, deadline)); for (LeaseOrder order : expiredOrders) { leaseOrderService.cancelOrder(order.getOrderId()); } }

@Scheduled是Spring Boot自带的任务调度，加一个@EnableScheduling就能用，毕设这种轻量场景完全够用，不需要引入额外的任务框架。

3.3 库存扣减与并发安全

库存扣减是这类系统里最容易出并发问题的地方。如果不加任何保护，两个用户同时下单抢同一个SKU的最后一件，都有可能扣减成功，导致超卖。解决的方案有几种：

第一种是数据库层面的乐观锁。在hanfu_sku表加一个version字段，更新时带上版本号：

UPDATE hanfu_sku SET stock_rented = stock_rented + 1, version = version + 1 WHERE id = ? AND version = #{version}

更新行数为0说明版本冲突，需要重试或者提示用户库存不足。MyBatis-Plus对乐观锁有现成的支持，在实体类上加@Version注解，配置一个乐观锁插件就能自动处理。

第二种是Redis分布式锁。用setIfAbsent实现一个简单的互斥锁，锁的key是SKU的ID，拿到锁的线程才能执行扣减逻辑。考虑到毕设的并发量，乐观锁方案简单可靠，代码侵入性小。我最终用的是乐观锁。

这里要提醒一句：库存扣减和订单创建必须在同一个事务里执行。如果订单创建成功但扣减失败，事务回滚，两边都不会落地；如果扣减成功但订单创建失败回滚，扣减也会被撤销。跨表操作的一致性靠的是数据库事务，不是靠代码里的if判断。

3.4 订单号生成策略

订单号看起来是个小事，但设计得不好会出实际问题。我用的是“时间戳 + 用户ID后四位 + 随机数”的组合，生成逻辑如下：

public static String generateOrderNo(Long userId) { String timePart = LocalDateTime.now() .format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss")); String userPart = String.format("%04d", userId % 10000); String randomPart = String.format("%04d", new Random().nextInt(10000)); return timePart + userPart + randomPart; }

这套方案能保证单机并发下不重复，而且从订单号里能直接看出下单时间和用户信息，排查问题时非常方便。不要用UUID直接当订单号，虽然不重复，但太长了，不好记不说，用户看到一堆没有规律的字符串体验也很差。

3.5 押金退还与逾期费用计算

押金是整个租赁系统里最能体现行业特色的环节。用户在创建订单时需要同时支付租金和押金，但业务上这是两笔不同性质的资金：租金是消费，不会退；押金是保证金，会退。

在数据库上我用payment_record表记录订单的支付流水，用deposit_record表单独记录押金的收取和退还。为什么要单独一张表？因为押金退还经常不是全额——用户逾期了要扣费，衣服有污损要扣清洗费，这些扣款明细必须沉淀到押金流水表里，每笔扣款都有备注说明，用户查看退押金记录时才能明白为什么退少了。

押金退还的触发时机是：用户发起归还申请，管理员收到归还的汉服后验收入库，验收通过后系统自动触发押金退还操作。如果存在逾期，系统计算逾期费并确认扣款，剩余押金原路退回。

逾期费的计算逻辑我单独写了一个方法。规则是：逾期第1天收取租金的20%，之后每天收取租金的10%。这个方法在归还验收时调用来生成扣款金额。

public BigDecimal calOverdueFee(LeaseOrder order) { if (order.getOverdueDays() <= 0) { return BigDecimal.ZERO; } BigDecimal dailyRent = order.getTotalRentalFee(); BigDecimal firstDayFee = dailyRent.multiply(new BigDecimal("0.20")).setScale(2, RoundingMode.HALF_UP); if (order.getOverdueDays() == 1) { return firstDayFee; } BigDecimal restDaysFee = dailyRent .multiply(new BigDecimal("0.10")) .multiply(new BigDecimal(order.getOverdueDays() - 1)) .setScale(2, RoundingMode.HALF_UP); return firstDayFee.add(restDaysFee); }

金额计算里必须用BigDecimal，这是这样一句说了无数遍的话，但还是会有人用double。double在计算0.1+0.2的时候会得到0.30000000000000004，涉及钱出这种精度问题，答辩的时候被老师看到基本就是送人头。

4. 管理后台与数据统计模块

管理后台存在的意义是让业务闭环的用户侧操作有对应的管理能力。没有后台，订单状态流转根本走不完——谁来发货？谁来验收？谁来处理逾期？这些问题都需要后台功能来承接。

4.1 汉服管理与上下架机制

汉服管理的核心不只是增删改查，而是“上下架”这个状态流转。一套汉服上架后用户才能看到、才能下单；下架之后用户端不再展示，但已经存在的租赁订单不受影响，该归还归还，该退款退款。所以hanfu_info表里的status字段有三态：上架、下架、删除。删除用的是MyBatis-Plus的逻辑删除功能：

@TableLogic private Integer deleted;

配置逻辑删除之后，MyBatis-Plus生成的SQL会自动加上WHERE deleted = 0条件，不用自己在每个查询里写，也不用真的把数据从数据库里物理删掉。历史订单关联的汉服数据被删掉会导致联查时出现空引用，逻辑删除恰好避免了这个问题。

管理端编辑库存时，要注意的是只能修改stock_total，不能直接修改stock_rented。stock_rented只能由订单流程的代码修改。如果管理员强行改了在租量，会导致可租量的计算失真，这个在过去踩过的坑，所以我在后台只暴露了总库存编辑入口。

4.2 订单全流程管理与异常处理

后台订单管理页面，需要支持按订单号、用户昵称、订单状态多条件筛选。订单详情页展示订单的所有信息及当前状态，操作按钮根据状态动态匹配：

• 待支付状态：可取消订单（释放库存）
• 已支付待发货：可执行发货操作（订单状态变更为租赁中，租期开始计算）
• 租赁中状态：可查看租期、发起归还提醒
• 待归还状态：用户已发起归还申请，不再有管理端操作
• 已归还待验收：执行验收操作，填入验收备注（完好/有污损/有损坏），系统根据验收结果触发押金退还

这里有一个容易搞混的点：谁来发起归还？我的设计中，用户在订单详情页点击“申请归还”，提交后订单进入“待归还”状态。管理员在后台看到“待归还”的订单，执行“验收归还”后，订单才进入“已完成”并触发退押金流程。如果用户一直不点归还，租期过了也没用，所以我在系统里加了一个每日自动扫描的定时任务，超过endDate还没发起归还的订单，自动置为“已逾期”状态，同时在用户端高亮提示。这个设计让“逾期”不再依赖用户自觉申报，系统有主动发现机制，逻辑上是更完整的一条闭环。

4.3 数据统计如何做出价值感

数据统计这块，很多毕设就是做了几个饼图柱状图，把全部数据拉出来画一画就算完事，答辩老师一问“这个统计能说明什么运营问题”就哑了。我的思路是统计模块要能回答具体的业务问题。

第一个统计视角是租赁热度排行。统计前10款被租赁次数最多的汉服，配上分类维度的占比，可以回答“哪些款式的汉服更受欢迎，运营要不要调整采购方向”。

第二个统计视角是营收分析。按月统计租金收入、押金扣除收入（逾期和赔偿）的走势，可以回答“这个租赁业务的收入结构是什么样，押金扣除收入占比高说明服务质量有问题”。

第三个统计视角是逾期率分析。统计所有已完成订单里有逾期记录的占比，以及平均逾期天数，可以回答“租期设置是不是不合理，需不需要调整默认租期天数”。

这三个统计在SQL层面都不复杂，一个group by加几个聚合函数就能查出来，关键是要懂背后的业务含义。当你在答辩时能把这些统计和运营决策联系起来，整个项目的价值感就完全不同了。毕设不但要“能用”，要追求“有思想”，统计模块是最容易体现这点的地方。

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

做毕设的过程就是不停踩坑和填坑的过程。这一章把我实际开发中遇到的典型问题和排查方法整理出来，按出现频率排序，给后面做类似系统的人一个速查参考。

5.1 数据库连接时分秒丢失

第一个坑就属于典型的技术细节。订单的endDate明明设置的是2025-06-10 23:59:59，从MySQL里查出来却变成了2025-06-10 00:00:00。排查下来发现是驱动连接池配置的时区问题。在jdbc连接串里加上serverTimezone=Asia/Shanghai，以及配置useSSL=false避免不必要的警告，再把MyBatis-Plus关于日期类型的映射核对了一遍才解决。

注意：不要觉得这个坑小就跳过。租期计算、逾期判断完全依赖时间精度，如果时区不对，所有跟时间相关的业务都会出现偏移。

5.2 级联查询导致N+1问题

订单列表页要展示关联的汉服信息和用户信息。最开始用MyBatis-Plus的getById在for循环里查询关联表，查50条订单会执行100多次SQL查询，页面响应时间明显变慢。排查方法是开启了MyBatis的SQL日志（mybatis-plus.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl），看到日志里大量重复查询才发现问题。

解决方式有两种：一种是联表查询一次查出所有数据，另一种是查出订单列表后，收集所有关联ID，用in查询一次性查出关联数据，再在内存里做映射。毕设场景用后者更实用，配合MyBatis-Plus的selectBatchIds非常方便。

5.3 图片上传后前端无法访问

用户和管理员都要上传汉服图片，上传的文件如果被保存在项目根目录的某个文件夹下，重启后文件就丢了（因为是打包在jar包里的），或者线上部署时前端跨域访问不了。这是毕设中最常见的文件存储踩坑点。

我的解决方式是：用配置文件指定一个固定上传目录，比如E:/hanfu_rental/upload/，然后把该目录映射为静态资源路径，通过配置类实现：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourcePaths("file:" + uploadPath); } }

这样一个简单的配置就能让上传的图片通过http://localhost:8080/upload/xxx.jpg访问，同时项目本身的jar包不受文件写入的影响。

5.4 跨域问题在高并发下表现不一致

前端Vue项目单独跑在8081端口，后端跑在8080端口，联调时大概率会遇到跨域。我一开始直接在后端加了个@CrossOrigin注解，但发现部分请求还是会报跨域错误，原因是没有处理OPTIONS预检请求。解决方案是配置一个全局CorsFilter，明确允许来源、允许Header和请求方法，这样前端不需要额外处理跨域。这一步在开发阶段解决掉，部署到服务器时省心太多。

5.5 一个容易被忽视的事务回滚问题

创建订单、扣减库存、生成支付记录，这三个操作看起来应该在一个事务里，但如果方法在同一个类内部直接调用，且通过this调用，事务注解会失效。这是Spring AOP的经典陷阱——事务是通过代理对象生效的，内部调用走的是this本身，不是代理，@Transactional就不会被切面拦截。

我当时写了一个OrderServiceImpl，里面有个createOrder方法调用了同类里的deductStock，而deductStock加了@Transactional，结果库存扣了一半，订单创建失败回滚了，库存却保留住了。排查了很久才发现是事务失效的问题。解决方式是：要么把事务注解加在入口方法上，要么通过@Autowired注入自己的代理对象（或用AopContext.currentProxy()）。

6. 部署上线与个人实操体会

毕设做到最后，代码写得再漂亮，最终要能跑起来给别人看。部署环节往往是很多同学最虚的部分。我的经验是：打包部署不用搞得很复杂，但要走通全流程，保证在任何一台机器上都能一键跑起来。

6.1 打包与部署步骤

我用的是前后端分离但共用一个Spring Boot服务的方式。Vue前端构建后生成的dist目录，直接复制到后端的static目录下，由Spring Boot统一托管静态资源。这样部署时就只有一个jar包，不需要额外装Nginx、不需要解决前端后端的跨域问题、不需要管理两个服务的启停。这个方案在毕设这样的小型项目里非常实用，资源配置简单还不易出错。

打包命令：

mvn clean package -DskipTests

启动命令：

java -jar hanfu-rental-1.0.0.jar

为了部署方便，我把数据库连接信息、上传路径等配置外置到application.yml里，部署时根据环境修改即可。数据库我打包了一份初始化SQL脚本，在项目的docs目录下放着，新环境直接执行脚本就能初始化表结构和基础数据。

6.2 关于“源码”的一点个人看法

现在网上各种毕业设计源码资源非常多，但以我自己的实际体会来看，拿到一份源码跟真正吃透这套系统之间还有很长的距离。源码是别人思考的结果，如果只是跑起来改个标题就交上去，答辩时老师问几个业务细节就会露馅。好的做法是拿源码当参考，把核心模块的代码逐行看明白，然后自己动手重写关键部分——订单状态流转、库存扣减、押金结算这几个核心链路一定要自己敲一遍。只有亲手踩过那些坑，才能在答辩时有底气说出“这个系统的每个核心逻辑我都清楚”。

以这套汉服租赁系统来说，里面最值得花时间理解的就是状态机和库存设计。如果你能不看代码，独立在白板上画出完整的状态流转图、说明每个流转发生的条件和触发的业务动作，那这个毕设你就真的吃透了。这比把代码背下来有用得多。

6.3 可扩展的方向与最后建议

这套系统如果后续想继续演进，有几个明确的方向。一是增加真实的在线支付对接，把模拟支付替换成微信或支付宝的沙箱环境，订单回调的可靠性会带来一批新的技术挑战，对提升系统完整性很有帮助。二是引入消息队列来做订单超时通知、归还提醒等异步任务，用定时任务勉强能跑，但离生产环境还有距离。三是增加会员体系，对高频租赁用户提供积分和折扣，这会让整个业务模型更加完整。

最后分享一条个人体会：做毕设不要贪功能多，要把一条主线做到闭环。汉服租赁的减库存逻辑，订单状态流转，押金和逾期费用的计算，这三个核心点只要做扎实了，整个项目就是一套有说服力的作品。能讲清楚“为什么这么设计”比“实现了多少个接口”重要得多。祝每一台编译顺利，每一次部署一次通过。