企业官网建设流程全解析

每年开题季，总有人拿着半截标题来找我：“基于的汉服服装租赁系统，源码和开题一起要。”标题里那个“基于”后面空着的位置，本该填技术栈名字，结果要么是复制时漏了，要么是还没想好写什么。我见过太多这样的题目，最后做出来的是一个套了汉服皮肤的普通商品商城——商品详情页、加入购物车、下单支付，跑是能跑，但老师一问“两个人同时租同一件衣服怎么办”，当场卡住。汉服租赁系统和电商系统最大的差别不在于界面长什么样，而在于它的核心资源是“某一件具体的衣服在某一段时间内能不能被租走”。这篇就围绕这个差异，把从需求梳理、技术选型、表结构设计到几个真正会卡住人的代码点，以及开题报告怎么写不被反复打回，一次性讲清楚。适合正在做毕设或课程设计、手上有这么个题目但不知道从哪下手的同学，也适合想拿它当练手项目的人。

1. 汉服租赁的“库存”和普通电商的库存根本不是一个概念

1.1 卖出去就没了，租出去还得回来

普通电商的库存是一个递减的整数：100 件，卖一件变 99 件，卖完显示无货。这个模型简单到几乎不需要设计。汉服租赁完全不是这个逻辑，一件衣服租出去，它并不会从系统里消失，而是进入“占用中”状态，等它归还、检查、清洗、晾干之后，又重新回到可租池子里。也就是说，库存不是一个数字，而是一张时间表。

我在帮人看这类项目的时候，第一眼就去找它的表结构里有没有“起租日”和“归还日”这两个字段挂在订单明细上。如果没有，那基本可以判定它做的是电商而不是租赁。因为只要没有时间区间，系统就无法回答“这件衣服下周三到周五能不能租”这种最基本的问题，而这恰恰是用户最关心的。

把这个差异想明白，后面很多设计就顺了：商品详情页上不该只写“有货”，而应该给出一个日历，把已经被占用的日期灰掉；下单时不该扣库存，而应该去检查区间是否重叠；取消订单时不该加库存，而应该释放那段区间。

1.2 款式、实物、尺码把 SKU 数量撑爆了

汉服这个品类有个特点，它不是标准化商品。同一款“明制立领长衫”，可能有 S、M、L、XL 四个尺码，每个尺码下面有不同的颜色，还分单件和整套（上衣加马面裙），整套又可能带不带披帛、发簪、腰佩这些配饰。如果按电商的做法一股脑塞进 SKU 表，字段会迅速膨胀到没法维护。

更贴近实际的做法是拆成两层：款式层（描述这是什么衣服，有什么形制、什么朝代风格、什么面料、租一天多少钱、押金多少、适合什么身高三围）和实物层（具体是哪一件，有唯一编号，有自己的状态、清洗次数、磨损记录）。用户在前端看的是款式，下单时系统分派的是实物。

这么拆的好处很直接：某一件衣服送修了，只需要把那一件的状态改掉，款式页依然可以展示，只是可租数量少一件；某款衣服有六件实物，档期排得开，用户几乎随时能租到。用生活化的类比，款式像是酒店 App 上的“大床房”，实物像是具体的“806 房间”，你订的是房型，住的是房间。

1.3 档期表才是这个系统真正的心脏

我在做需求梳理时，会把“可租区间计算”单独拎出来当成一个核心能力，而不是散落在下单逻辑里的几行判断。原因是它会被很多地方调用：详情页的日历要高亮空闲日，搜索列表要过滤掉指定日期不可租的款式，下单要二次校验，后台要能人工锁定某段时间（比如送去修补），归还之后还要留出一段缓冲期不能立刻再租。

这里有个很容易被忽略的点：归还日和下一次起租日之间必须留缓冲。衣服回来要检查有没有污渍、掉配件、开线，然后清洗晾晒，快的也要一两天。如果系统里 A 用户 5 号还，B 用户 5 号就租走，实际运营中一定出问题。我的建议是在配置表里放一个buffer_days参数，默认 1 到 2 天，计算可租区间时自动把归还日往后推这么多天。

