企业官网建设流程全解析

1. 项目概述：这不是一个简单的增删改查练习

如果你正在为毕业设计发愁，或者想拿一个能写进简历里的Spring Boot项目练手，这套“特色民族服饰租赁系统”非常值得认真过一遍。我见过太多毕业设计从图书管理、学生管理系统这种老掉牙的题目里挑一个，最后答辩时自己都讲不出亮点。而民族服饰租赁这个切入点，业务逻辑完整，既有商品管理又有订单流转，还涉及库存、押金、归还周期这些真实业务场景，拿去做毕设或者项目经历，含金量完全不一样。

这套系统基于Spring Boot框架开发，核心解决的是传统民族服饰租赁流程效率低、信息不透明的问题——线下租借一件传统服饰往往要跑好几趟门店，尺码有没有货、租金怎么算、押金退不退都靠人肉记录。系统把它搬到线上：用户能浏览服饰、按尺码和风格筛选、线上下单、支付押金租金，管理员能管理服饰上架、处理订单、跟进归还状态。前后台角色分离，权限清晰，业务闭环完整。

说实话，这类系统在真实行业中已经有相当成熟的应用形态，比如影楼服装租赁、演出服租赁、景区旅拍服饰租赁，底层逻辑完全相通。只不过程序设计的角度，把民族服饰租赁拆成“商品维度+订单维度+用户维度”来建模，是一个很标准、也很有代表性的教学案例。适合的人群非常明确：有一定Java基础、正在准备毕业设计或校招项目的同学，以及想快速上手Spring Boot + MyBatis Plus组合的初级开发者。

这套实战流程我会原原本本拆给你看：模块怎么设计、表结构怎么建、核心接口怎么实现、最容易卡住的坑在哪里。源码和论文的配套逻辑我也会顺带讲清楚，让你不只是会跑通代码，而是真正能讲明白“为什么这么做”。

2. 技术选型：为什么偏偏是Spring Boot

2.1 技术栈对比：Spring Boot为何成为首选

很多同学在选题时纠结过：用SSH还是SSM？用Spring Boot还是Spring Cloud？要不要上Vue做前后端分离？我说一下我的看法：毕业设计这个阶段，Spring Boot + MyBatis Plus + MySQL 这套组合就是性价比最高的选择，没有之一。

SSH（Struts2 + Spring + Hibernate）已经是上个时代的产物，现在公司里几乎没人新开这种项目，写了反而显得技术陈旧。SSM（Spring + Spring MVC + MyBatis）虽然还算流行，但配置繁琐，各种XML和注解混在一起，学生光折腾环境就要耗掉一周。Spring Boot把Spring家族的配置简化到了极致，内嵌Tomcat，一个spring-boot-starter-web依赖就能跑起来Web服务，这才是现代Java开发的主流姿势。

至于MyBatis Plus，它的强大之处在于“单表CRUD零SQL”，你可以继承BaseMapper<T>直接获得增删改查方法。对于毕业设计，不需要你手写复杂的多表Join，大部分查询都是单表+条件构造器，MyBatis Plus的LambdaQueryWrapper写起来比拼SQL字符串舒服太多了。而且MyBatis Plus在国内中小型公司使用率极高，学了不亏。

有人可能会问：那要不要用Vue做前后端分离？我的建议是：除非你对前端特别熟悉，否则别碰。不是说前后端分离不好，而是毕业设计只有几个月时间，你还要写论文、做PPT、准备答辩，再抽时间学Vue、Element UI、Axios，精力根本不够用。Spring Boot + Thymeleaf（服务端渲染模板引擎）足够完成这个项目的全部页面展示，代码量更少，逻辑更集中，论文也好写——所有视图渲染都归后端管，你只需要专注于接口和业务逻辑。而且服务端渲染的项目部署也更简单，打包成jar直接跑，不需要单独部署前端静态资源。

2.2 环境准备与工具链清单

我自己搭过不下十次这套环境，把清单给你列出来：

