企业官网建设流程全解析

每年到了毕业设计选题季，总有人问我Java Web方向有什么好做的题目。问得多了，我慢慢发现一个规律：很多同学不是不会写代码，而是不会选题，要么选个纯管理系统的CRUD，答辩时没亮点；要么选个算法类题目，工作量全在论文里，代码实现跟不上。如果你现在也在为选题发愁，我建议你认真看看“基于Spring Boot的汉服租赁管理系统”这个方向。

为什么推荐这个题？首先，汉服租赁这个业务场景本身就比普通的图书管理、班级管理有意思——它有完整的用户端和管理员端交互，有商品展示、在线下单、租金计算、押金管理、订单状态流转、归还验收这一整条业务链，复杂度恰到好处，既不是毫无难度的增删改查，也不会难到做不完。其次，Spring Boot是目前企业级Java开发的主流框架，做这个题等于把“前后端交互、数据库设计、状态机设计、并发控制”全部练了一遍，无论将来找工作还是继续读研，这些能力都用得上。就我接触过的案例来看，认真做完这个项目并吃透核心逻辑的同学，在答辩时普遍比那些做“XX管理系统”的更有底气，因为每个模块都能讲出设计理由。

这篇文章我会从需求拆解、技术选型、数据库设计、核心功能实现、关键难点攻克、常见问题排查到论文撰写技巧，完整复盘这个项目的做法。不管你Java基础怎么样，按这条路线走下来，都能把这个项目吃透，而不是停留在“跑通就完事”的层面。

1. 需求拆解：汉服租赁业务到底在管什么

很多同学拿到题目就开始建表写代码，这是大忌。我见过太多人做了三个月，最后被导师问“你这个业务逻辑和现实中租汉服有什么区别”就卡壳了。做系统之前，第一件事是把业务场景彻底搞清楚。

1.1 传统汉服租赁的业务痛点

汉服租赁和普通商品买卖有本质区别。你去线下汉服体验店租一套衣服，流程通常是：先到店看款式，确定喜欢的衣服，然后告诉店家你要租哪天、穿几天，店家要翻纸质登记本确认那几天有没有人预定，有档期就收押金和租金，给你开一张单据，等你归还时再验货退押金。

这个流程最大的问题有三个。第一是档期冲突：同一套汉服如果被两个客户在重叠日期预定了，人工登记很容易漏记，到了取衣那天才发现撞车。第二是押金管理混乱：押金收了现金还是转账、退没退、退了多少钱，全靠脑子记，客户一句“我当时交了两千”就能吵半天。第三是状态无法追踪：衣服是在库、已预定、出租中还是已归还待清洗，没有一个实时视图，店长只能跑到仓库一件件核对。

我做这个项目时，专门去和开汉服店的朋友聊过这些痛点，也翻过他们那本翻得破破烂烂的登记簿。把这些真实问题转化成系统需求，答辩时讲出来，比空谈“传统人工管理效率低下”要有说服力得多。

1.2 从业务痛点提炼系统功能模块

基于上面的痛点，我梳理出系统必须解决的几个核心问题：

用户端需要什么

• 浏览汉服商品，查看款式、尺码、价格、押金、可租状态
• 在选定日期范围内下单租赁，系统自动校验该时段是否可租
• 在线支付租金和押金（毕业设计阶段可用模拟支付）
• 查看个人订单列表、订单状态，处理取消、归还等操作

管理端需要什么

• 汉服商品的增删改查，包括上架、下架、库存管理
• 订单审核、确认取衣、处理归还、验收衣服、办理退款
• 押金管理：收取、扣除（损坏赔偿）、退还
• 用户管理、数据统计（热门款式、营收情况）

系统层面的隐性需求

• 商品在“预订中”和“租赁中”时不能被重复下单——这是并发问题
• 订单状态必须有序流转，不能从“租赁中”直接跳到“已完成”——这是状态机问题
• 超时未取衣、超期未归还需要有处理机制——这是定时任务问题

1.3 角色与核心业务流程梳理