2. 技术栈落地：三套方案摆在一起看，再决定写哪个

2.1 Java、Python、PHP 三条路各自适合什么人

标题里“基于”后面填什么，直接决定了后面三个月的痛苦程度。我把常见的三种组合摆出来对比，你按自己的情况对号入座。

如果没有特别的偏好，我一般推荐方案一。不是因为 Java 更“高级”，而是三个很实际的理由：一是答辩组老师大概率是讲 Java 课出身的，你讲 Spring 的分层、讲 MyBatis 的映射，他能听懂并且能顺着问；二是这类项目的参考资料多，遇到报错基本能搜到；三是简历上写“SpringBoot 前后端分离项目”匹配度更广。

2.2 版本号要写进开题的“开发环境”里

这一点吃过亏的人不少：开题报告里只写了“SpringBoot + MySQL”，没写版本，结果中期检查时换了一台机器，代码跑不起来了。原因是 SpringBoot 3.x 强制要求 JDK17，而很多学校的机房还装着 JDK8；MySQL 8 的驱动类名是com.mysql.cj.jdbc.Driver，和 5.x 的com.mysql.jdbc.Driver也不一样。

我的建议是，在你的开题报告“开发环境”一节里，把版本号写死，并且写清楚理由：

JDK 1.8.0_301 SpringBoot 2.7.18 MyBatis-Plus 3.5.3.1 MySQL 8.0.32 Node.js 18.17.0 Vue 3.3.x Element Plus 2.3.x Maven 3.8.6

为什么 JDK 选 1.8 而不是 17，这个可以在开题里加一句说明：目标运行环境兼容性考虑，且所依赖的第三方库对 1.8 支持更完整。写清楚理由，老师就不会觉得你是随便抄的。

Maven 记得配镜像，不然第一次拉依赖能耗掉一整个下午：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>aliyun</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

2.3 分层目录定下来，后面写代码就不乱了

很多同学的项目写到一半就崩，不是因为技术不会，而是因为结构没定好，业务代码全堆在 Controller 里，一个方法两百行。我在动手写第一行业务代码之前，会先把目录建出来，哪怕里面全是空文件。

src/main/java/com/example/hanfu ├── common // 统一返回体、常量、异常 │ ├── Result.java │ ├── ResultCode.java │ └── BizException.java ├── config // 跨域、拦截器、MyBatis 配置 ├── controller // 只做参数接收和结果返回 ├── service │ └── impl ├── mapper // 接口，复杂 SQL 写在 XML 里 ├── entity // 和表一一对应 ├── dto // 前端传进来的参数对象 ├── vo // 返回给前端的视图对象 └── utils // 日期计算、编号生成

关键是那条规矩：Controller 里不写业务判断，Service 里不写 SQL 字符串。这条守住了，后面无论加多少功能，代码都不会烂。

3. 从表结构开始拆：款式、实物、档期三层建模

3.1 核心表清单与字段说明

我按实际会用到的最小集合列一遍，字段只挑关键的讲，省略掉create_time、update_time、is_deleted这类公共字段。

几个设计上的取舍需要说明。hanfu_item里我放了status字段，取值用整数枚举：0 可租、1 已租出、2 待清洗、3 维修中、4 下架。有人会问，既然档期表已经能判断能不能租，为什么还要 status？因为状态是“当前这一刻”的物理状态，档期是“未来某段”的占用情况，两者互补。一件衣服在维修中，档期表里可能没有占用记录，但它就是不能租。

rental_order_item单独存一份起止日期，看起来和主表重复，但这层冗余是必要的。一个订单可能同时租三件衣服，其中两件档期一致，另一件因为库存紧张只能安排在后半段，主表一个日期字段撑不住这种场景。而且冲突检测的查询会直接打到这张表上，冗余字段能省掉一次 join。

3.2 档期冲突的判定逻辑与索引设计

判断两个时间区间是否重叠，是个经典问题。设已有区间为[s1, e1]，新区间为[s2, e2]，重叠的充要条件是：