• JDK：必须是1.8或11，推荐1.8，稳定，网上资料多，不会有升级到17之后各种依赖兼容性问题。
• IDE：IntelliJ IDEA，社区版完全够用。别用Eclipse，Spring Boot对IDEA的优化和内置支持好太多。
• 数据库：MySQL 5.7或8.0。5.7够轻量，8.0也行，但要注意驱动版本问题。建议用8.0，因为5.7官方已经停止维护了。
• 数据库可视化工具：Navicat或DataGrip二选一。DataGrip是IDEA全家桶风格，Navicat更大众化。
• 项目管理：Maven 3.6以上，用IDEA自带的也行。
• Postman或Apifox：接口调试必备，模拟前端请求直接打后端。

环境搭建部分踩坑率最高的就是JDK和Maven版本不匹配、Maven仓库下载依赖超时。建议把Maven的中央仓库镜像换成国内镜像，依赖秒下。这个细节不懂的同学可以搜“Maven国内镜像配置”，非常基础。

2.3 为什么排除了微服务和分布式架构

我理解有些同学想显得高级，动不动就想用Spring Cloud Alibaba、Redis、RabbitMQ。但我要给你泼盆冷水：这套民族服饰租赁系统的业务量级，完全不需要微服务架构。单机Spring Boot应用就能扛住几千并发，你引入Nacos、Gateway、Sentinel只是给自己挖坑——每个组件都要学、要配、要排查，答辩时老师一问“为什么用微服务”，你说不出个消费场景，反而暴露短板。

Redis可以做，但不是必须。本项目核心数据是库存和订单，必须保证强一致，Redis缓存适合读多写少的场景，服饰列表也许适合缓存，但毕设体量下MySQL直接扛完全没问题。如果你非要用Redis展示一下技术广度，建议只做“服饰浏览计数”或“验证码存储”这种非核心场景，当作加分项写在论文的创新点里，而不是把核心流程复杂化。

同理，消息队列在你这个项目里没有用武之地——没有削峰填谷的场景，没有异步解耦的必要，订单流程是简单的同步事务。技术的价值在于解决实际问题，而不是堆砌名词。

3. 项目思路拆解：从业务需求到功能模块

3.1 系统角色与核心业务流程

民族服饰租赁系统要回答三个问题：谁在用？用哪些功能？功能之间怎么流转？

角色划分很清晰：普通用户（游客/注册用户）和管理员。这是最经典的前后台双角色模型。

用户的完整操作路径是这样的：注册登录 → 浏览服饰列表 → 查看服饰详情（包括图片、尺码、租金、押金、库存量） → 选择尺码和租赁天数 → 提交订单 → 在线支付租金和押金 → 管理员确认发货/到店自取 → 用户穿着使用 → 到期归还 → 管理员验收服饰 → 退还押金 → 订单完成。

管理员的操作路径对应为：后台登录 → 服饰管理（增删改查、上下架、库存维护） → 订单管理（查看所有订单、确认租赁、变更状态） → 用户管理（查看用户列表、禁用违规用户） → 公告管理（发布平台公告） → 反馈处理（处理用户问题）。

注意这里有一个关键的金融环节：押金。押金的存在让这个系统比普通电商系统多了一层业务逻辑。押金不是在支付时直接没收，而是作为冻结资金，归还时验收合格才退还。这就涉及到订单状态的设计，比单纯的“待发货→已发货→已完成”要复杂一些。

还有一个维度容易忽略：库存。服饰租凭讲究“时间段维度”的库存——同一件衣服，在时间段A被预定了，时间段B可能还可以租。如果想做成真正精细化的系统，需要引入时间段排期表。但毕业设计阶段，我们做简化处理：每个服饰SPU（标准产品单元）设置一个总库存数字，用数字减库存，归还时加库存。虽然不算完美，但足够演示完整的业务闭环，论文里也容易解释清楚设计取舍。

3.2 功能模块地图：前端展示与后台管理