系统涉及三种角色：普通用户、管理员（店长）、系统。有人可能会问为什么不需要“店员”角色，我当初也纠结过，后来一想，小规模汉服店通常就是店主自己管所有事，加一个角色只会增加权限控制的复杂度，对毕业设计来说没有实际收益。把角色控制好，简单清晰也是一个可以写进论文的设计决策。

核心业务流程是两条线：

租赁流程：注册登录 → 浏览商品 → 选择档期 → 提交订单 → 支付押金租金 → 到店取衣 → 开始计租 → 归还衣服 → 验收结算 → 退还押金

订单状态流：待付款 → 已支付（待取衣）→ 租赁中 → 待归还 → 已完成，以及两个异常分支：超时未付款自动取消、逾期未归还需支付违约金

这两条线是整个系统的骨架，后文的数据库设计和代码实现都是围绕它们展开的。

2. 技术选型：为什么是Spring Boot全家桶

确定好需求之后，下一步就是选技术栈。我见过有同学在这个环节纠结很久，一会儿想用Vue做前后端分离，一会儿想用原生Servlet，到最后把自己搞得很累。我的建议是：毕业设计的技术选型，核心原则是“主流、够用、能说清”。

2.1 Spring Boot的核心优势

先明确一个大前提：如果你不是专门做前后端分离方向的课题，选Spring Boot + 服务端渲染模板是你最高效的路线。Spring Boot相比之前的Spring MVC，最大的改变在于“约定优于配置”——内嵌Tomcat，不用再单独部署；自动配置Starter，几行配置就能连上数据库；自带Actuator监控，答辩时可以展示系统运行状态。这些都是可以写进论文的选型理由。

具体到版本选择，我用的是Spring Boot 2.7.x。为什么不推荐3.x？因为3.x基于Jakarta EE规范，很多网上教程和兼容组件还没完全跟上，对新手来说遇到问题不好查。2.7.x是目前教材、网课、企业存量项目里最常见的选择，遇到任何报错，搜索引擎都能帮你找到解决方案。这不是保守，是务实。

2.2 持久层框架：MyBatis-Plus还是JPA

这是很多同学纠结的地方。我两个都用过，给毕业设计用的话，我会选MyBatis-Plus。原因很简单：JPA虽然写起来爽，但遇到复杂查询时，方法名解析和JPQL会让你抓狂；MyBatis-Plus在MyBatis基础上封装了通用Mapper和分页插件，单表操作一行代码都不用写，多表关联用它的Wrapper条件构造器也能搞定，学习曲线比JPA平滑得多。

有一说一，这里有个取舍逻辑：MyBatis-Plus的Service层封装得太好，容易让你在答辩时被问到“你的业务逻辑到底写在哪”而答不上来。所以我在代码里会刻意把订单状态的流转校验写在Service层，而不是依赖框架的自动填充，这样既享受了框架的效率，又保留了可讲的核心业务代码。

2.3 前端方案：Thymeleaf + Bootstrap实战经验

前端的选型，我强烈建议用Thymeleaf模板引擎配合Bootstrap框架，而不是再引入Vue搞前后端分离。原因有两条：第一，前后端分离意味着你要同时维护两套工程、处理跨域、写接口文档，工作量直接翻倍；第二，毕业设计答辩时，评委更关注“你怎么实现业务功能”，而不是“你用没用Vue3”。

Thymeleaf + Bootstrap的好处很直接：Thymeleaf天然支持在HTML中渲染后端数据，Spring Boot官方Starter一站式集成；Bootstrap自带现成的组件和栅格布局，不用自己写CSS也能做出能看的界面。我实际做下来，整个前端页面包括用户端和管理端一共十来个页面，两周左右就能搞定，而且界面风格统一，不需要折腾前端构建工具。

2.4 完整技术栈清单

我最终用的技术栈是这样的：

这里重点说一下权限控制。很多教程用Spring Security，但它的配置复杂度对新手很不友好，光是理解过滤器链就要花不少时间。我用的是Sa-Token，一个国产轻量级权限框架，登录只需一行代码，鉴权只需要一个注解，非常适合毕业设计的体量。如果导师指定必须用Spring Security，你再换也不迟，核心业务代码不受影响。这个取舍体现了你“根据项目规模选择合适工具”的能力，答辩时反而是加分项。