s2 <= e1 AND e2 >= s1

注意这里用的是闭区间，因为起租日和归还日当天都算占用。如果业务上允许“当天还、当天再租”，那就得改成半开区间，但前面说过，实际运营里要留清洗缓冲，所以闭区间更贴合。

对应的查询写成这样：

SELECT COUNT(1) FROM rental_order_item roi JOIN rental_order ro ON roi.order_id = ro.id WHERE roi.item_id = #{itemId} AND ro.status IN (1, 2, 3, 4) AND roi.start_date <= #{endDate} AND roi.end_date >= #{startDate};

其中status IN (1,2,3,4)表示待发货、已发货、使用中、待归还这几种占用了实物的状态；已取消和已完成的订单不参与冲突判断。item_lock表里的记录也要用同样的逻辑查一遍，两边任意一边有冲突就拒绝下单。

索引不能只建在item_id上，正确的是联合索引：

ALTER TABLE rental_order_item ADD INDEX idx_item_period (item_id, start_date, end_date);

为什么顺序是这样？因为查询条件里item_id等值匹配，选择性最高，放在最左；两个日期字段做范围比较，跟在后面。如果只建单列索引，MySQL 在数据量上来之后会走全表扫描，几百条记录看不出差别，几千条就能明显感到卡顿。

3.3 订单状态机：一条汉服的完整生命周期

状态设计是这类项目里最容易写成“一锅粥”的地方。我见过用十几个 if-else 判断状态的代码，改一个需求就要动三处。正确做法是把状态和允许的流转列成一张表，写成一个单独的类来管。

这张表我建议直接写在开题报告的功能设计章节里，再配一张状态流转图（用普通绘图工具画，别用代码画图）。它能让老师一眼看出你是真的想过业务，而不是套模板。代码层面，用一个OrderStatusMachine类，内部放一个Map<Integer, Set<Integer>>记录合法流转，每次改状态前先校验，非法流转直接抛业务异常。

4. 真正会卡住人的几个代码点

4.1 租期天数到底怎么算

这是个小问题，但十个项目里有六个算错。常见的错误是用两个Date对象相减除以一天的毫秒数，遇到跨夏令时或者时区设置不一致，结果会差一天。用java.time包能规避大部分问题：

