做Java Web毕设最怕的不是代码写不出来而是题目选得太大最后东拼西凑自己都讲不清楚。我最后定的题目是“SpringBootVue高校汉服租赁网站平台”前后端分离、带完整SQL脚本和接口文档从选题、建表、写接口到前端页面陆续做了四个多星期。这篇文章把我整个做项目的思路、数据库设计、核心模块和常见的坑都梳理一遍适合正在选毕业设计题目、或者想快速跑通一个前后端分离项目的学生参考。1. 项目从选题到落地的整体思路拆解1.1 为什么选“汉服租赁”这个业务场景毕设选题最重要的标准是“业务复杂度刚好”。选纯电商卖衣服流程太常见评委看一眼就猜到是CRUD选二手交易平台又要涉及支付、担保交易、聊天沟通复杂度很容易失控。汉服租赁恰好卡在中间。汉服这个品类的特点是单价高、使用频率低学生想参加校园活动、拍写真但购买成本太高租赁需求天然存在。更重要的是租赁业务的规则比普通买卖多一层租期按天计算押金在下单时就要收取归还时要检查汉服是否损坏损坏要扣一定费用逾期归还要另外计算逾期费用同一件汉服在规定日期内不能被重复预订。这样一来系统建模就比单纯的“商品订单”多了不少需要设计的地方。库存不再是一个单纯的数字还要考虑时间段占用订单金额也不再是简单的单价乘数量而是租金加押金再减去各种扣款的组合。这些业务规则写进论文和答辩PPT里都有内容可讲评委也不会觉得项目太单薄。1.2 技术栈选型SpringBootVue的前后端分离方案最开始我也纠结过要不要用传统的JSPSSM主要是网上教程多、学校以前的项目也大多是这种。但仔细算账后发现SSM的配置成本太高SpringMVC里光spring-web.xml、spring-service.xml、mybatis-config.xml就要写一大堆出问题排查半天。SpringBoot把自动配置和内嵌Tomcat都做好了一个Application类就能跑起来省下的时间可以全部放在业务逻辑上。前端我用的是Vue2 Element UI后面如果你时间比较充裕也可以换成Vue3 Element Plus业务逻辑基本一样只是个别组件用法有差异。之所以不继续用服务端渲染的JSP是因为前后端分离之后优势很明显后端只提供JSON接口不关心页面长什么样前端可以单独调试配合Vue CLI的代理转发很方便部署时后端打一个jar包前端build出静态文件结构非常清晰。数据库用MySQL 5.7或8.0ORM选MyBatis-Plus而不是原生MyBatis。MyBatis-Plus对单表CRUD提供了现成方法像分页、条件查询基本不用手写SQL能把精力省下来放在租赁业务本身。这组技术栈在Java Web毕设里非常主流遇到问题几乎都能搜到现成的解决办法。1.3 功能模块全景图整个系统只分两大类角色管理员和普通用户学生。用户端注册、登录、个人信息维护浏览汉服列表按朝代形制、价格区间筛选支持关键词搜索汉服详情页多图展示、尺码库存、押金和日租金、用户评价购物车加购、修改数量、删除下单租赁选择租期、计算总费用、模拟支付订单中心待支付、待取货、租赁中、已归还、已取消归还后可以填写评价。管理员端汉服分类管理、汉服信息维护包括封面图、多图、库存、价格订单管理查看所有订单、标记取货、确认归还、处理逾期用户管理禁用或启用账号公告管理发布站内公告首页统计总用户数、总订单额、各分类租赁占比。模块划分清楚之后数据库设计和接口设计都跟着这套结构走后边写代码基本就是按图索骥不会出现一边写一边改功能的混乱局面。2. 从零开始的数据库设计2.1 核心表结构与业务关系数据库是毕设项目的根基库表设计得好后面接口写起来会非常顺。我设计的表结构并不复杂核心就是把商品、订单、归还、评价这几条线拆清楚。用户表userid、username、password、nickname、phone、avatar、role、status、create_time、update_time汉服分类表hanfu_categoryid、name、sort、status汉服表hanfuid、category_id、name、dynasty、style、size、color、description、daily_price、deposit、stock、cover_image、images、status、deleted、create_time购物车表cartid、user_id、hanfu_id、count、create_time订单表ordersid、order_no、user_id、total_price、deposit、status、rent_start_date、rent_end_date、rental_days、create_time、pay_time、fetch_time、return_time、cancel_reason订单明细表order_itemid、order_id、hanfu_id、hanfu_name、daily_price、deposit、count、rental_days归还记录表return_recordid、order_id、return_time、is_damaged、damage_desc、damage_fee、overdue_days、overdue_fee、refund_amount、operator评价表reviewid、user_id、order_id、hanfu_id、content、score、create_time公告表noticeid、title、content、create_time、update_time用户和订单是一对多订单和订单明细是一对多因为一个订单可能同时租多件汉服。归还记录和订单一对一评价和订单也是一对一避免同一个订单被重复评价。2.2 SQL脚本中的关键设计细节我在SQL脚本里做了几个比较重要的决定写下来供参考。第一所有表都用utf8mb4字符集。汉服详情和评价里可能出现生僻汉字或特殊符号utf8mb4才能完整存下直接用默认latin1或utf8很容易在导入数据时报错或出现乱码。第二金额字段全部用DECIMAL(10,2)不要用FLOAT或DOUBLE。租金、押金、逾期费进数据库后要参与加减运算浮点数精度问题在金额场景下非常致命。展示的时候注意保留两位小数就够了。第三逻辑删除字段deleted和通用时间字段create_time、update_time在业务表里都留一份。逻辑删除的好处是数据不会真丢管理员误删了汉服还能恢复时间字段用MyBatis-Plus的自动填充插入和更新时不用手工维护。第四订单号order_no要加唯一索引。订单号格式是“yyyyMMddHHmmss 4位随机数”虽然撞号概率极低但唯一索引是数据库层面的最后一道防线万一重复就直接抛业务异常重新生成。第五初始化数据里放一个管理员账号。密码必须存BCrypt哈希不能存明文。BCrypt算法对同一个密码每次生成的结果都不同所以管理员初始密码写死在SQL里时要先用代码生成一次哈希再塞进去别以为写个明文也能登录成功。2.3 数据初始化与测试数据准备这个部分很多同学会忽略。项目能跑起来和演示效果好是两码事演示的时候首页只有5条汉服、订单列表空荡荡的评委几分钟就能看出准备不充分。我后来专门花了一个下午补测试数据。分类至少5个唐制、宋制、明制、晋制、现代改良汉服至少30条每个分类下6条左右覆盖不同价格档位封面图统一处理成jpg或webp用户至少10个密码统一用同一个哈希值方便演示时切换账号订单至少50条状态要覆盖待支付、租赁中、已归还、已逾期等各个阶段时间分布在不同月份这样统计图才有内容评价每条汉服2到3条内容尽量贴近真实体验。测试数据可以直接在SQL脚本里INSERT也可以在后台一条条录入。我建议直接写INSERT语句放进SQL脚本因为这样任何导入这个库的人都能马上看到完整效果也方便答辩前重置数据。3. 后端核心模块实现3.1 用户认证与权限控制用户认证我用的方案是JWT加拦截器没有引入完整的Spring Security。对毕设来说Spring Security配置繁琐各种过滤器顺序很容易把人绕晕与其把精力花在框架配置上不如把业务逻辑做得更扎实。登录接口流程是这样的用户提交username和password查询用户用BCrypt比对密码通过后生成一个JWT里面放userId、username、role有效期设成7天前端每次请求都在请求头的Authorization字段带上token。拦截器里要做两件事从请求头取出token并解析解析失败直接返回401解析成功后把userId和role放进ThreadLocal后面的Controller和Service随时能拿到当前登录用户。这里有个坑线程池和异步处理会丢失ThreadLocal数据。我的项目中归还记录和逾期检查用的定时任务是自己查询用户信息的不走ThreadLocal所以没有踩雷。如果你在业务线程里需要用户信息最好在进入线程之前就把它取出来传参不要等进入线程内部再读ThreadLocal。权限控制就是角色判断。管理员接口上加一个自定义注解用拦截器检查当前用户的role是否为admin权限不够直接拒绝。因为是毕设项目这个简单方案完全够用也容易跟评委解释。3.2 租赁订单流转的核心逻辑订单流转是项目中业务最重的部分也是最容易写乱的地方。我的做法是先定一个状态机再按状态写接口严格禁止订单状态随意跳变。订单状态定义0 待支付1 已支付待取货2 租赁中已取货3 已归还押金已处理4 已取消5 已逾期核心流程拆开来讲下单接口用户从购物车选择商品提交租期start_date和end_date后端校验租期不能早于今天、结束日期必须大于开始日期计算每件汉服的租赁天数结束日减开始日按自然日计算租金等于日租金乘以租赁天数检查每一件汉服在这个时间段内是否被占用查询该汉服所有“已支付、租赁中”状态的订单判断是否存在租期重叠库存充足则扣减库存生成订单和订单明细状态为待支付。有一点特别重要库存扣减和订单生成必须在同一个事务里执行。我用Transactional包住整个下单逻辑任何一步失败都会回滚不然会出现订单生成了但库存没减的脏数据。支付接口是模拟实现订单状态必须为待支付才能调支付支付成功后状态置为已支付记录支付时间。取货接口由管理员操作状态为已支付时才能取货取货后状态置为租赁中记录取货时间。归还接口也由管理员操作状态为租赁中才能归还先算实际归还时间是否超过租期结束日超出天数按逾期费单价计算检查汉服是否有损坏有损坏则记录损坏费应退押金等于原押金减去损坏费再减去逾期费不够扣就提示客户补缴生成归还记录订单状态置为已归还。这些校验逻辑如果漏掉任何一个就会出现“待支付订单直接变成已归还”“逾期没人管”这种答辩时一追问就露馅的问题。建议把状态校验抽成一个独立方法每次状态变更前先做一次断言。3.3 库存、并发与数据一致性答辩老师特别喜欢问并发问题两个用户同时租同一件汉服怎么办我当时做了两层处理。第一层下单时用乐观锁的思路。扣减库存的update语句可以写成update hanfu set stock stock - 1 where id #{id} and stock 0通过受影响行数判断是否扣减成功如果行数为0说明库存不足直接抛业务异常。这样即使并发请求同时进来数据库在行锁层面也会把这个update串行化不会出现库存扣成负数的问题。第二层订单租期重叠的校验不能只靠应用层的for循环去查就算查到了也可能被并发窗口绕过。我在hanfu表上额外维护了一个不可租状态字段当某个时段被订单占用时直接标记下单时先检查这个字段。不过毕设场景并发量很小第一层的update语句加上事务实际已经能挡住绝大多数问题。还有一处数据一致性容易忽略库存的初始值。我被自己坑过一次导入SQL脚本后汉服表库存是0前端页面显示有商品但一点“立即租赁”就提示库存不足。后来我在初始化脚本里把所有汉服库存统一写成5到10并把下单扣库存的逻辑写得足够直观才算解决了演示时的尴尬。3.4 统一返回体与全局异常处理前后端接口约好统一的返回结构非常重要否则前端每个接口都要单独处理错误分支。我的Result对象很简单{ code: 200, message: 操作成功, data: {} }code固定几个值200成功、400参数错误、401未登录、500系统异常。业务异常统一抛BizException全局异常处理器捕获后返回对应的code和message前端在响应拦截器里拿到非200就把message弹出来给用户看。参数校验我用了Validated配合javax.validation的NotNull、NotBlank、Min注解省去大量手写if判断。Controller层的代码看起来干净很多评委翻源码的时候印象也会更好。全局异常处理器里还要单独处理MethodArgumentNotValidException把具体的校验失败信息返回给前端不然用户看到的永远是笼统的“系统异常”体验会差很多。4. 前端Vue实现与页面交互4.1 前端项目搭建与目录结构我用vue-cli创建的前端项目目录结构分成几块src/api每个模块的接口请求函数src/router路由表和路由守卫src/store用户状态、购物车状态src/views页面组件src/components公共组件比如验证码、图片上传、分页src/utilsaxios封装、日期工具、金额格式化axios封装是最先要做的事情。请求拦截器里把token从localStorage取出来放到请求头响应拦截器里判断result.code不是200就调用Element UI的Message提示碰到401就清掉本地token并跳转登录页。这样业务组件里只需要写this.$axios.get(/api/hanfu/list)然后直接拿data使用不需要每个页面重复处理错误逻辑。路由守卫用的beforeEach进入需要登录的页面时判断store里有没有用户信息没有就跳登录页并带上redirect参数登录成功后跳回原页面。这个小交互做出来很加分评委演示时能直观看到登录态控制的效果。4.2 核心页面拆解首页是门面我把它分成顶部导航、轮播图、分类tab、汉服卡片网格、底部公告几块。顶部导航放搜索框和购物车入口购物车角标数量用Vuex里的状态驱动登录后从后端接口拉取购物车数量。汉服列表页支持分类筛选和价格排序我用的是Element UI的Tabs组件和下拉选择器筛选条件变化后调后端分页查询接口。需要注意后端分页参数pageNum和pageSize要和Element UI的Pagination组件对应好页码从1开始不要混用。详情页信息量比较大左侧多图轮播右侧显示名称、朝代形制、日租金、押金、尺码、库存和可租日期下方是评价列表。用户选择开始日期和结束日期后前端把两个日期传给后端后端返回该时间段的总费用点击“立即租赁”或“加入购物车”调用对应接口。订单确认页要展示每个商品明细、租金小计、押金合计并且明确标明“押金在归还后扣除相关费用原路退回”。这是租赁场景和普通电商最大的区别这块业务表达清楚整个项目的专业度就体现出来了。后台管理端我用的布局是左侧菜单加右侧内容区。汉服管理页面核心是表格加弹窗表单表格列包括封面缩略图、名称、分类、价格、库存、状态表单里图片上传组件把文件传到后端返回图片URL再回填到表单。4.3 与后端联调的关键点前后端联调最容易出问题的地方在跨域和字段格式上。跨域问题开发环境下最简单的方式是vue.config.js里配置devServer.proxy把/api前缀的请求全部代理到后端地址。线上部署时让nginx代理后端接口或者后端直接加CorsFilter允许跨域。我写了一个CorsConfig配置类开发环境和线上都能跑省心很多。日期格式后端返回的LocalDate默认格式是yyyy-MM-dd但LocalDateTime默认带T比如2025-01-01T10:20:30前端展示肯定不想要这个T。统一在application.yml里配置spring.jackson.date-format或者对时间字段单独加JsonFormat注解。金额格式后端返回的是BigDecimal前端直接用就行但计算合计时要小心浮点精度。我都是先把字符串转成Number再算最后用toFixed(2)保留两位小数显示。购物车里几条数据加起来金额不对多半就是浮点精度在捣乱。图片上传上传接口返回的URL要区分绝对路径和相对路径。我把图片统一放到了后端的static/upload目录下返回的URL直接是相对路径前端拼接自己的请求地址访问。注意Windows和Linux的路径分隔符不同拼接文件路径时要处理一下不然部署到服务器上图片全挂。5. 接口文档编写与自测5.1 一份能用于毕设的接口文档应该包含什么接口文档不只是给答辩看的它同时也是开发期前后端沟通的契约。这份文档最后交付时包括下面几块内容项目概述和环境约定BaseURL、数据格式、鉴权方式通用错误码表用户模块注册、登录、获取个人信息、修改个人资料汉服模块分页查询、详情、分类列表、搜索购物车模块列表、加入、修改数量、删除订单模块创建订单、支付、取消、详情、我的订单列表、管理员订单列表、取货、归还归还模块归还记录查询、押金退回明细公告和评价模块。每个接口的格式统一为请求URL、请求方式、请求参数表格、成功返回JSON示例、可能的错误码。参数表格里要标注是否必填、类型、长度限制返回示例里别省略字段把真实数据贴进去。比如汉服详情接口返回示例就写成完整的一条记录包含id、名称、分类、价格、库存、图片URL、描述等字段这样评阅人一眼就能看懂接口的用途不需要再翻代码。除了手写的文档我还在项目里集成了Knife4j自动生成在线接口文档。SpringBoot加一个依赖写几个注解就能在浏览器里打开接口调试页面。手写文档用作纸质交付Knife4j在线文档用于答辩现场演示两边都覆盖算是比较稳妥的做法。5.2 用Apifox从零自测一套订单流程自测是整个开发过程中最容易被拖延的环节。我的习惯是每写完一个模块就跑一遍全套接口而不是拖到最后一次性联调几十个接口堆在一起出问题时根本定位不了。推荐用Apifox或Postman建一个环境变量把token存成变量登录接口返回的token自动写入变量后续所有需要登录的接口直接引用。这样测试一套流程可以连续跑下来不用每次重新登录。完整流程建议按业务顺序走注册新用户登录拿token查询汉服列表选一个有库存的商品加入购物车创建订单日期选未来三天支付订单管理员登录查询待取货订单管理员执行取货管理员执行归还分别测无损坏和损坏两种情况查看应退押金金额和归还记录。跑这套流程的同时故意把日期改成已经过期的验证逾期费计算对不对再改成和已有订单重叠的日期看库存占用能不能被拦住。异常路径测试完项目才算真正稳了。纸上写十个接口文档都不如实测一遍暴露的问题多这是我当时最深的感受。6. 部署运行与避坑实录6.1 本地从零跑通的完整步骤拿到这套源码后最快跑通的步骤如下用Navicat或命令行执行SQL脚本创建数据库和表注意SQL脚本文件头部会指定数据库名跑之前先确认有创建数据库的权限用IDEA打开后端项目等待Maven依赖下载完成修改application.yml里的数据库地址、账号、密码时区配置成serverTimezoneAsia/Shanghai否则连MySQL 8会报时区错误启动后端Application类看到“Started Application in x seconds”就说明成功了进入前端目录先npm install再npm run serve浏览器打开前端地址管理员账号和普通用户账号在SQL脚本里都有说明初始密码统一。后端默认端口配的8080前端开发服务器端口配的8081这样前后端不会冲突。如果不小心撞了端口改一下配置文件就能解决。6.2 常见坑与避坑经验我踩过且印象比较深的几个坑汇总一下MySQL 8.0的驱动名为com.mysql.cj.jdbc.DriverMySQL 5.7用com.mysql.jdbc.Driver版本别混用混了启动直接报ClassNotFoundException导入SQL脚本时如果报“unknown command”或者中文乱码检查文件编码是不是UTF-8以及连接数据库时是否指定了useUnicodetrue和characterEncodingutf8前端npm install慢可以用国内镜像源但换源后可能出现依赖版本缓存问题遇到奇怪报错先清理npm缓存后端图片URL在浏览器打不开多半是静态资源映射没配置SpringBoot里要写一个WebMvcConfigurer手动addResourceHandlersVue的axios请求如果baseURL配置错误会出现404建议先单独测试登录接口通不通再写页面定时任务扫描逾期订单时依赖服务器时间答辩演示如果临时改了服务器时间扫描结果可能不符合预期最好做一个小接口手动触发扫描演示更可控。6.3 答辩与演示的几个实用心得最后说点实际操作中的体会。答辩时演示环节比PPT更关键宁可少讲优点也要把一条完整用户流程顺下来。我当时准备了两套数据一套是模拟数据用于正常演示一套是空库直接导入SQL用于展示“从零到跑通”的能力。常见问题和答复思路我也准备了几个问为什么前后端分离就从维护性和部署便利性讲问订单状态如何处理就画状态机讲清楚每一跳的触发条件问并发怎么防超卖就讲库存扣减的update条件语句。这几个问题答好了整个项目的可信度就上来了。如果你也想做这个题目或者正在做类似的前后端分离毕设我建议先把数据库和接口文档定下来再动手写代码磨刀不误砍柴工。中途改表结构是最痛苦的不仅后端代码要跟着改前端字段也要一起调那一晚上我是记忆犹新。这套项目源码和SQL脚本现在整理得很完整按照上面步骤跑一遍基本半天内就能看到完整效果。