3. 数据库设计：一张好的表结构等于成功一半

如果说Spring Boot让编码变简单了，那数据库设计就是整个项目里最不能偷懒的部分。表结构设计不合理，后面写业务代码时你会层出不穷地打补丁。这一节我拆开细说。

3.1 表结构总览与设计思路

我的项目一共设计了七张核心表，我把它们分为三类：

用户相关

• user（用户表）：存用户名、密码、手机号、角色类型（用户/管理员）、状态

商品相关

• hanfu_info（汉服信息表）：存名称、分类、图片、款式描述、日租金、押金、库存、状态

订单与租赁相关

• rent_order（租赁订单主表）：存订单编号、用户ID、订单状态、总金额、下单时间
• rent_order_item（订单明细表）：存订单中包含的每套汉服、租赁开始日期、结束日期、小计金额
• payment_record（支付记录表）：存每次支付/退款流水，标注类型是租金还是押金

业务辅助相关

• damage_record（损坏赔偿记录表）：存归还验收时发现的损坏信息、赔偿金额、处理状态
• dictionary（字典表）：存租赁分类、商品尺码等可扩展数据

3.2 核心表字段详解及其设计理由

上面七张表里，最核心的是租订单表和汉服信息表，我展开讲讲关键字段的设计逻辑。

汉服信息表（hanfu_info）核心字段：

• id：主键，使用MyBatis-Plus的雪花算法生成，不要用数据库自增。为什么？因为订单和商品表将来都可能做分库分表，数据库自增在分布式环境下会冲突。雪花ID虽然长一点，但全局唯一、趋势递增，是当前的主流做法。这个细节写进论文里，显得你考虑过扩展性。

• status（状态字段）：我用整数类型，1上架、0下架、2租赁中。为什么不直接用字符串“上架/下架”？因为整数在条件查询时更快，而且可以定义常量来保证代码可读性。这里注意，如果一件汉服处于“租赁中”状态，管理员不能直接将它下架，前台也不能对它的档期再做预订——这就是状态对业务的约束。

• daily_price和deposit：几乎没有例外，这两个字段都用decimal(10,2)而不是float或double。很多新手在这里踩坑：浮点数在计算机中无法精确表示，比如0.1实际上是个无限循环小数，存到数据库里会出现19.99和20.01这种诡异差异。金额字段一律用decimal，这是一个职业道德问题。

租赁订单表（rent_order）核心字段：

• order_no：订单编号，格式是日期+随机数，比如“202505201400123”。为什么要单独设计这个字段而不用自增ID当订单号？因为主键ID会暴露系统的订单量，这是商业敏感性；同时订单号需要具备唯一性和可读性，用户报出订单号，客服一眼就能看出是哪天下单的。

• status：订单状态，0待付款、1已支付待取衣、2租赁中、3待归还、4已完成、5已取消、6已逾期。我用一个int字段配合常量类来管理状态，而不是用Java枚举直接映射到数据库。原因很简单：数据库里存数字可以避免枚举类名重构时带来的数据不一致问题，同时查SQL时也直观。

• total_amount和deposit_amount：总金额和押金分开存。为什么要分开？因为押金在租赁结束后要退还，而租金是店里的收入，两者的资金流向完全不同。如果合并成一个字段，退款逻辑会非常混乱。

3.3 多表关联的设计细节

接下来是订单明细表的设计。这个表非常容易被人忽略，但它是解决“一套订单租多套汉服”的关键。

设计一个rent_order_item表，包含：id、order_id、hanfu_id、rent_start_date、rent_end_date、item_amount这几个字段。为什么不能直接在主表里存一个“商品ID加开始日期加结束日期”？一个订单可能同时包含两套不同的汉服，也可能同一套汉服租两件，一张表存不下，强行设计会导致大量冗余。拆成明细表后用订单ID关联，查询时一对多映射，非常清晰。

这里有个月对数提醒：同一订单里，不同汉服的租赁日期可以不同吗？现实中往往可以——比如客户A想5月1日到3日租甲款，5月2日到4日租乙款，这在业务上是合理的。所以明细表里每条明细都有自己的租赁日期，租金也按各自的时长计算，最后汇总到订单总额。这是这个项目里比较有价值的一个设计点，答辩时可以主动提。