public static long calcRentDays(LocalDate start, LocalDate end) { if (start == null || end == null) { throw new BizException("租期不能为空"); } if (end.isBefore(start)) { throw new BizException("归还日期不能早于起租日期"); } // 起租日和归还日当天都计费，所以 +1 return ChronoUnit.DAYS.between(start, end) + 1; }

那个+1是业务决定的：5 号取件、6 号归还，实际占用两天，按两天计价。如果业务上想改成“按 24 小时计”，那就得存时间戳而不是日期，复杂度会上一个台阶，本科毕设没必要。关键是把你选的规则写进文档和界面提示里，别让用户自己猜。

还有一个坑是租期上限。不限天数的话，用户可以下一单占一年，实物就被锁死。加一行校验：

if (days > 30) { throw new BizException("单次租期不得超过30天，如需长期租赁请联系客服"); }

4.2 押金、超期费、清洗费的账怎么算平

这三笔钱是最容易算糊涂的。我建议在订单表里把金额拆开存，别只存一个总额：item_amount（租金）、deposit_amount（押金）、overdue_amount（超期费）、damage_amount（损坏赔偿），最后再算一个total_amount。拆开存的好处是退款时不用反推，每笔钱都能追溯。

超期费按天递增，越往后越贵，这样才有约束力：

public BigDecimal calcOverdueFee(BigDecimal dayPrice, long overdueDays) { if (overdueDays <= 0) { return BigDecimal.ZERO; } if (overdueDays <= 3) { return dayPrice.multiply(new BigDecimal(overdueDays)); } // 超过 3 天，超出部分按 1.5 倍计 BigDecimal base = dayPrice.multiply(new BigDecimal(3)); BigDecimal extra = dayPrice.multiply(new BigDecimal("1.5")) .multiply(new BigDecimal(overdueDays - 3)); return base.add(extra); }

金额一律用BigDecimal，不要用double。这一点我在评审代码时见得太多，0.1 + 0.2算出来0.30000000000000004，押金退款差几分钱，用户投诉，你还得写个脚本去对账。BigDecimal做除法的时候记得指定精度和舍入模式，divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP)，不指定会抛ArithmeticException。

清洗费的处理方式我在项目里是这样做的：不预收，在验收环节由后台判定。如果只是正常使用痕迹，不收；有明显的酒渍、化妆品印这类需要特殊处理的，按配置表里的标准扣一部分押金。这个逻辑要在界面上写清楚，别让用户觉得是乱扣钱。

4.3 两个人同时下单同一件汉服怎么办

这是答辩现场的高频追问，也是最能体现技术水平的地方。假设库存只剩一件，A 和 B 几乎同时点下单，两条请求进来，都通过了冲突检测，都写入了订单，结果就是超卖。

三种应对思路，从低到高：

第一种，数据库行锁。在检测和写入之间加一层锁，把要占用的实物行锁住：

@Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 先按 item_id 升序排序，避免多件商品互相等待形成死锁 List<Long> itemIds = dto.getItems().stream() .map(OrderItemDTO::getItemId) .sorted() .collect(Collectors.toList()); // 2. 逐件加行锁 for (Long itemId : itemIds) { HanfuItem item = itemMapper.selectForUpdate(itemId); if (item == null || item.getStatus() != 0) { throw new BizException("该汉服当前不可租"); } } // 3. 锁住之后再做冲突检测 for (OrderItemDTO oi : dto.getItems()) { int conflict = orderItemMapper.countConflict( oi.getItemId(), oi.getStartDate(), oi.getEndDate()); if (conflict > 0) { throw new BizException("所选日期已被占用，请换个日期"); } } // 4. 写订单、写明细 // ... }

对应的 Mapper 方法：

<select id="selectForUpdate" resultType="HanfuItem"> SELECT * FROM hanfu_item WHERE id = #{id} FOR UPDATE </select>

注意两点：一是加锁的顺序必须统一，按 id 排序后再加，不然两个订单一个锁 1 号一个锁 2 号，互相等对方释放，就死锁了；二是@Transactional的粒度要覆盖整个流程，锁在事务提交后才释放，如果把检测放到事务外面，锁就白加了。

第二种，唯一约束 + 捕获异常。给占用记录建一个唯一索引，插入冲突时数据库直接拒绝，捕获DuplicateKeyException转成友好提示。这种做法简单粗暴，但只适用于“同一实物同一时段只能有一条记录”这种强约束场景，灵活性差。

第三种，Redis 分布式锁。用setnx加锁，设置过期时间，业务完成后释放。适合多实例部署，但对毕设来说属于过度设计，还会额外引入一个组件，答辩时解释成本更高。

我的建议是用第一种，够用，也能讲清楚。在开题报告的“关键技术”一节里把行锁和死锁避免写进去，这是个加分项。

5. 开题报告里那几页，老师最先看什么

5.1 研究现状别写成产品罗列

很多人写“国内外研究现状”，写成了“某某平台有几千套汉服、某某 App 支持在线预约”，通篇是产品介绍。老师扫两眼就知道是从网上抄的。正确的写法是先归类，再指出空白。

可以这样组织：把现有的汉服租赁渠道分成三类，一类是综合类二手交易渠道的个人租赁，特点是灵活但缺少档期管理、纠纷多；一类是垂直类汉服租赁小程序的线上预约，特点是流程标准化，但多数只做到“款式预约”，没有做到“实物级档期”，同一款多件的库存同步做得粗糙；一类是线下汉服体验馆的自有系统，特点是服务好，但系统多为通用租赁软件改造，缺少针对汉服的尺码匹配、配饰管理、清洗追溯这些环节。最后落到一句：本课题针对实物级档期管理和汉服特有属性建模这两个点做工作。

这个写法有三个好处：有分类、有对比、有落点。老师看到会认为你做过功课。

5.2 功能模块图和用例图必须对得上

这是中期检查最容易被挑刺的地方。功能模块图里画了“订单管理”，用例图里却找不到对应的用例；用例图里有“管理员审核”，功能模块图又没这个框。两图对不上，说明是分别从两个模板里抠出来的。

我的做法是先定角色，再定用例，最后才画模块图。角色只有两个：普通用户、管理员。普通用户的用例包括浏览款式、查看档期日历、下单租赁、支付押金、归还申请、评价；管理员的用例包括款式维护、实物入库、订单发货、归还验收、清洗登记、异常处理。功能模块图就是把这些用例按业务归类，用户侧归成“商品浏览、租赁下单、个人中心”三块，管理侧归成“款式管理、实物管理、订单管理、清洗管理、统计报表”五块。这样两图天然一致。

5.3 进度安排与参考文献的写法

进度安排别写“第 1-2 周：需求分析；第 3-4 周：系统设计”这种糊弄式的内容，看起来像模板。可以按交付物来写，比如“第 3 周末：完成数据库设计说明书，含 10 张表的 E-R 图和字段字典”，有具体产出，显得是真计划。

参考文献这一块有个细节：别全列中文期刊论文，也别全列外文。我的习惯是中文 5 到 8 篇加外文 2 到 3 篇，中文里挑两篇和租赁业务相关的（比如共享经济下的信用租赁模式研究），外文里挑一两篇讲区间数据建模或者并发控制的。数量凑够，类型搭开，老师一般不会再问。

6. 交付前自测清单和答辩常见追问

6.1 我给自己定的回归测试清单

功能做完不等于能交付。每次改完代码，我会按这张表跑一遍，十来分钟，能挡掉八成的低级问题。

第 4 条防重复提交容易被忘。做法很简单，前端按钮点击后置灰，后端在 Redis 里用一个order:submit:{userId}的键做 3 秒幂等，或者直接在订单表加一个前端生成的request_id唯一索引。

6.2 老师最爱追问的几个点

我把这几年听到的问题归了归类，基本上跑不出这几个：

第一个：你的系统怎么防止超卖。这就是 4.3 那套，思路讲清楚就行，先说明为什么会冲突，再说用了什么手段，最后说怎么避免死锁。

第二个：如果用户把衣服弄坏了怎么办。回答要落到流程上：验收环节拍照留档，后台判定损坏等级，按配置表扣款，扣款记录进deposit_log，用户可以在个人中心看到明细并申诉。别只说“扣押金”，太单薄。

第三个：你的数据和真实业务规模对不上。这个是在问性能。可以答：当前数据量下联合索引足够支撑，档期查询走的是item_id + 日期的联合索引，单表十万级记录下响应在百毫秒内。如果量级再上台阶，会把历史订单归档到独立表，只保留近半年的活跃档期参与冲突计算。

第四个：为什么用前后端分离。回答别扯技术潮流，就说实际理由：小程序端、后台管理端、用户端要共用一套接口，分离之后接口复用，改界面不影响逻辑，联调时用文档就能对接。

第五个：这个课题的创新点在哪。千万别说“我用了 SpringBoot”，那不是创新点。可以这样答：一是把库存粒度从款式下沉到实物单件，解决了同款多件时的档期不同步问题；二是引入了归还缓冲期和清洗状态追踪，让线上系统能对上线下运营的真实流程；三是在押金结算上做了分段超期费用和损坏赔偿分离，账目可追溯。

最后再分享一个我自己踩过的坑：这个项目最耗时间的不是写业务代码，而是前端日历组件的可租日期高亮。一开始我图省事，在前端按每个日期循环调一次接口，一件衣服三十天的日历就是三十次请求，页面直接卡住。后来改成后端一次返回所有已占用区间，前端在渲染时做区间匹配，请求数从三十次降到一次。这个改动花了我小半天，但后续做列表页的日期筛选时直接复用了同一套逻辑，省下的时间比花掉的多得多。所以你如果也在做这个，先把“批量返回区间”这个接口设计好，别等页面卡了再回头改。