功能模块图是论文必备的，但更重要的是你要让模块落地到代码里。我按模块拆开来说。

用户端模块包括：

• 注册登录：邮箱/用户名+密码，密码加密存储，登录态用Session或Token管理。推荐JWT，因为前后端分离时也能用。
• 服饰浏览：首页展示推荐服饰、分类导航（按民族风格分类，比如苗族、藏族、蒙古族等）、服饰搜索（关键词、风格、尺码、价格区间）、服饰详情。
• 购物车：用户可以把多件服饰加入购物车，统一结算。这个模块看起来简单，但它考验你一对多关系的设计能力。
• 订单中心：我的订单列表，订单详情，取消订单，确认收货，发起归还。
• 个人中心：个人信息修改，密码修改，我的收藏，联系客服/提交反馈。
• 支付与押金：模拟支付流程，支付成功后同时锁定库存。

管理员端模块包括：

• 仪表盘：统计今日订单数、总用户数、服饰总数、待处理订单数。
• 服饰管理：上传服饰信息（名称、图片、风格分类、尺码、库存、租金价格、押金价格、服饰描述），修改上下架状态。
• 订单管理：查询所有订单，按状态筛选，操作订单状态流转（确认、发货、完成归还、拒绝等）。
• 用户管理：查看用户列表，启用或禁用用户账号。
• 公告管理：发布平台公告，用户端首页展示。
• 数据统计：简单的折线图展示最近一周订单量、收入。

这些模块听起来多，但落到数据库层面其实就五六张核心表：用户表、服饰表、订单表、订单明细表（可选，如果一张订单包含多件商品就需要）、收藏表、公告表、反馈表。表设计我下面详细讲。

3.3 数据库设计：表结构才是系统的灵魂

我见过太多学生项目，代码写得没问题，但数据库表一塌糊涂。表设计决定了系统的扩展性和可用性，也是论文里“系统设计”这一章的核心内容。直接给你可用的建表思路。

用户表sys_user：

CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '密码(MD5加密)', `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `role` tinyint(4) NOT NULL DEFAULT '1' COMMENT '角色: 0管理员 1普通用户', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态: 1正常 0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

服饰表costume：

CREATE TABLE `costume` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '服饰ID', `name` varchar(100) NOT NULL COMMENT '服饰名称', `category` varchar(50) DEFAULT NULL COMMENT '民族风格分类', `image` varchar(255) DEFAULT NULL COMMENT '服饰图片URL', `images` text COMMENT '多图URL，逗号分隔', `size` varchar(20) DEFAULT NULL COMMENT '尺码: S/M/L/XL/XXL/均码', `color` varchar(20) DEFAULT NULL COMMENT '颜色', `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存数量', `rent_price` decimal(10,2) NOT NULL COMMENT '租金(元/天)', `deposit` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '押金', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态: 1上架 0下架', `description` text COMMENT '服饰描述', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='服饰表';

订单表rent_order：