3.4 冗余字段与索引的取舍

作为一个有经验的导师，我特别想交代索引设计。数据库设计不只是建表存数据，更要为高频查询建索引。

订单明细表里，(hanfu_id, rent_start_date, rent_end_date)这组字段要建联合索引。为什么？因为“查某件汉服某段时间是否可租”是系统最高频的查询，有联合索引可以让这个查询走索引加速。同理，订单表里的user_id要建普通索引，因为用户查自己的订单列表也是高频操作。

冗余字段方面，我在订单主表里存了一个user_name冗余字段。正常设计是存user_id，查询时联表拿用户名。但在订单列表展示时，几乎每一次都要显示用户名，如果每次都JOIN一次用户表，查询代价不小。直接在订单表冗余存一个user_name的快照，展示时就不用联表了。这里有取舍逻辑：如果用户改了昵称，历史订单显示的还是下单时的旧昵称，这在业务上其实更合理——订单上的名字代表下单那一刻的身份。这种了解，正是设计经验和不设计经验的差别。

4. 核心功能实现：从登录到归还的完整链路

前面把骨架搭好了，现在开始填充血肉。我把系统按业务链路拆成几个核心模块，挑最有代表性的实现细节讲。

4.1 登录认证与权限控制

登录用Sa-Token实现，整体逻辑不算复杂：用户提交用户名密码，后端校验通过后调用StpUtil.login(userId)，Sa-Token会在服务端生成一个token并存入缓存，返回给前端。前端后续请求都在header里带上这个token，Sa-Token的拦截器会自动校验。

权限控制我用注解来解决。在管理员相关的Controller方法上直接标注@SaCheckLogin和@SaCheckRole("admin")，比如：

