简介基于Java的校园二手交易平台设计与实现文档是一份面向计算机专业毕业生、Java Web开发学习者及毕业设计团队的完整项目设计参考重点解决校园二手商品在线交易系统的需求分析、架构设计与功能落地等问题。内容围绕SSMSpring、SpringMVC、MyBatis、Vue和MySQL的整合方案展开详细设计了管理员、普通用户、商家三类角色及其权限边界覆盖商品发布与审核、商品查询、购物车管理、订单管理、个人中心等核心模块并结合Java跨平台、Vue组件化、MySQL稳定支撑等特性阐述了具体的技术选型理由。包内共1个docx文件压缩包大小约3.45MB从内容预览可见其包含摘要、关键词、目录、绪论、系统分析等完整章节适合直接阅读与参考。目前已有33人学习下载。读者可从中获取课题背景分析、系统业务流程梳理、功能模块设计、数据库设计思路以及后期实现要点为毕业设计选题、论文框架搭建或校园交易类项目开发提供有效支持。 每年到毕业设计开题季总有一批同学拿着同一个问题来找我“Java学了SSM、Spring BootMySQL也会写但让我从零做一个完整项目我真的不知道第一步该干什么。”这种情况我一般会推荐校园二手交易平台这个选题。它不是我拍脑袋想出来的而是我前前后后指导、参与过好几个完整版本的Java Web项目之后认定最稳的一个方案。这个题目基于Java和Spring Boot这套主流技术栈业务上有完整的闭环规模又不会大到一个人做不完非常适合当作毕业设计或课程设计的项目主体。它的核心是把校园里闲置物品的流转——发布、浏览、搜索、购买、下单、确认交易——用一套完整的设计和实现落地成一个能运行、能演示的Web系统。这篇文章我就把这个项目的完整开发过程拆开讲一遍包含技术选型逻辑、数据库建模思路、核心模块的落地方式以及我在实际开发中踩过的那些坑。下面按我做这个项目的实际思路来写希望给正打算做这个题目的人一条可以直接参考的路线也帮你能在答辩时把“为什么这么设计”讲清楚。1. 为什么校园二手交易平台是Java项目里最值得做的“样板工程”1.1 业务闭环完整覆盖Java Web开发的核心知识点很多项目做完你会发现除了CRUD还是CRUD展示的时候很单薄。二手交易平台不一样它天然带着一整套业务状态和交互逻辑用户要注册、登录、修改资料商品要发布、修改、下架、被购买订单要创建、确认、完成、取消再加上收藏、留言、举报这些辅助功能一条链路走下来你会自然接触到权限控制、数据校验、状态流转、事务管理、文件上传、分页查询这些几乎所有Java Web开发都会用到的知识点。这套知识点不算复杂但足够完整。答辩时老师问“你这个项目涉及哪些技术”你几乎可以把Java开发的核心内容全部理一遍而且每一项都有真实的业务落点不是背出来的概念。1.2 校园场景比通用电商更容易做减法也更适合单人开发如果你照着淘宝、京东的思路去做电商系统很容易把自己劝退——优惠券、购物车、秒杀、分销、售后、物流跟踪随便一个模块都够写半个月。但把场景缩小到校园一切都可以做合理的减法。交易发生在同一个校区内买家卖家基本都是学生现货现款、当面交易是主流。物流、退款、多级分销这些复杂场景完全可以简化成“双方线下确认完成”。这个“做减法”的过程本身就是设计能力的体现。老师不会觉得你能力不足反而会认可你做了合理的需求取舍。校园二手交易平台是这个选题最大的优势有电商的味道但不用背电商系统的复杂度包袱。1.3 功能清单做一个什么程度的版本算“合格”根据不同学校的要求我把功能分成基础版和加分版两个档位。基础版至少要包含这些功能用户注册与登录、商品发布与图片上传、商品列表与分类筛选、关键词搜索、商品详情、收藏与取消收藏、下单购买、订单列表我买到的/我卖出的、确认交易、下架商品。加分版可以再加管理员后台用户管理、商品审核、举报处理、站内留言私信、个人主页展示、浏览记录、数据统计。建议先把基础版跑通再根据时间余量做加分项不要一上来就想做全功能。2. 技术选型与工程初始化不是越新越好而是越稳越好2.1 为什么是Spring Boot MyBatis-Plus MySQL这三件套基本是当下Java后端项目的默认组合。Spring Boot把Spring MVC、Tomcat、Jackson、参数校验等大量组件的配置都自动处理了打成一个JAR包就能启动比传统的SSMSpring Spring MVC MyBatis少写一大堆XML配置也更贴近现在企业的真实开发方式。MyBatis-Plus是MyBatis的增强工具它提供的BaseMapper已经内置了单表CRUD不需要为每张表手写insert、update、delete、selectById这些重复方法。它还带条件构造器LambdaQueryWrapper写复杂查询时比手拼SQL直观得多。MySQL用8.x版本建库时指定utf8mb4字符集。这一点特别提醒商品描述和留言内容里很可能出现Emoji表情utf8mb3也就是常说的utf8是存不下的跑起来会报“Incorrect string value”错误utf8mb4才能完整支持。2.2 前端方案Thymeleaf还是Vue这个选择题没有标准答案取决于你想把重点放在哪里。方案AThymeleaf Bootstrap后端渲染一个人维护一套代码部署简单适合把重心放在Java后端的场景。方案BVue3 Element-Plus前后端分离前端工程和后端工程分开部署交互体验更好适合想同时展示前端能力的同学。我的建议是如果毕业设计定位是Java后端方向用Thymeleaf完全足够还能省掉跨域、Token刷新、前后端联调这些额外工作。如果选了Vue就要接受工作量会多出不少。不要为了“听起来新”强行上微服务、Redis集群、MQ这些重型组件除非你有把握应对答辩时的连环追问。2.3 项目目录与基础配置推荐按技术层分包这种方式最容易讲清楚也最常规com.example.campus ├── controller // 控制层接收请求 ├── service // 业务层事务在这里控制 ├── mapper // 数据访问层继承BaseMapper ├── entity // 实体类与表对应 ├── common // 通用类返回结果、异常处理、常量 └── config // 配置类拦截器、资源映射、分页插件开工前先把三件事做好统一返回结果类、全局异常处理器、CORS跨域配置如果前后端分离。尤其是全局异常处理用RestControllerAdvice把业务异常和系统异常统一包装返回后面写代码时Controller层会很干净这也是很多新手一开始容易忽略但后续收益最大的配置。3. 数据库设计状态机没想清楚之前先别急着建表3.1 核心表字段的取舍我做这个项目时一共设计了8张表核心的是三张用户表、商品表、订单表。下面这张表是字段的参考版本-- 用户表 CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL COMMENT BCrypt加密存储, nickname VARCHAR(50) DEFAULT NULL, student_no VARCHAR(20) DEFAULT NULL COMMENT 学号, phone VARCHAR(20) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 商品表 CREATE TABLE goods ( id BIGINT AUTO_INCREMENT PRIMARY KEY, seller_id BIGINT NOT NULL, category_id BIGINT DEFAULT NULL, title VARCHAR(100) NOT NULL, description TEXT, cover VARCHAR(255) DEFAULT NULL COMMENT 封面图, images VARCHAR(1000) DEFAULT NULL COMMENT 多图逗号分隔, original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原价, sell_price DECIMAL(10,2) NOT NULL COMMENT 售价, condition_level TINYINT DEFAULT NULL COMMENT 成色5成到全新, trading_location VARCHAR(100) DEFAULT NULL COMMENT 交易地点, status TINYINT NOT NULL DEFAULT 0 COMMENT 0在售 1锁定 2已售 3下架, view_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 订单表 CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, goods_id BIGINT NOT NULL, buyer_id BIGINT NOT NULL, seller_id BIGINT NOT NULL, price DECIMAL(10,2) NOT NULL COMMENT 成交价快照, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待确认 1待交易 2已完成 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME DEFAULT NULL, finish_time DATETIME DEFAULT NULL );3.2 三个容易被忽略的设计细节第一订单表里必须单独存一份price不能下单时去查商品表取价格。因为商品价格后续可能被卖家修改订单必须保留下单那一刻的价格快照否则等交易完成后对不上账。第二金额类型用DECIMAL不用double或float。浮点数在二进制里本身就不精确算钱会出大问题。第三建议不建物理外键逻辑外键就够了。物理外键在分页查询、批量删除时会带来额外开销而且经常会出现“想删一条父表数据删不掉”的尴尬情况。实体之间通过业务代码保证一致性这也是当前项目开发里的主流做法。3.3 商品和订单的状态机设计商品状态我用的是这套0 在售中 - 1 已被下单(锁定) - 2 已售出 0 在售中 - 3 卖家主动下架 0 在售中 - 4 管理员下架这里最关键的是“1 已被下单”这个锁定状态。同一件商品不能被两个人同时下单所以商品从0变成1之后其他人可以浏览但不能下单只有当前订单取消或异常回滚时商品才回到0。这个设计是整个系统里最容易出错的地方很多初版实现就是漏了它才会出现同一本书被两个人买走的线上事故。订单状态我用的是这套0 待确认 - 1 待交易(约时间地点) - 2 已完成 0 待确认 - 3 已取消 1 待交易 - 3 已取消校园场景下订单不需要区分待付款、待发货、待收货那么细状态太多反而让流程显得冗长。买家下单后先处于待确认卖家看到订单即可联系买家约时间地点面交当面交易完成后订单确认完成这个状态流转足够覆盖校园二手交易的真实流程。3.4 辅助表辅助表有收藏表、留言表、举报表、分类表。收藏表一定要给user_id和goods_id加联合唯一索引否则用户点两下收藏按钮就插入两条记录这属于典型的数据重复。留言表是商品详情页的评论区字段包括商品id、发送人、接收人、内容、时间。举报表服务于管理员的审核功能记录举报理由和处理状态。分类表最简单存分类名称和排序值首页分类导航直接用。4. 核心模块实现商品、订单与权限三条主线的落地细节4.1 商品发布与图片上传商品发布是整个系统里功能最密集的接口涉及字段校验、图片上传、数据入库三步。图片上传这一段有非常多的细节。文件大小建议限制在2MB以内类型限制为jpg、png、webp。存储位置建议用磁盘绝对路径比如/data/images/不要存到项目的target或源码目录下否则每次重新打包上传的图片就全没了。Spring Boot里要把URL路径和磁盘路径关联起来需要实现WebMvcConfigurer的addResourceHandlers方法Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceHandler(file:D:/data/images/); }数据库里存的图片路径不要写绝对路径只存相对路径比如/images/2025/06/01/xxx.jpg。这样以后换服务器、换磁盘代码都不用改只要把文件整体搬过去就行。字段校验一定要做后端校验不要只在前端做提示。前端校验只是为了用户体验后端校验才是最后一道防线。最简单的做法是用Spring的Valid注解配合NotBlank、NotNull再加上几个手动判断比如价格必须大于0、标题不能超过100字。4.2 商品列表的搜索与分页商品列表页需要支持三个维度的组合查询分类筛选、关键词搜索、排序方式。MyBatis-Plus的LambdaQueryWrapper写起来很顺手LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 0) .eq(categoryId ! null, Goods::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Goods::getTitle, keyword) .orderByDesc(price_asc.equals(sort) ? null : Goods::getCreateTime);排序这里有个小细节如果用户选择了按价格升序就orderByAsc(Goods::getSellPrice)否则默认按发布时间倒序。前端把排序参数传过来后端不要直接拼接用户输入的排序字段而是写死几个白名单选项避免注入风险。分页必须配置MyBatis-Plus的PaginationInnerInterceptor这个不配置的话Page对象返回的其实是全量数据这是这个插件最常见的坑。4.3 下单逻辑与事务边界下单接口是体现并发安全意识的核心场景。最安全的做法不是“先查询商品状态再更新”而是用一条条件UPDATE把查询和修改合成一个原子操作在数据库层面防止超卖Transactional(rollbackFor Exception.class) public void createOrder(Long goodsId, Long buyerId) { // 条件更新只有当商品处于在售状态时才能锁定成功 int updated goodsMapper.update(null, new LambdaUpdateWrapperGoods() .set(Goods::getStatus, 1) .eq(Goods::getId, goodsId) .eq(Goods::getStatus, 0)); if (updated 0) { throw new BusinessException(商品已被购买或已下架); } // 创建订单生成唯一订单号 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setGoodsId(goodsId); order.setBuyerId(buyerId); Goods goods goodsMapper.selectById(goodsId); order.setSellerId(goods.getSellerId()); order.setPrice(goods.getSellPrice()); order.setStatus(0); ordersMapper.insert(order); }这个写法很关键updated等于0说明这条UPDATE没有影响到任何行也就意味着商品状态已经不是0了。这样即使是两个用户同时点击购买数据库层面的行锁也只会让其中一个人更新成功另一个人立即失败不会产生两笔订单。事务注解Transactional放在Service层方法上不要放在Controller层。4.4 用户权限与归属校验权限控制用一个登录拦截器就能完成。拦截器里检查Session或Token中是否包含用户信息没有就跳转到登录页或返回401。需要放行的路径包括登录、注册、商品列表、商品详情、分类查询需要拦截的路径包括发布商品、下单、订单列表、个人中心、商品编辑。但登录拦截只是第一步真正的坑在“归属校验”。用户A登录之后绝对不能通过直接改URL参数去修改用户B发布的商品或者把用户B发布的商品标记为已售。所以凡是操作商品、订单的接口Service层里都要先查一次数据校验当前登录用户的id是否等于商品的seller_id或订单的buyer_id/seller_id不一致直接抛业务异常。这块是答辩时老师最常追问的点也是最容易暴露设计漏洞的地方。5. 实测中最容易翻车的几个场景与排查记录5.1 分页插件没配置Page返回全量数据表现前端传page1size10后端返回了表中全部记录total字段也不对。原因MyBatis-Plus的分页功能需要显式配置分页插件没有配置时Page对象不会触发SQL改写查询结果不会拼上LIMIT语句。解决方式Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }这个配置加完之后分页查询才正常。类似的问题还有很多排查方向一般是“第三方增强功能是否在配置类中注册过”。5.2 图片上传成功但访问404表现后端日志显示图片保存成功但浏览器访问URL一直报404。原因图片是保存到本地磁盘的但Spring Boot默认只映射classpath下的静态资源目录不会自动把URL路径映射到磁盘目录。解决方式在配置类里实现WebMvcConfigurer用addResourceHandlers把URL路径映射到磁盘绝对路径。这一步做完图片立即可访问。这里还要补一个经验Windows路径是反斜杠file:D:/data/images/Linux是正斜杠file:/data/images/写配置时如果要在两个环境切换最好用File.separator拼接路径或者把路径放到application.yml里按环境配置。5.3 并发下单导致同一件商品被卖两次表现两个用户几乎同时点击“立即购买”数据库里生成了两笔订单。原因初版代码是先SELECT商品状态再UPDATE商品状态两个操作之间存在时间差。并发状况下两个请求都读到了“在售中”然后都走了下单逻辑。解决方式改成前面提到的条件UPDATE写法把“检查状态”和“修改状态”合并成一个原子操作配合事务问题就彻底解决了。这个思路在秒杀、抢购类系统里是通用的只是实现复杂度不同。5.4 事务不生效数据写了一半表现方法里先插入订单再更新商品状态第二个步骤故意抛异常结果订单还是被写进数据库了。排查顺序很重要按下面这个顺序逐一确认方法是不是publicTransactional在private方法上不生效这是Spring代理机制决定的。事务方法是不是被同类内部调用同类里this.method()直接调用不会走Spring代理事务会失效。要自调用时可以把逻辑拆到另一个Service类或者用AopContext.currentProxy()。异常是不是被catch掉了事务方法里catch住异常不抛出事务管理器感知不到异常自然不回滚。正确做法是catch后手动抛RuntimeException或标记rollback。数据库引擎是不是MyISAMMyISAM不支持事务必须用InnoDB。有没有指定rollbackForSpring默认只在抛出RuntimeException时回滚如果业务抛的是自定义Exception需要显式声明Transactional(rollbackFor Exception.class)。这五个原因覆盖了绝大多数“事务好像没生效”的场景按顺序排查基本不会漏。6. 从能跑到好演示答辩前值得做好的几件小事6.1 准备一套像样的演示数据空数据库演示的效果非常差老师一眼就能看出系统从没真正用过。建议提前导入20到30条有真实感的商品数据二手教材、自行车、洗衣机、耳机、台灯、篮球每条都有封面图、价格、描述、成色、交易地点。有一个隐藏的细节演示前把当前用户切换成一个“卖家身份”提前准备好“我发布的商品”列表里有商品的状态。演示下单流程时先在自己发布的商品里选一件下单再把另一端的买家账号打开整个过程就完整顺滑了。不要现场注册、现场发布、现场拍图十有八九会卡在图片上传上。6.2 值得投入的几个高性价比扩展一是管理员后台不需要做得很复杂用户管理、商品管理、举报处理三块就够了一张管理员的表加上一个独立的MVC模块就能撑起来但对项目的完整度提升非常明显。二是管理员上下架商品时用AOP记录操作日志展示时可以说“系统具备操作审计能力”。三是在商品详情页增加浏览记录用一张简单的表记录用户和商品的浏览关系最近浏览列表可以放在个人中心。四是在代码里用Hutool这样的工具类库简化日期、ID生成、图片处理等重复代码答辩时提一句“使用了主流工具库提升开发效率”也是加分的。最后再分享一个小体会做这个项目最大的收获不是“我会用Spring Boot了”这句话而是真正理解了把一个功能完整落地需要思考多少细节。框架的用法看几遍文档就能上手但“商品状态流转的边界条件”“并发下为什么不能先查再改”“事务在什么情况下会失效”这些问题是背八股文背不出来的。如果你能把这个项目从头到尾走一遍并且能在答辩时把每一个“为什么这么做”讲清楚那这个毕业设计的价值就真正到位了。本文还有配套的精品资源点击获取 基于Spring Boot的校园二手交易平台：从数据库设计到并发下单实战
简介基于Java的校园二手交易平台设计与实现文档是一份面向计算机专业毕业生、Java Web开发学习者及毕业设计团队的完整项目设计参考重点解决校园二手商品在线交易系统的需求分析、架构设计与功能落地等问题。内容围绕SSMSpring、SpringMVC、MyBatis、Vue和MySQL的整合方案展开详细设计了管理员、普通用户、商家三类角色及其权限边界覆盖商品发布与审核、商品查询、购物车管理、订单管理、个人中心等核心模块并结合Java跨平台、Vue组件化、MySQL稳定支撑等特性阐述了具体的技术选型理由。包内共1个docx文件压缩包大小约3.45MB从内容预览可见其包含摘要、关键词、目录、绪论、系统分析等完整章节适合直接阅读与参考。目前已有33人学习下载。读者可从中获取课题背景分析、系统业务流程梳理、功能模块设计、数据库设计思路以及后期实现要点为毕业设计选题、论文框架搭建或校园交易类项目开发提供有效支持。 每年到毕业设计开题季总有一批同学拿着同一个问题来找我“Java学了SSM、Spring BootMySQL也会写但让我从零做一个完整项目我真的不知道第一步该干什么。”这种情况我一般会推荐校园二手交易平台这个选题。它不是我拍脑袋想出来的而是我前前后后指导、参与过好几个完整版本的Java Web项目之后认定最稳的一个方案。这个题目基于Java和Spring Boot这套主流技术栈业务上有完整的闭环规模又不会大到一个人做不完非常适合当作毕业设计或课程设计的项目主体。它的核心是把校园里闲置物品的流转——发布、浏览、搜索、购买、下单、确认交易——用一套完整的设计和实现落地成一个能运行、能演示的Web系统。这篇文章我就把这个项目的完整开发过程拆开讲一遍包含技术选型逻辑、数据库建模思路、核心模块的落地方式以及我在实际开发中踩过的那些坑。下面按我做这个项目的实际思路来写希望给正打算做这个题目的人一条可以直接参考的路线也帮你能在答辩时把“为什么这么设计”讲清楚。1. 为什么校园二手交易平台是Java项目里最值得做的“样板工程”1.1 业务闭环完整覆盖Java Web开发的核心知识点很多项目做完你会发现除了CRUD还是CRUD展示的时候很单薄。二手交易平台不一样它天然带着一整套业务状态和交互逻辑用户要注册、登录、修改资料商品要发布、修改、下架、被购买订单要创建、确认、完成、取消再加上收藏、留言、举报这些辅助功能一条链路走下来你会自然接触到权限控制、数据校验、状态流转、事务管理、文件上传、分页查询这些几乎所有Java Web开发都会用到的知识点。这套知识点不算复杂但足够完整。答辩时老师问“你这个项目涉及哪些技术”你几乎可以把Java开发的核心内容全部理一遍而且每一项都有真实的业务落点不是背出来的概念。1.2 校园场景比通用电商更容易做减法也更适合单人开发如果你照着淘宝、京东的思路去做电商系统很容易把自己劝退——优惠券、购物车、秒杀、分销、售后、物流跟踪随便一个模块都够写半个月。但把场景缩小到校园一切都可以做合理的减法。交易发生在同一个校区内买家卖家基本都是学生现货现款、当面交易是主流。物流、退款、多级分销这些复杂场景完全可以简化成“双方线下确认完成”。这个“做减法”的过程本身就是设计能力的体现。老师不会觉得你能力不足反而会认可你做了合理的需求取舍。校园二手交易平台是这个选题最大的优势有电商的味道但不用背电商系统的复杂度包袱。1.3 功能清单做一个什么程度的版本算“合格”根据不同学校的要求我把功能分成基础版和加分版两个档位。基础版至少要包含这些功能用户注册与登录、商品发布与图片上传、商品列表与分类筛选、关键词搜索、商品详情、收藏与取消收藏、下单购买、订单列表我买到的/我卖出的、确认交易、下架商品。加分版可以再加管理员后台用户管理、商品审核、举报处理、站内留言私信、个人主页展示、浏览记录、数据统计。建议先把基础版跑通再根据时间余量做加分项不要一上来就想做全功能。2. 技术选型与工程初始化不是越新越好而是越稳越好2.1 为什么是Spring Boot MyBatis-Plus MySQL这三件套基本是当下Java后端项目的默认组合。Spring Boot把Spring MVC、Tomcat、Jackson、参数校验等大量组件的配置都自动处理了打成一个JAR包就能启动比传统的SSMSpring Spring MVC MyBatis少写一大堆XML配置也更贴近现在企业的真实开发方式。MyBatis-Plus是MyBatis的增强工具它提供的BaseMapper已经内置了单表CRUD不需要为每张表手写insert、update、delete、selectById这些重复方法。它还带条件构造器LambdaQueryWrapper写复杂查询时比手拼SQL直观得多。MySQL用8.x版本建库时指定utf8mb4字符集。这一点特别提醒商品描述和留言内容里很可能出现Emoji表情utf8mb3也就是常说的utf8是存不下的跑起来会报“Incorrect string value”错误utf8mb4才能完整支持。2.2 前端方案Thymeleaf还是Vue这个选择题没有标准答案取决于你想把重点放在哪里。方案AThymeleaf Bootstrap后端渲染一个人维护一套代码部署简单适合把重心放在Java后端的场景。方案BVue3 Element-Plus前后端分离前端工程和后端工程分开部署交互体验更好适合想同时展示前端能力的同学。我的建议是如果毕业设计定位是Java后端方向用Thymeleaf完全足够还能省掉跨域、Token刷新、前后端联调这些额外工作。如果选了Vue就要接受工作量会多出不少。不要为了“听起来新”强行上微服务、Redis集群、MQ这些重型组件除非你有把握应对答辩时的连环追问。2.3 项目目录与基础配置推荐按技术层分包这种方式最容易讲清楚也最常规com.example.campus ├── controller // 控制层接收请求 ├── service // 业务层事务在这里控制 ├── mapper // 数据访问层继承BaseMapper ├── entity // 实体类与表对应 ├── common // 通用类返回结果、异常处理、常量 └── config // 配置类拦截器、资源映射、分页插件开工前先把三件事做好统一返回结果类、全局异常处理器、CORS跨域配置如果前后端分离。尤其是全局异常处理用RestControllerAdvice把业务异常和系统异常统一包装返回后面写代码时Controller层会很干净这也是很多新手一开始容易忽略但后续收益最大的配置。3. 数据库设计状态机没想清楚之前先别急着建表3.1 核心表字段的取舍我做这个项目时一共设计了8张表核心的是三张用户表、商品表、订单表。下面这张表是字段的参考版本-- 用户表 CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL COMMENT BCrypt加密存储, nickname VARCHAR(50) DEFAULT NULL, student_no VARCHAR(20) DEFAULT NULL COMMENT 学号, phone VARCHAR(20) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 商品表 CREATE TABLE goods ( id BIGINT AUTO_INCREMENT PRIMARY KEY, seller_id BIGINT NOT NULL, category_id BIGINT DEFAULT NULL, title VARCHAR(100) NOT NULL, description TEXT, cover VARCHAR(255) DEFAULT NULL COMMENT 封面图, images VARCHAR(1000) DEFAULT NULL COMMENT 多图逗号分隔, original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原价, sell_price DECIMAL(10,2) NOT NULL COMMENT 售价, condition_level TINYINT DEFAULT NULL COMMENT 成色5成到全新, trading_location VARCHAR(100) DEFAULT NULL COMMENT 交易地点, status TINYINT NOT NULL DEFAULT 0 COMMENT 0在售 1锁定 2已售 3下架, view_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 订单表 CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, goods_id BIGINT NOT NULL, buyer_id BIGINT NOT NULL, seller_id BIGINT NOT NULL, price DECIMAL(10,2) NOT NULL COMMENT 成交价快照, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待确认 1待交易 2已完成 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME DEFAULT NULL, finish_time DATETIME DEFAULT NULL );3.2 三个容易被忽略的设计细节第一订单表里必须单独存一份price不能下单时去查商品表取价格。因为商品价格后续可能被卖家修改订单必须保留下单那一刻的价格快照否则等交易完成后对不上账。第二金额类型用DECIMAL不用double或float。浮点数在二进制里本身就不精确算钱会出大问题。第三建议不建物理外键逻辑外键就够了。物理外键在分页查询、批量删除时会带来额外开销而且经常会出现“想删一条父表数据删不掉”的尴尬情况。实体之间通过业务代码保证一致性这也是当前项目开发里的主流做法。3.3 商品和订单的状态机设计商品状态我用的是这套0 在售中 - 1 已被下单(锁定) - 2 已售出 0 在售中 - 3 卖家主动下架 0 在售中 - 4 管理员下架这里最关键的是“1 已被下单”这个锁定状态。同一件商品不能被两个人同时下单所以商品从0变成1之后其他人可以浏览但不能下单只有当前订单取消或异常回滚时商品才回到0。这个设计是整个系统里最容易出错的地方很多初版实现就是漏了它才会出现同一本书被两个人买走的线上事故。订单状态我用的是这套0 待确认 - 1 待交易(约时间地点) - 2 已完成 0 待确认 - 3 已取消 1 待交易 - 3 已取消校园场景下订单不需要区分待付款、待发货、待收货那么细状态太多反而让流程显得冗长。买家下单后先处于待确认卖家看到订单即可联系买家约时间地点面交当面交易完成后订单确认完成这个状态流转足够覆盖校园二手交易的真实流程。3.4 辅助表辅助表有收藏表、留言表、举报表、分类表。收藏表一定要给user_id和goods_id加联合唯一索引否则用户点两下收藏按钮就插入两条记录这属于典型的数据重复。留言表是商品详情页的评论区字段包括商品id、发送人、接收人、内容、时间。举报表服务于管理员的审核功能记录举报理由和处理状态。分类表最简单存分类名称和排序值首页分类导航直接用。4. 核心模块实现商品、订单与权限三条主线的落地细节4.1 商品发布与图片上传商品发布是整个系统里功能最密集的接口涉及字段校验、图片上传、数据入库三步。图片上传这一段有非常多的细节。文件大小建议限制在2MB以内类型限制为jpg、png、webp。存储位置建议用磁盘绝对路径比如/data/images/不要存到项目的target或源码目录下否则每次重新打包上传的图片就全没了。Spring Boot里要把URL路径和磁盘路径关联起来需要实现WebMvcConfigurer的addResourceHandlers方法Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceHandler(file:D:/data/images/); }数据库里存的图片路径不要写绝对路径只存相对路径比如/images/2025/06/01/xxx.jpg。这样以后换服务器、换磁盘代码都不用改只要把文件整体搬过去就行。字段校验一定要做后端校验不要只在前端做提示。前端校验只是为了用户体验后端校验才是最后一道防线。最简单的做法是用Spring的Valid注解配合NotBlank、NotNull再加上几个手动判断比如价格必须大于0、标题不能超过100字。4.2 商品列表的搜索与分页商品列表页需要支持三个维度的组合查询分类筛选、关键词搜索、排序方式。MyBatis-Plus的LambdaQueryWrapper写起来很顺手LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 0) .eq(categoryId ! null, Goods::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Goods::getTitle, keyword) .orderByDesc(price_asc.equals(sort) ? null : Goods::getCreateTime);排序这里有个小细节如果用户选择了按价格升序就orderByAsc(Goods::getSellPrice)否则默认按发布时间倒序。前端把排序参数传过来后端不要直接拼接用户输入的排序字段而是写死几个白名单选项避免注入风险。分页必须配置MyBatis-Plus的PaginationInnerInterceptor这个不配置的话Page对象返回的其实是全量数据这是这个插件最常见的坑。4.3 下单逻辑与事务边界下单接口是体现并发安全意识的核心场景。最安全的做法不是“先查询商品状态再更新”而是用一条条件UPDATE把查询和修改合成一个原子操作在数据库层面防止超卖Transactional(rollbackFor Exception.class) public void createOrder(Long goodsId, Long buyerId) { // 条件更新只有当商品处于在售状态时才能锁定成功 int updated goodsMapper.update(null, new LambdaUpdateWrapperGoods() .set(Goods::getStatus, 1) .eq(Goods::getId, goodsId) .eq(Goods::getStatus, 0)); if (updated 0) { throw new BusinessException(商品已被购买或已下架); } // 创建订单生成唯一订单号 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setGoodsId(goodsId); order.setBuyerId(buyerId); Goods goods goodsMapper.selectById(goodsId); order.setSellerId(goods.getSellerId()); order.setPrice(goods.getSellPrice()); order.setStatus(0); ordersMapper.insert(order); }这个写法很关键updated等于0说明这条UPDATE没有影响到任何行也就意味着商品状态已经不是0了。这样即使是两个用户同时点击购买数据库层面的行锁也只会让其中一个人更新成功另一个人立即失败不会产生两笔订单。事务注解Transactional放在Service层方法上不要放在Controller层。4.4 用户权限与归属校验权限控制用一个登录拦截器就能完成。拦截器里检查Session或Token中是否包含用户信息没有就跳转到登录页或返回401。需要放行的路径包括登录、注册、商品列表、商品详情、分类查询需要拦截的路径包括发布商品、下单、订单列表、个人中心、商品编辑。但登录拦截只是第一步真正的坑在“归属校验”。用户A登录之后绝对不能通过直接改URL参数去修改用户B发布的商品或者把用户B发布的商品标记为已售。所以凡是操作商品、订单的接口Service层里都要先查一次数据校验当前登录用户的id是否等于商品的seller_id或订单的buyer_id/seller_id不一致直接抛业务异常。这块是答辩时老师最常追问的点也是最容易暴露设计漏洞的地方。5. 实测中最容易翻车的几个场景与排查记录5.1 分页插件没配置Page返回全量数据表现前端传page1size10后端返回了表中全部记录total字段也不对。原因MyBatis-Plus的分页功能需要显式配置分页插件没有配置时Page对象不会触发SQL改写查询结果不会拼上LIMIT语句。解决方式Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }这个配置加完之后分页查询才正常。类似的问题还有很多排查方向一般是“第三方增强功能是否在配置类中注册过”。5.2 图片上传成功但访问404表现后端日志显示图片保存成功但浏览器访问URL一直报404。原因图片是保存到本地磁盘的但Spring Boot默认只映射classpath下的静态资源目录不会自动把URL路径映射到磁盘目录。解决方式在配置类里实现WebMvcConfigurer用addResourceHandlers把URL路径映射到磁盘绝对路径。这一步做完图片立即可访问。这里还要补一个经验Windows路径是反斜杠file:D:/data/images/Linux是正斜杠file:/data/images/写配置时如果要在两个环境切换最好用File.separator拼接路径或者把路径放到application.yml里按环境配置。5.3 并发下单导致同一件商品被卖两次表现两个用户几乎同时点击“立即购买”数据库里生成了两笔订单。原因初版代码是先SELECT商品状态再UPDATE商品状态两个操作之间存在时间差。并发状况下两个请求都读到了“在售中”然后都走了下单逻辑。解决方式改成前面提到的条件UPDATE写法把“检查状态”和“修改状态”合并成一个原子操作配合事务问题就彻底解决了。这个思路在秒杀、抢购类系统里是通用的只是实现复杂度不同。5.4 事务不生效数据写了一半表现方法里先插入订单再更新商品状态第二个步骤故意抛异常结果订单还是被写进数据库了。排查顺序很重要按下面这个顺序逐一确认方法是不是publicTransactional在private方法上不生效这是Spring代理机制决定的。事务方法是不是被同类内部调用同类里this.method()直接调用不会走Spring代理事务会失效。要自调用时可以把逻辑拆到另一个Service类或者用AopContext.currentProxy()。异常是不是被catch掉了事务方法里catch住异常不抛出事务管理器感知不到异常自然不回滚。正确做法是catch后手动抛RuntimeException或标记rollback。数据库引擎是不是MyISAMMyISAM不支持事务必须用InnoDB。有没有指定rollbackForSpring默认只在抛出RuntimeException时回滚如果业务抛的是自定义Exception需要显式声明Transactional(rollbackFor Exception.class)。这五个原因覆盖了绝大多数“事务好像没生效”的场景按顺序排查基本不会漏。6. 从能跑到好演示答辩前值得做好的几件小事6.1 准备一套像样的演示数据空数据库演示的效果非常差老师一眼就能看出系统从没真正用过。建议提前导入20到30条有真实感的商品数据二手教材、自行车、洗衣机、耳机、台灯、篮球每条都有封面图、价格、描述、成色、交易地点。有一个隐藏的细节演示前把当前用户切换成一个“卖家身份”提前准备好“我发布的商品”列表里有商品的状态。演示下单流程时先在自己发布的商品里选一件下单再把另一端的买家账号打开整个过程就完整顺滑了。不要现场注册、现场发布、现场拍图十有八九会卡在图片上传上。6.2 值得投入的几个高性价比扩展一是管理员后台不需要做得很复杂用户管理、商品管理、举报处理三块就够了一张管理员的表加上一个独立的MVC模块就能撑起来但对项目的完整度提升非常明显。二是管理员上下架商品时用AOP记录操作日志展示时可以说“系统具备操作审计能力”。三是在商品详情页增加浏览记录用一张简单的表记录用户和商品的浏览关系最近浏览列表可以放在个人中心。四是在代码里用Hutool这样的工具类库简化日期、ID生成、图片处理等重复代码答辩时提一句“使用了主流工具库提升开发效率”也是加分的。最后再分享一个小体会做这个项目最大的收获不是“我会用Spring Boot了”这句话而是真正理解了把一个功能完整落地需要思考多少细节。框架的用法看几遍文档就能上手但“商品状态流转的边界条件”“并发下为什么不能先查再改”“事务在什么情况下会失效”这些问题是背八股文背不出来的。如果你能把这个项目从头到尾走一遍并且能在答辩时把每一个“为什么这么做”讲清楚那这个毕业设计的价值就真正到位了。本文还有配套的精品资源点击获取