CREATE TABLE `rent_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '订单ID', `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '下单用户ID', `costume_id` bigint(20) NOT NULL COMMENT '服饰ID', `size` varchar(20) DEFAULT NULL COMMENT '下单尺码', `rent_days` int(11) NOT NULL DEFAULT '1' COMMENT '租赁天数', `start_date` date DEFAULT NULL COMMENT '租赁开始日期', `end_date` date DEFAULT NULL COMMENT '预计归还日期', `actual_return_date` date DEFAULT NULL COMMENT '实际归还日期', `rent_fee` decimal(10,2) NOT NULL COMMENT '租金费用', `deposit` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '押金金额', `total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额(租金+押金)', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态: 0待支付 1已支付待取货 2租赁中 3已归还 4已取消 5已退款', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', `pay_time` datetime DEFAULT NULL COMMENT '支付时间', `return_time` datetime DEFAULT NULL COMMENT '归还时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_costume_id` (`costume_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租赁订单表';

收藏表favorite、公告表notice、反馈表feedback设计思路类似，核心都是外键关联用户或内容，加一个创建时间。整体就够支撑整个项目了，不会增加学生负担，论文里还能画出E-R图来充章节内容。

这里提一个很多同学会犯的错误：订单表里直接用costume_name字段冗余存储服饰名称。有人说这违背范式，但我要说，在订单这种业务里冗余字段是必要的——如果管理员修改了服饰名称，历史订单不应该跟着变。这叫“历史快照”思想，在电商领域是标准做法。

4. 核心代码实现：手把手拆解关键环节

4.1 创建项目与Maven依赖配置

打开IDEA，选择Spring Initializr创建项目，语言Java，类型Maven，包装Jar，Java版本8。

pom.xml核心依赖如下：

<dependencies> <!-- Web启动器 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- Thymeleaf模板引擎 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <!-- MyBatis Plus启动器 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency> <!-- Lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- 参数校验 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> </dependencies>

application.yml配置文件：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/costume_rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 thymeleaf: cache: false servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: auto

注意几个细节：map-underscore-to-camel-case必须设为true，这样数据库字段create_time能自动映射到实体的createTime，不然你就要手写一大堆ResultMap。log-impl开发阶段开着，能看到每一条SQL，排查问题极有用，上线前关掉即可。

4.2 实体类与Mapper层：MyBatis Plus如何省事

实体类用@Data注解简化getter/setter，用@TableName指定表名，用@TableId标注主键。

以订单实体为例：

@Data @TableName("rent_order") public class RentOrder { @TableId(type = IdType.AUTO) private Long id; private String orderNo; private Long userId; private Long costumeId; private String size; private Integer rentDays; private LocalDate startDate; private LocalDate endDate; private LocalDate actualReturnDate; private BigDecimal rentFee; private BigDecimal deposit; private BigDecimal totalAmount; private Integer status; private String remark; private LocalDateTime createTime; private LocalDateTime payTime; private LocalDateTime returnTime; }

Mapper层只需要继承BaseMapper：

@Mapper public interface RentOrderMapper extends BaseMapper<RentOrder> { }

就这一个接口，你就能对订单做增删改查了，这就是MyBatis Plus的价值所在。复杂查询用LambdaQueryWrapper轻松搞定，比如查某个用户的所有未完成订单：

LambdaQueryWrapper<RentOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(RentOrder::getUserId, userId) .in(RentOrder::getStatus, Arrays.asList(0, 1, 2)) .orderByDesc(RentOrder::getCreateTime); List<RentOrder> orders = rentOrderMapper.selectList(wrapper);

这套写法你会用得很频繁，建议专门花半小时熟悉LambdaQueryWrapper的eq、ne、like、in、between、orderByDesc、groupBy这几个方法，基本覆盖项目80%的查询需求。

4.3 下单核心逻辑：事务、库存与状态机

下单是项目最核心的接口，业务逻辑包括：校验服装是否存在和上架 → 计算租金费用 → 扣减库存 → 生成订单编号 → 保存订单。这里面最关键的是“扣库存”这步必须放在事务里，不能让并发请求把库存扣成负数。

Service层代码核心逻辑：

@Transactional(rollbackFor = Exception.class) public RentOrder createOrder(OrderCreateDTO dto) { // 1. 校验服饰 Costume costume = costumeMapper.selectById(dto.getCostumeId()); if (costume == null || costume.getStatus() != 1) { throw new BusinessException("服饰不存在或已下架"); } // 2. 预扣库存 if (costume.getStock() < dto.getQuantity()) { throw new BusinessException("库存不足"); } // 3. 计算金额：租金*天数 + 押金 Integer rentDays = dto.getRentDays(); BigDecimal rentFee = costume.getRentPrice().multiply(BigDecimal.valueOf(rentDays)); BigDecimal deposit = costume.getDeposit(); BigDecimal totalAmount = rentFee.add(deposit); // 4. 扣减库存 costumeMapper.updateStock(costume.getId(), -dto.getQuantity()); // 5. 生成订单 RentOrder order = new RentOrder(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setCostumeId(costume.getId()); // ... 设置其他字段 order.setStatus(0); // 待支付 rentOrderMapper.insert(order); return order; }

注意updateStock这一步，不要用先查后改的方式，而是应该直接用UPDATE语句做原子扣减：

<update id="updateStock"> UPDATE costume SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity} </update>

如果影响了0行，说明库存不足，直接抛异常并回滚事务。这是防止超卖最简单有效的手段，比先查询再判断更可靠。《深入理解分布式事务》里讲的锁机制和乐观锁，在这句SQL里体现得淋漓尽致——用数据库自身的行锁和条件更新来保证原子性。

订单状态流转用状态机思想管理，几个关键流转：

• 待支付(0) → 已支付待取货(1)：用户点击支付成功后，记录支付时间。
• 已支付待取货(1) → 租赁中(2)：管理员确认发货或用户到店自取后。
• 租赁中(2) → 已归还(3)：用户归还，管理员验收通过后，退还押金。
• 任何状态 → 已取消(4)：用户取消或管理员关闭。

状态流转要写在一个service方法里，每一步校验上一个状态是否符合预期，防止乱跳状态。比如“已支付”的订单不能直接变成“已归还”，必须先经历“租赁中”。这种状态机约束在业务上非常必要，答辩时老师也爱问。

4.4 文件上传与服饰图片处理

服饰图片上传是本项目少有的“多媒体处理”需求。Storege方案不建议引入OSS、MinIO这些重型依赖，简单存到本地上传目录即可。

配置一个虚拟路径映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // uploadPath 是本地磁盘路径，filePath 是访问URL前缀 registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); } }

上传接口用Spring MVC的MultipartFile：

@PostMapping("/admin/costume/upload") public Result uploadImage(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("请选择文件"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFilename = UUID.randomUUID().toString().replace("-", "") + ext; File dest = new File(uploadPath, newFilename); file.transferTo(dest); String url = "/upload/" + newFilename; return Result.success(url); }

用UUID重命名文件是为了防止文件名冲突和中文乱码。图片大小限制在上面配置了max-file-size: 10MB。一个实操心得：上传目录千万别放在项目源码目录下，否则每次重新打包部署，上传的图片就被清空了。正确做法是放到一个外部绝对路径，比如D:/upload/或者Linux的/data/upload/。

4.5 登录认证与权限控制

用户登录逻辑不复杂，核心是密码加密和Session管理。

密码加密用MD5加盐，虽然MD5不算安全的加密算法，但毕业设计用它足够了。更正规的做法是用BCrypt，Spring Security自带BCryptPasswordEncoder，只是引入Security会增加不少配置成本。我的建议是：如果你不想额外引入Security依赖，就用MD5 + 盐值，并在论文里注明“在实际生产环境中建议使用BCrypt”。

登录后在Session中存储用户信息，用拦截器统一校验除注册登录外的所有请求：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod) { // 这里不拦截放行的接口，比如登录注册、首页列表 User loginUser = (User) request.getSession().getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect("/user/login"); return false; } } return true; } }

管理员请求在用户基础上再校验role == 0，写一个AdminInterceptor或者直接在注解上做判断即可。两个拦截器的注册顺序要处理好，先经过登录拦截器，再进管理员拦截器。别小看这个顺序，写反了会出现未登录却能访问管理页面的逻辑漏洞。

5. 前端页面实现的关键技巧

5.1 Thymeleaf模板与页面复用

虽然这是后端项目，但前端页面你绕不开。Thymeleaf语法简单，和HTML无缝结合，对于熟悉HTML的人来说几乎没有学习成本。

公共头尾部分建议用 fragment 抽出来：

<div th:fragment="header"> <!-- 导航栏 --> </div> <div th:fragment="footer"> <!-- 页脚 --> </div>

其他页面通过th:replace引入：

<div th:replace="~{common/header :: header}"></div>

这样改导航栏只需要改一个地方，所有页面同步生效。同时把CSS和JS文件也放到公共模板里统一引入，避免每个页面重复写。

列表页面的核心是利用Thymeleaf的th:each遍历渲染：

<div class="costume-grid"> <div class="costume-card" th:each="item : ${page.records}"> <img th:src="${item.image}" alt="服饰图片"> <h3 th:text="${item.name}">服饰名称</h3> <p th:text="${item.category}">民族风格</p> <p>租金：<span th:text="${item.rentPrice}">100</span>元/天</p> <p>押金：<span th:text="${item.deposit}">500</span>元</p> <a th:href="@{/costume/detail/{id}(id=${item.id})}" class="btn">查看详情</a> </div> </div>

页面上每一件服饰都是一张卡片，点击进入详情页。分页逻辑用MyBatis Plus的Page对象，后端selectPage直接返回分页数据，前端渲染页码。具体来说，控制器里接收pageNum和pageSize，用Page<Costume>查询，然后传给模板。注意current从1开始，数据库中firstResult偏移量是(current-1)*size，这一点经常有人搞错。

5.2 精选页面：详情页的数据联动

服饰详情页是整个用户端的“门面”，展示的信息最完整，交互也最多：服饰主图、名称、风格、库存、租金、押金、尺寸选择、数量选择、租赁天数选择，以及“加入购物车”和“立即租赁”两个按钮。

租赁天数的选择要联动显示价格变化，这一步可以用JS在前端实现：

function calculatePrice() { const days = document.getElementById('rentDays').value; const rentPrice = parseFloat(document.getElementById('rentPrice').dataset.price); const deposit = parseFloat(document.getElementById('deposit').dataset.price); const total = rentPrice * days + deposit; document.getElementById('totalAmount').innerText = total.toFixed(2); }

价格计算逻辑注意前后端一致——用户看到的预算是前端算的，但最终金额一定以后端计算为准。千万不能信任前端传过来的totalAmount字段，否则用户用开发者工具改价格，你的押金就损失了。后端在下单接口里重新用数据库的rentPrice×rentDays+deposit计算，才是安全做法。

库存显示逻辑：如果库存 ≤ 0，按钮要变成禁用状态，“立即租赁”不可点击，页面显示“暂时缺货”。如果库存 ≤ 5，建议显示“库存紧张”标签，制造紧迫感。

5.3 购物车与订单确认页

购物车是一个中间状态：用户还没决定下单，但有意向把多件服饰放在一起结算。购物车数据结构可以用Session存储，也可以用数据库表存储。毕业设计推荐用Session存储，因为不需要跨设备同步，也不涉及持久化。用户关掉浏览器，购物车清空，这符合真实场景。

订单确认页展示的是订单快照：服饰信息、租赁天数、起止日期、租金明细、押金明细、合计金额。用户点击“提交订单”后跳转到模拟支付页——这一步用一个模拟的支付二维码页面，点击“确认支付”后端直接把订单置为“已支付待取货”。

要注意的是，提交订单和支付之间有一个时间窗口，如果用户提交后不支付，库存已经被锁定住了。解决这个问题的方案有两种：一种是订单30分钟未支付自动取消，恢复库存，这是一个经典的定时任务场景；另一种是采用延时队列。毕业设计建议用Spring的@Scheduled定时任务，每1分钟扫描一次超时未支付订单，取消并恢复库存，代码简单，论文里还能作为技术亮点。

5.4 管理员后台页面

管理员页面用Thymeleaf写一个统一的布局，左侧是菜单栏（服饰管理、订单管理、用户管理、公告管理、数据统计），右侧是内容区域。整体风格参考常见的AdminLTE布局，但你可以直接用Bootstrap + 简单CSS实现，没必要特意引入AdminLTE框架。

订单管理页面是最重要的后台页面，需要支持状态筛选：

<a th:href="@{/admin/order/list(status=0)}">待支付</a> <a th:href="@{/admin/order/list(status=1)}">已支付待取货</a> <a th:href="@{/admin/order/list(status=2)}">租赁中</a> <a th:href="@{/admin/order/list(status=3)}">已归还</a> <a th:href="@{/admin/order/list(status=4)}">已取消</a>

后端根据status参数拼查询条件，列表里的每一行都有操作按钮：确认发货、确认归还、取消订单。关键操作都要求二次确认，可以用JS弹窗实现：

function confirmAction(url, msg) { if (confirm(msg)) { location.href = url; } }

6. 运行测试与问题排查实录

6.1 从零到跑通的完整流程

项目拿到手，第一步不是看代码，而是先把环境跑通。我的标准流程是：

1. 创建数据库costume_rental，字符集用utf8mb4。
2. 导入SQL文件，执行建表和基础数据（至少包含一个管理员账号、5条以上服饰数据）。
3. 修改application.yml里的数据库用户名密码。
4. 运行CostumeRentalApplication.java的main方法。
5. 浏览器访问http://localhost:8080，能看到首页即成功。
6. 用管理员账号admin / admin123登录后台，确认后台功能可用。

如果启动失败，90%的原因是数据库连不上。连接报错时先检查：MySQL服务是否启动；用户名密码是否正确；url里的数据库名是否存在；MySQL端口是不是3306（写成了3307也是常见错误）。

6.2 高频Bug与解决方案速查

我把这几年带学生做类似项目遇到的典型问题整理成表，建议你提前预防：

6.3 库存预扣回滚的坑

我在4.3节讲了用条件UPDATE原子扣库存，但还有一个隐藏问题：如果下单成功、库存已扣，用户却一直不支付，怎么办？这个坑我实际踩过：有同学做完项目演示时，连续下了好几单没支付，库存被扣光了，其他用户无法下单，系统“看起来挂了”。

解决办法就是我前面说的定时任务扫描超时订单。具体实现：

@Scheduled(fixedRate = 60000) // 每60秒执行一次 @Transactional public void closeTimeoutOrders() { LocalDateTime deadline = LocalDateTime.now().minusMinutes(30); LambdaQueryWrapper<RentOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(RentOrder::getStatus, 0) // 待支付 .lt(RentOrder::getCreateTime, deadline); List<RentOrder> orders = rentOrderMapper.selectList(wrapper); for (RentOrder order : orders) { // 恢复库存 costumeMapper.updateStock(order.getCostumeId(), order.getQuantity()); // 更新订单状态 order.setStatus(4); // 已取消 rentOrderMapper.updateById(order); } }

注意@Scheduled需要启动类加@EnableScheduling注解。这个功能放到论文里也算一个“细节优化”，比单纯做CRUD显得你考虑得更全面。

6.4 模拟支付接口与订单状态推进

真实对接支付宝或微信支付需要营业执照、商户号，毕业设计阶段显然不具备条件。标准做法是做一个模拟支付页面：

<!-- 模拟支付页面 --> <div class="pay-box"> <h3>订单金额：<span th:text="${order.totalAmount}">500</span> 元</h3> <div class="qrcode">【模拟二维码展示区域】</div> <button onclick="confirmPay()">确认支付</button> </div>

点击“确认支付”，向后端发送支付请求，后端直接修改订单状态为“已支付待取货”，记录支付时间，跳转到用户订单列表页。

管理员“确认发货”后，订单状态变为“租赁中”。到期后用户点击“申请归还”，管理员在后台点击“确认归还”，订单状态变为“已归还”，押金金额标注为“已退还”。这个流程把现实中的租赁业务完整搬到了线上，答辩时的业务讲解素材非常丰富。

7. 论文写作：让代码和文档互相成就

7.1 论文结构骨架

毕业设计论文有固定的套路结构：绪论（背景、意义、国内外研究现状）→ 相关技术介绍 → 系统分析（需求分析、可行性分析）→ 系统设计（总体架构、功能设计、数据库设计）→ 系统实现（截图+代码+讲解）→ 系统测试（功能测试、性能测试）→ 总结与展望。

技术介绍章节不要写成百科词条，应该结合项目说明：“本系统采用Spring Boot框架，利用其自动配置特性简化了传统SSM框架的XML配置……在数据持久层引入MyBatis Plus，借助其内建CRUD方法和条件构造器，显著提升了单表操作的开发效率。”

需求分析章节是整个论文的逻辑起点，要把用例图画出来，并把每个角色的功能边界说清楚。用例图用visio或者processon画，答辩PPT上也用得上。

7.2 核心创新点怎么提炼

很多同学的论文被批“没有创新点”，其实不是你没做创新，而是不会提炼。从你的代码里找亮点：

• 事务机制保证库存一致性：原子扣库存 + 事务回滚。
• 定时任务实现订单超时自动取消：体现你对异常场景的考虑。
• 逻辑删除与历史快照：体现数据安全意识。
• 分层架构与接口封装：体现工程化思想。
• 前后端数据联动校验：体现安全思维。

“库存超时释放”这个点，论文里可以单独写一小节，把定时任务与状态机结合的设计画成流程图，老师会觉得你是真的实践过，而不是抄代码。

7.3 系统测试章节的实操写法

测试章节不需要写复杂的JUnit单元测试，重点是功能测试记录。每个功能模块列一张表格：测试项、操作步骤、预期结果、实际结果、是否通过。例如：

这些测试尽量自己真实操作一遍，截图保存。测试截图是后面贴论文和做答辩PPT的素材。

8. 扩展方向与经验总结

8.1 想加分？试试这三个扩展点

如果你做完基础功能还有余力，我建议往这三个方向扩展，既不会太大工程量，又能明显提升项目档次。

第一个是公告模块的定时推送：管理员设置的公告在用户端首页显示，可以增加“已读”“未读”状态，或者绑定用户角色定向推送。第二个是数据可视化——后台增加订单趋势折线图、服饰热度排行榜、库存预警列表，用ECharts图表库就能实现，前端引入JS，后端提供统计数据接口。第三个是Excel导入导出：管理员需要批量导入服饰数据，导出用户订单列表，用EasyExcel工具包，几百行代码搞定，而且这功能在答辩现场演示特别亮眼。

8.2 你可能忽略的部署细节

到答辩阶段，项目需要现场演示。提前准备一套稳定环境，我建议用Docker方式部署MySQL，本地跑Spring Boot jar包。记得将application.yml中数据库连接改为你演示机器的IP或localhost，封装的jar包用mvn clean package生成。

还要注意一个细节：演示时不要用一上来就把密码输错的账号当场操作，提前准备好演示数据和演示账号，避免现场翻车。浏览器建议用Chrome的无痕模式，排除插件干扰。投影仪分辨率通常偏低，确保页面最小字号不小于14px，不然台下看不清你的代码、页面细节。

8.3 我的一点个人体会

做这种带“民族”元素的毕设项目，我心里其实挺有感情的。前年带A同学做完这套系统时，他是给家乡的文旅风景区做的线下租赁店定制，完成后店主说以后每个节假日盘点库存、结算押金再也不用翻纸质台账了。那一刻你会意识到，编程不只是教程里的增删改查，它能切实改变一个小店、一个小团队的工作方式。

我自己的经验是：做毕业设计，技术和业务哪一个都不能瘸腿。技术是骨架，业务是灵魂。你现在把Spring Boot这套实战做扎实了，简历上写“独立开发服饰租赁系统，覆盖商品、订单、支付、库存全链路”，面试官看到的是一个有完整业务思考的候选人，而不是一个只会抄代码的学生。

最后再说一个实操心得：拿到项目后，第一件事永远是先跑通，再改造。很多同学上来就改代码，结果把能跑的项目改坏了，又不知道哪里出错。先把原版的业务流程走一遍，记录每个页面的形态和每个接口的返回值，然后再按自己的需求去改。这套工作方法，在以后真实的项目开发中同样适用。