@SaCheckRole("admin") @PostMapping("/admin/hanfu/add") public Result addHanfu(@RequestBody HanfuInfo hanfu) { // 新增汉服逻辑 }

这里有个我踩过的坑：Sa-Token的@SaCheckRole注解默认从token里获取角色信息，确保登录时把角色类型存进了token的session里。我在第一次开发时因为漏了这一步，导致所有标注了权限注解的接口全部403，排查了一个多小时才找到原因。后来我的习惯是，登录成功后统一调用StpUtil.getSession().set("role", user.getRole())，然后把这段逻辑封装成一个方法，避免遗漏。

密码存储方面，不要用MD5，用BCrypt加密。MD5虽然快，但彩虹表攻击可以秒破弱密码。BCrypt内置盐值，同一个密码每次加密结果都不同，安全性高一个量级。Spring Boot的spring-security-crypto包直接提供BCryptPasswordEncoder，不用额外引依赖。

4.2 商品展示与多条件筛选

用户端首页展示汉服列表，支持按分类、价格区间、状态筛选。这个功能本身不复杂，但有一个细节值得注意——列表默认只展示状态为上架（status=1）的商品，而且每件商品要展示一个“当前是否可租”的标识。

这个“可租标识”不能直接查商品表，因为它依赖订单明细表。假设现在是5月20日，客户想看6月1日到3日哪天能租，你需要查询rent_order_item表，判断该商品在6月1日至3日这个区间内有没有未完成或未取消的订单记录。MyBatis-Plus的条件构造器这样写：

LambdaQueryWrapper<RentOrderItem> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(RentOrderItem::getHanfuId, hanfuId) .lt(RentOrderItem::getRentStartDate, endDate) .gt(RentOrderItem::getRentEndDate, startDate) .eq(RentOrderItem::getStatus, 1); // 1表示有效占用

这段查询的思路是：两条租赁记录发生冲突，条件是“新记录的开始日期早于旧记录的结束日期，且新记录的结束日期晚于旧记录的开始日期”，即区间重叠。反过来讲，只要不存在区间重叠的未完成记录，该商品在目标时间段就是可租的。这个查询逻辑是整个系统的核心之一，理解了它，你就理解了租赁类系统的精髓。

4.3 订单提交与租期校验的完整流程

这是整个项目里逻辑最复杂的部分，值得单独拿出来写。我把下单流程拆成六个步骤：

第一步：校验登录状态。用户未登录直接下单是不行的，后端Controller统一从token中获取用户ID，取不到就抛出未登录异常。

第二步：校验商品状态。查询商品是否上架，如果已下架或库存为0，直接返回错误。

第三步：校验租期。这里有两个维度要查。第一，前端传过来的startDate和endDate不能倒置，即开始日期必须早于结束日期；第二，该商品在目标日期区间内是否已有有效订单占用。第三步实际调用上一小节写的区间冲突查询逻辑。

第四步：计算租金。租金等于日租金乘以租赁天数。租赁天数的计算要搞清楚：用户选5月1日到5月3日，是按3天算还是2天算？现实中取衣当天就算一天，归还当天不算。所以天数 = endDate - startDate + 1。我一开始按自然天数算，结果用户投诉计价不对，后来改为+1才符合行业习惯。这个细节虽然小，但体现了你对业务的理解。

第五步：计算押金。押金等于商品押金乘以租赁数量。

第六步：生成订单。先生成主表记录，状态设为待付款；再循环生成明细记录，每套汉服一条，状态同样为待付款。两个表的数据必须在一个事务里完成，用@Transactional注解。

下单是典型的高并发场景下的数据一致性问题。我在下单第三步做区间查询时，发现一个隐患：如果两个用户在同一个毫秒都查询到“该商品可租”，然后同时下单，数据库里就会产生两条冲突的订单。解决方案有几种：悲观锁、乐观锁、数据库唯一约束。我采用的是数据库事务配合行级锁的思路：在查询区间冲突时，先查询该汉服的最新订单记录并开启事务，利用数据库的行锁机制将冲突检测和订单插入串行化。虽然牺牲了一点并发性能，但保证了数据的正确性。这个设计在答辩时是真能讲到点上的，你甚至可以画一张时序图，把自己发现问题到解决问题的过程展示出来。

4.4 支付流程：毕业设计里的模拟支付方案

真实接入支付宝或微信支付，你需要企业资质和商户号，个人开发者根本走不通。毕业设计阶段我推荐用模拟支付。做法是在支付页面展示订单金额，用户点击“确认支付”，后端调用一个mockPay方法，直接生成支付流水记录，并把订单状态从待付款改为已支付。这个方案的好处是：开发的业务逻辑和真实支付完全一致——创建支付流水、记录支付时间、更新订单状态——只是没有真实调用第三方接口。你可以在论文里说明：本项目出于演示目的采用模拟支付，若需上线可替换为第三方支付SDK。答辩老师都懂，也不会在这上面刁难你。

支付记录表设计上，我把租金支付和押金支付分开记录，通过payment_type字段区分（1租金、2押金）。为什么分开？因为它们的生命周期不同：租金是商家的收入，直接入账；押金是客户的保证金，要等到归还验收通过后才退还。混在一个流水里，后面退押金时账都算不清。

4.5 归还验收与损坏赔偿

归还环节是汉服租赁区别于普通商品销售的标志性功能，也是答辩时的差异化亮点。用户点击“申请归还”后，管理员查看订单，进入归还验收页面，核对衣服是否完好。

如果完好，管理员点击“确认归还”，系统自动将押金退还（模拟），订单状态变为已完成。如果存在损坏，管理员填写损坏描述和赔偿金额，比如“袖口污渍，赔偿80元”，系统会生成一条damage_record记录，同时从押金中扣除赔偿金额，剩余部分退还，订单状态同样变为已完成。

损坏赔偿这个流程业务上有讲究：赔偿金额不能超过押金总额，这是底线。所以后端要校验赔偿金额小于等于押金，否则提示管理员修改。这个约束逻辑放后端，不能只靠前端校验，因为接口可以被绕过。我在代码里加了一段校验：

if (damageAmount > order.getDepositAmount()) { throw new BusinessException("赔偿金额不能大于押金总额"); }

就是这一行校验，答辩时评委问“如果用户把衣服弄丢了怎么办”，你就回答“超过押金部分走线下协商”，既专业又严谨。

5. 关键难点攻克与性能优化

这个项目真正拉开差距的地方在难点处理上。我把自己实际开发中遇到的三个难点和对应的解决方案整理出来，这三个点如果你能在答辩时清晰讲出来，绝对让评委眼前一亮。

5.1 档期冲突检测：区间重叠查询的边界处理

前面说了区间重叠的核心查询，但边界情况还值得深挖。比如：现有订单是5月1日到5月3日，新用户要租5月3日到5月5日，这个是否冲突？

业务上，5月3日当天那位旧客户是否已经归还？如果还没归还，那当天就不能给新客户用。所以判断时应视为冲突。用区间重叠查询判断，插入条件用lt和gt而不是le和ge，就能正确处理边界。这个看似微小的选择，恰恰是业务正确性的关键。我之前用ge/le测试时，发现边界日会出现误判，后来才调整成lt/gt。建议你写完后用“同一天归还再出租”的场景专门测试一下。

5.2 订单状态机：防止业务逻辑混乱的设计模式

订单状态必须有序流转，不能随意跳转。我在代码里设计了一个状态机校验器：

public void checkTransition(int currentStatus, int targetStatus) { switch (currentStatus) { case 0: // 待付款 if (targetStatus != 1 && targetStatus != 5) { throw new BusinessException("非法状态流转"); } break; case 1: // 已支付待取衣 if (targetStatus != 2 && targetStatus != 5) { throw new BusinessException("非法状态流转"); } break; // 其他状态同理 } }

在每次订单状态变更的Service方法里先调用这个校验器，杜绝了“已取消的订单突然变成租赁中”这种逻辑漏洞。有的同学会把状态判断散落在各个Controller里，导致排查状态问题时像大海捞针。把状态流转集中到一个类里管理，这个习惯称为“状态机模式”，写进论文里是一个知识性的亮点。

5.3 超时自动取消与逾期处理：定时任务的实战用法

用户下单后不在30分钟内付款（我设定30分钟，你可以自定），订单应自动取消；租赁到期后没有归还，订单应标记为逾期。这类批量处理用Spring Schedule定时任务最合适。

我的实现是：在配置类上标注@EnableScheduling，然后写一个定时任务类，每5分钟执行一次扫描：

@Component @Slf4j public class OrderTimeoutTask { @Autowired private RentOrderService rentOrderService; @Scheduled(cron = "0 */5 * * * ?") public void processTimeoutOrders() { // 查询所有待付款且下单时间早于当前时间30分钟的订单 // 批量将其状态置为已取消，同时释放占用档期 } }

写定时任务时有个小坑：如果直接遍历查询结果并逐条更新状态，数据量大时会很慢，而且中途出错会影响后续订单。我建议用分批处理：每批100条，处理完一批再查下一批。这样即使某次执行出问题，也不会影响大范围数据。

还要注意，超时取消订单后必须释放该订单占用的档期。如果只是把订单状态改成已取消，而订单明细还在占用档期，那这套汉服在那些日期就永远“不可租”了。这个bug我真实遇到过，排查了很久才发现是订单明细状态没有同步更新。解决办法是在取消订单的方法里，同时把该订单所有明细的状态也改为已取消。

5.4 缓存优化：商品列表如何扛住高并发

如果商品列表页每次请求都去数据库查询，并发高时数据库压力会比较大。我在商品列表接口上加了本地缓存：用Spring Cache的@Cacheable注解，把“商品列表”这个查询结果缓存10分钟。用户在10分钟内的重复请求直接命中缓存，数据库压力大大降低。当管理员修改商品信息时，调用@CacheEvict注解清除缓存，保证数据一致性。

Spring Cache配置本身很简单，但这里有个原理性知识点：为什么不能缓存太久？因为汉服的可租状态依赖实时订单数据，缓存时间过长会导致用户看到的状态不准确。所以商品基本信息可以缓存10分钟，但“某商品某日期是否可租”这个动态状态必须走实时查询，不能缓存。这种“静态数据缓存、动态数据实时”的混合策略，是生产环境里的常见做法，足够体现你考虑过性能问题。

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

我知道你迟早会在开发中遇到各种问题，把我在实际项目里踩过的最典型的几个坑拿出来说，省得你再走弯路。

6.1 数据库时间字段相关的问题

问题：使用LocalDateTime类型的字段保存租赁日期，查出来的时间和数据库存的时间差了8个小时。

原因：MySQL连接时区参数没配好，JDBC默认使用服务器本地时区。如果你的服务器是UTC时区，而你的本地是中国时区，就会差8小时。

解决：在application.yml的数据库连接URL上加上serverTimezone=Asia/Shanghai：

jdbc:mysql://localhost:3306/hanfu?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

这个参数不加，订单里的日期就会错位，看起来是当天租的，库里存的却是前一天。这种问题在答辩演示现场出现会很尴尬，建议你在项目一建立时就配好。

6.2 文件上传路径的绝对与相对之谜

问题：汉服图片上传后，在本地开发环境能正常显示，部署到服务器后图片就404了。

原因：本地用相对路径存储文件，比如/upload/images，这个路径是相对于项目的运行目录。本地开发时运行目录就是项目目录，所以能找到；部署后运行目录变成了Tomcat的bin目录，相对路径就不对了。

解决：文件上传要存储到绝对路径，比如/home/ubuntu/hanfu/upload，然后把该路径配置为Spring Boot的静态资源映射地址：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:/home/ubuntu/hanfu/upload/"); } }

也就是说，访问/upload/xxx.jpg时，会映射到本机的/home/ubuntu/hanfu/upload/xxx.jpg文件。这是很多同学忽略的细节，等部署时才发现问题就耽误工期了。

6.3 状态流转时出现的事务失效问题

问题：调用订单取消方法，数据库里主表状态改了，明细表状态没改。

原因：我没有在Service方法上标注@Transactional，导致主表更新和明细表更新不在同一个事务里。主表更新成功后，明细表更新抛异常，事务没有回滚。

解决：在需要保证多步更新原子性的方法上统一标注@Transactional。注意一个细节：@Transactional只对由Spring容器管理的public方法生效。在同一类内部通过this调用时，事务会失效。我举例：OrderService里有个cancelOrder方法，里面调用了另一个方法updateOrderStatus，而你只在updateOrderStatus上加@Transactional，这样事务是不会生效的。解决办法是把updateOrderStatus放到另一个Service类中，或者保证整个cancelOrder就一个事务。

这个方法上的细微差别，面试时也常被问到。理解它，比单纯写出一堆能跑的代码更有价值。

6.4 前后端联调时请求的Content-Type问题

问题：前端通过AJAX提交JSON数据，后端用@RequestBody接收，但报“Required request body is missing”。

原因：前端发送请求时没有设置Content-Type为application/json，导致后端无法解析JSON体。

解决：前端代码里显式设置：

$.ajax({ url: "/api/order/submit", type: "POST", contentType: "application/json", data: JSON.stringify(orderData), success: function(res) { ... } });

这个坑在联调阶段很常见，尤其新手容易忽略。如果用了现在主流的axios框架也要注意，axios发axios.post时传对象需要JSON.stringify，否则同为表单格式导致后端解析不了。

7. 文档撰写与论文写作的实战经验

毕业设计如果只写代码不写文档，等于白做。我见过太多代码能力还行、但论文写成一团浆糊的同学。这里单独讲讲文档和论文的技巧。

7.1 系统需求分析怎么写才有说服力

需求分析章节不能只是罗列功能，要从业务场景出发，把用户在什么样的场景下会产生什么需求讲清楚。比如：用户访问系统首页，需要快速找到喜欢的汉服，所以系统提供分类筛选和搜索功能；用户选定汉服后需要确认档期是否可租，所以系统提供租期校验；店长需要掌握所有订单状态以便安排取衣和提醒归还，所以系统提供订单管理列表。

这里有个写作框架：每写一个功能需求，都采用“背景 → 角色 → 操作 → 预期结果”的结构展开。比如：

背景：用户浏览到心仪的汉服后，需要确认所选日期是否有档期。 角色：普通用户。 操作：在商品详情页选择开始日期和结束日期，点击“立即租赁”。 预期结果：系统校验所选时段是否可租，如可租则进入订单确认页，否则提示冲突日期并推荐可租日期。

这种写法逻辑清晰、说服力强，导师看了就觉得你做过调研，而不是网上抄的。

7.2 数据库设计章节的展示技巧

数据库部分要画两张图：ER图和表结构图。表结构用表格形式列出字段名、类型、注释、是否主键/外键，清晰直观。同时，每个表定义下附一段设计说明，用来解释关键字段。例如：

rent_order表：本表存储租赁订单主信息。status字段取值范围0-6，分别对应待付款、已支付待取衣、租赁中、待归还、已完成、已取消、已逾期。状态流转规则：待付款可转为已支付或已取消；已支付可转为租赁中或已取消；租赁中只能转为待归还等。为保证状态一致性和可追溯性，订单状态的所有变更均由后端Service层完成，并经过统一状态机校验。

这段文字让评委看到的不只是表结构，而是你对业务闭环的思考。

7.3 核心功能时序图怎么画不费劲

论文里一定要有核心功能时序图。用UML工具画确实费时间，我的经验是用绘图工具手绘简化版。重点是展示对象之间的交互顺序，比如用户点击下单之后，Controller、Service、Mapper、数据库之间依次发生了什么。画图时别追求过于复杂的语法，把关键调用关系和返回结果标注清楚就够了。答辩时看着这份时序图，你就能把整个下单流程讲得头头是道。

7.4 测试用例与测试报告的写法

这一章很多同学随便编几个用例糊弄过去，其实不需要写得面面俱到，抓住几个核心场景就好：用户注册登录流程、商品搜索与筛选、下单时档期冲突校验、并发下单的一致性、订单状态流转、归还验收与押金结算。每个用例写清楚输入、前置条件、执行步骤、预期结果、实际结果。尤其要把“档期冲突时系统拒绝下单”和“催款到期后自动取消订单”这类你特别设计过的用例写进去，这比写100个DELETE一条记录的用例有价值得多。

7.5 答辩前要准备的五个问题

根据我帮朋友模拟答辩的经验，评委最可能问下面几类问题，提前准备好稳很多：

• 为什么选Spring Boot做后端，而不是SSH或原生Servlet？
• 如果两个用户同时下单同一件汉服同一档期，系统怎么保证不冲突？
• 订单状态有哪些，流转规则是什么？
• 如果用户不归还或者逾期了怎么办？
• 押金退还的具体逻辑是什么？

这五个问题恰好就是我在前面章节详细展开的内容。吃透这篇文等于直接背好答辩答案。

8. 补充价值：从毕业设计到真实项目的能力迁移

做完这个项目，你其实不只是完成了一个毕业设计，你的能力已经发生了几个层面的变化。第一层是业务层面：你理解了租赁类业务的完整生命周期，而这个模型可以平移到共享单车、图书借阅、机房设备管理等等系统。第二层是技术层面：你掌握了状态机设计、并发控制、定时任务、事务管理等后端开发的核心技能，这些在任何Java后端岗位面试中都是高频考点。第三层是工程层面：你第一次走完了“需求分析 → 概要设计 → 详细设计 → 编码 → 测试 → 文档”的完整软件工程流程，而这个流程在未来的工作里会陪你走很久。

我个人经验上，做完这个项目后，我给学生们的建议都是：不要急着把源码到处发，保持项目的好奇心，试着往里面加功能。比如加一个“预约试穿”功能：用户在线选择到店试穿时间，管理员安排档期；或者加一个“汉服收藏夹”功能：用户可以收藏喜欢的款式，便于下次快速下单；再或者加一个“营收统计面板”：用图表展示每个月的营收趋势和热门款式排行。这些功能能锻炼你独立设计表、写接口、做前端的能力，比开新项目更有价值。

最后分享一个小技巧：给项目写一篇完整的上线部署文档，包括环境要求、初始化数据、启动步骤、注意事项。你现在能为一个系统写清楚部署文档，说明你真正掌握了它。等工作后参加实习或者团队开发，这也会是让你立刻和其他人拉开差距的能力之一。做这个项目时我一直提醒自己：写系统不是考试的最终目的，真正理解它、能把它讲透，才是我通过实习和面试时最重要的资本。