Spring Boot二手交易系统源码解析：从CRUD到状态机实战

简介一套基于Spring Boot的二手交易系统完整源码包面向Java初学者、毕业设计学生以及需要快速搭建电商交易类项目的开发者覆盖商品管理、用户管理、订单管理和留言管理四大核心模块支持JWT登录鉴权、分页查询、商品分类、订单状态流转等典型业务场景。压缩包共138个文件以Java源码31个java文件与编译后class文件、Vue前端组件18个vue、XML映射与配置、docx说明文档、JS/CSS/HTML静态资源为主整体约4.05MB目录结构清晰易检索。资源内含12份Word文档可辅助梳理数据库设计、接口调用与部署流程。目前已有65人学习浏览适合用来研究Spring Boot分层架构、RESTful API设计、JWT认证实现及前后端分离项目的完整落地过程下载后可直接导入开发工具运行并按模块研读、二次开发。 说实话我一开始看到基于Spring Boot的二手交易系统这种源码zip第一反应是又是个老掉牙的CRUD项目。但真的把压缩包解开、把代码一行行过完之后我发现这类项目的价值被严重低估了。它表面上是商品上架、下单、订单管理这些基础功能实际上把Web后端最经典的那些东西全串起来了用户认证、文件上传、分页检索、事务控制、状态机流转、越权防护。如果你正打算做毕业设计、课程设计或者只想用一个完整项目把Spring Boot从入门到实战走一遍这套源码的拆解思路是很好的参照。这个系统的业务定位很清晰买卖双方各有一个入口卖家发布闲置商品买家浏览、搜索、收藏、下单双方通过订单状态推进交易流程。技术上没有堆砌微服务和中间件就是Spring Boot MyBatis-Plus MySQL 标准Maven结构前后端不分离静态页面直接由Spring Boot托管。这种选型让源码的可读性很高跟着下面的内容走你不仅能跑起来还能搞清楚每一步到底为什么这么设计。1. 为什么要做一个二手交易系统以及我选型时考虑的事1.1 场景痛点与功能定位二手交易这个场景太适合当练手项目了。你可以代入校园或社区场景想想毕业季的教材、考研资料、小电器搬家带不走扔了可惜买家想低价捡漏卖家想快速回血。这些需求天然就需要一个平台来撮合。和标准电商比二手交易系统少了很多包袱比如不需要复杂的SKU库存管理、不需要对接真实支付网关、不需要物流轨迹跟踪核心就是一个信息发布 交易撮合 状态管理的闭环。基于这个定位这个系统的功能边界很明确用户端注册、登录、个人中心、我的发布、我的购买、我的收藏商品端发布闲置、编辑/下架商品、图片上传、分类浏览、关键词搜索、商品详情交易端收藏意向、加入购物车、下单、取消订单、确认收货管理端用户管理、商品审核/下架、分类管理如果你拿到的源码版本里缺了某一项别急着抱怨自己补上去就是最好的练习。比如管理后台没有做你就用Spring Boot Thymeleaf写个简单的admin模块整个系统的完整性立刻上一个台阶。1.2 技术栈选型的取舍为什么这套系统用Spring Boot而不是Spring Cloud为什么用MyBatis-Plus而不是JPA为什么连Redis都没上这些选型问题在面试里经常被问本质上是在考你是否理解技术的适用边界。对于二手交易这种单体应用最合理的技术栈是这样的Spring Boot 2.7.x稳定、资料多、和JDK 8/11都能配合社区遇到问题一搜就有答案MyBatis-Plus单表CRUD几乎不用写XMLLambdaQueryWrapper做动态条件查询非常顺手比原生MyBatis省一半代码量MySQL 5.7或8.0开源数据库复杂度和系统匹配度刚好SQL也能直观地排查MavenOne依赖、构建、打包一把梭前端Bootstrap或原生Thymeleaf模板不搞前后端分离减少跨域和部署的复杂度至于Redis、Spring Security、消息队列这些东西我的观点很明确等核心跑通了再往上加。直接套一堆中间件初学者很容易被缓存一致性、分布式事务、权限框架的过滤器链淹没最后连业务主线都看不清。这套源码保持够用但不过度设计的调性恰恰是它适合学习的原因。2. 数据库设计交易系统的命门在状态字段怎么设计2.1 表结构总览数据库设计决定了一个项目的天花板。很多跑不起来的源码问题不在代码而在建表脚本和代码里的字段对不上。这套系统的核心表大致如下表名职责关键字段user用户表id、username、password、nickname、avatar、phonecategory商品分类表id、name、sortgoods商品表id、user_id、category_id、title、description、price、cover、status、view_countgoods_image商品图片表id、goods_id、image_urlcart购物车/收藏表id、user_id、goods_id、typeorders订单表id、order_no、goods_id、buyer_id、seller_id、price、statusmessage留言表id、goods_id、from_user_id、to_user_id、content要注意用户表和商品表之间、商品表和订单表之间用的是逻辑关联而不是物理外键。我给新手一句忠告别建物理外键。外键约束在数据库层面强制一致性确实很安全但高并发插入、更新时会产生额外的锁竞争而且很多团队在拆分库表时会发现外键是巨大的迁移阻碍。在这个系统里通过Service层的事务来保证关联数据的一致性就足够了。2.2 商品表和订单表的状态设计这是整个数据库设计里最值得细看的部分。商品表里的status字段如果你定义为0上架、1下架这种布尔语义后面一定会后悔。二手商品的生命周期比这复杂得多0草稿/待审核1上架中可被搜索和购买2已售出/锁定中有人下单但交易未完成3已下架卖家主动下架订单表的状态也要想清楚。二手系统不接在线支付很多流程是线下转账或当面交易所以订单状态简化成一条清晰的时间线状态值含义说明0待处理买家下单后等待卖家接单1交易中卖家确认双方进入线下对接2待收货卖家标记已发货3已完成买家确认收货交易闭环4已取消任意一方在未完成前取消这里的关键是状态的每一次变化都要有对应的时间字段比如pay_time、deliver_time、finish_time、cancel_time。哪怕暂时用不到也留出来。因为这些时间字段在将来做订单超时关闭、交易数据统计时全都会用到到时候缺字段的日子可不好过。2.3 索引与常用查询建表时顺手把索引建好省得后期数据量上来再回头加。这套系统的核心查询路径其实很固定商品列表页按分类状态筛选并按时间排序订单页按用户查询后台按状态统计。所以至少要有这些索引goods 表idx_category_id、idx_status、idx_create_timeorders 表idx_buyer_id、idx_seller_id、idx_status再强调一点所有表的id都用BIGINT自增主键create_time和update_time统一用datetime类型。MyBatis-Plus里用自动填充功能维护这两个时间字段比手动new Date()要优雅也靠谱得多。3. 商品发布与检索核心接口实现与常见返工点3.1 发布商品的服务层实现商品发布看起来就是填个表单点个提交但落到底层是插入商品主表 批量插入多张图片两个操作。这两个操作必须在一个事务里否则就会出现商品插进去了、图片批量写入中途报错最终产出一条没有图的残疾商品。Service层的代码骨架大致是这样Transactional(rollbackFor Exception.class) public Long publishGoods(GoodsPublishDTO dto, Long userId) { Goods goods new Goods(); goods.setUserId(userId); goods.setCategoryId(dto.getCategoryId()); goods.setTitle(dto.getTitle()); goods.setDescription(dto.getDescription()); goods.setPrice(dto.getPrice()); goods.setCover(dto.getImages().get(0)); goods.setStatus(1); goods.setViewCount(0); goodsMapper.insert(goods); if (CollectionUtils.isNotEmpty(dto.getImages())) { ListGoodsImage imageList dto.getImages().stream() .map(url - new GoodsImage(goods.getId(), url)) .collect(Collectors.toList()); goodsImageMapper.batchInsert(imageList); } return goods.getId(); }注意我用了Transactional(rollbackFor Exception.class)而不是默认的Transactional。原因是Spring默认只在RuntimeException抛出时回滚如果你自定义了受检异常或业务异常不加rollbackFor就可能导致事务不生效。这类细节是踩坑高发区必须养成习惯。3.2 图片上传与静态资源映射图片上传的坑比大多数人想象的多。上传本身很简单——接收MultipartFile写到一个目录把访问路径存到数据库。核心代码如下String ext StringUtils.getFilenameExtension(file.getOriginalFilename()); String filename UUID.randomUUID().toString().replace(-, ) . ext; String datePath new SimpleDateFormat(yyyyMMdd).format(new Date()); File dir new File(imageRootDir, datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, filename)); return /upload/ datePath / filename;但很多人在本地IDEA里跑得好好的一部署到Linux服务器图片就全裂了。原因基本都一样路径问题。Windows下用D:\这种绝对路径Linux下没这个盘符必挂。所以图片根目录image-root-dir一定要配置在yml里image-root-dir: /var/www/upload spring: mvc: static-path-pattern: /** resources: static-locations: classpath:/static/,file:${image-root-dir}/还要记得在配置类或配置文件中设置上传大小限制不然用户传一个50MB的图片Tomcat直接报错spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB3.3 商品检索分页、筛选与排序商品列表是这个系统访问量最大的接口。用MyBatis-Plus的LambdaQueryWrapper做动态条件组合非常舒服LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 1); if (StringUtils.hasText(keyword)) { wrapper.and(w - w.like(Goods::getTitle, keyword) .or().like(Goods::getDescription, keyword)); } if (categoryId ! null) { wrapper.eq(Goods::getCategoryId, categoryId); } wrapper.orderByDesc(Goods::getCreateTime); PageGoods page goodsMapper.selectPage(new Page(pageNum, pageSize), wrapper);对于几万条商品的中小规模系统这种LIKE模糊查询完全够用。但有一点要注意分页参数永远不要用前端传过来的偏移量直接拼SQL。MyBatis-Plus的分页插件已经帮你把防SQL注入的边界处理好了你只要把pageNum和pageSize校验一下最大值比如pageSize最多100别让恶意调用一次拖走全库就行。3.4 浏览量的并发更新商品详情页要请求量1。很多人第一反应是先查出来再1再更新回去。这是大忌// 错误示范 Goods goods goodsMapper.selectById(id); goods.setViewCount(goods.getViewCount() 1); goodsMapper.updateById(goods);两个人同时点击时后一个的更新会覆盖前一个浏览量直接丢更新。正确做法是一条UPDATE语句搞定UPDATE goods SET view_count view_count 1 WHERE id ?没有中间读取数据库的行锁保证原子递增性能和正确性都兼顾了。4. 订单交易链路状态机比接口更值得先想清楚4.1 从商品浏览到订单的转化路径订单模块是二手系统最核心也最容易出bug的地方。它的复杂不在于代码多而在于各种状态组合太多。我建议你写代码之前先在白纸上把状态流转图画出来把所有可能的路径列一遍。在这个系统里用户下单主要走两条路一种是用户从商品详情页点直接购买一种是从购物车里勾选多件商品结算。不管哪条路最终落到后端都是同一个核心方法创建订单。截取核心逻辑Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long goodsId, Long buyerId) { Goods goods goodsMapper.selectById(goodsId); if (goods null || goods.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } if (goods.getUserId().equals(buyerId)) { throw new BizException(不能购买自己发布的商品); } // 条件更新CAS的思想 int rows goodsMapper.lockOnSale(goodsId); if (rows 0) { throw new BizException(手慢了商品已被拍下); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setGoodsId(goodsId); order.setBuyerId(buyerId); order.setSellerId(goods.getUserId()); order.setPrice(goods.getPrice()); order.setStatus(0); orderMapper.insert(order); return OrderVO.of(order); }这里最关键的代码是lockOnSale它在XML里对应的SQL是UPDATE goods SET status 2 WHERE id #{id} AND status 1这种条件更新本质上就是乐观锁。数据库的UPDATE操作本身会对命中行加锁只要返回值是0就说明商品在并发场景下已经被别人抢先下单了。不加这一步两个人同时点购买两个事务都从status1查到了商品就会把同一件商品卖两次。这是二手系统必须有的兜底机制。4.2 订单状态流转矩阵订单状态不是随便改的每一条路径都必须有明确的触发动作和校验逻辑。把流转矩阵列清楚后面写代码时照着抄当前状态触发动作目标状态操作人前置校验0 待处理卖家接单1 交易中卖家卖家必须为商品owner0 待处理买家取消4 已取消买家无1 交易中卖家标记发货2 待收货卖家无2 待收货买家确认收货3 已完成买家无1 交易中取消4 已取消双方协商一致后操作所有状态流转代码都要使用条件更新的方式比如确认收货的SQLUPDATE orders SET status 3, finish_time NOW() WHERE id #{id} AND status 2如果受影响行数为0就说明当前状态根本不是待收货可能是重复提交或者状态已经被改过。用这种方式整个系统的订单状态永远不可能被非法路径跳到错误位置。4.3 事务边界要注意的事下单方法必须加事务这个不用说。但我要提醒一个容易被忽视的问题事务方法内部千万别做耗时操作。比如下单后要发短信通知卖家、要调用第三方接口这些都别塞在同一个事务里。原因很简单数据库事务连接是稀缺资源你把远程调用放在事务中间等于一直占着连接等外部响应并发一高连接池就耗尽。正确做法是只做数据库操作然后通过异步方式比如Spring的事件机制或简单的线程池去发通知。对于二手系统直接用Async异步发通知就够了没必要上MQ。5. 后端安全与防刷登录鉴权与越权操作5.1 密码存储与登录态方案先说密码。如果你看到源码里用户表的密码字段是明文的请务必改掉这是最基本的底线。Spring Security里自带的BCryptPasswordEncoder就能用// 注册时加密 String encoded new BCryptPasswordEncoder().encode(rawPassword); // 登录时校验 boolean matches encoder.matches(rawPassword, user.getPassword());BCrypt的特点是不用你自己加盐每次加密生成的哈希串都不同即使两个用户密码相同数据库里存的也不一样暴力破解的成本高很多。登录态用什么这套源码如果跑前后端不分离直接用Session是成本最低的方案。登录成功之后把用户ID放进Session再写一个拦截器统一校验public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getSession().getAttribute(loginUser) null) { response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\请先登录\}); return false; } return true; } }然后把需要登录才能访问的路径注册进拦截器注意要放行登录注册接口和静态资源。5.2 越权操作最容易被忽略的漏洞我见过太多二手交易源码在权限校验上形同虚设。典型例子修改商品接口只接收一个goodsId不管这个商品是谁发的登录用户传谁都能改。这是非常严重的越权漏洞属于水平越权。正确的做法是在操作前先查出goods校验goods.getUserId()和当前登录用户是否一致Goods goods goodsMapper.selectById(goodsId); if (goods null || !goods.getUserId().equals(currentUserId)) { throw new BizException(无权操作该商品); }订单操作同理。买家只能取消自己的订单卖家只能对自己的商品订单发货所有操作都要在Service层做一遍归属校验不要依赖前端按钮的显隐。5.3 防止重复提交与基本防刷用户在支付或下单时双击按钮前端可以做按钮置灰但后端必须兜底。最简单可靠的方案就是用状态字段做幂等就像前面说的条件更新第二次点击时状态已经不是待处理直接被拒绝。注册接口和商品发布接口还需要防刷。不用做得很复杂几个低成本手段就够用同一IP一段时间内注册次数限制记录到本地缓存商品发布频率限制比如一分钟最多发3条上传接口严格限制文件类型和后缀防止脚本传个JSP或恶意文件这些逻辑写在拦截器或切面里都行代码量不大但能让系统的健壮性上升一个档次。6. 源码导入运行全流程与常见踩坑6.1 拿到zip后先看什么从网上下载的源码包解压后我强烈建议不要急着双击IDEA打开先把这几样东西确认了pom.xml确认JDK版本、Spring Boot版本、依赖完整性src/main/resources/application.yml确认数据源、端口、上传路径配置数据库初始化SQL确认编码、结构完整然后按这个顺序操作创建数据库 - 导入SQL - 修改application.yml - 启动项目 - 访问首页。只要这条主链路通了立刻就能跑起来。数据库连接配置是重灾区MySQL 8.0的配置要写成这样spring: datasource: url: jdbc:mysql://localhost:3306/second_hand?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver一定不要漏掉characterEncodingutf8和serverTimezoneAsia/Shanghai。少了前者中文乱码少了后者MySQL 8.0直接报时区错误。6.2 Maven构建与启动命令源码拿到手构建打包用这几条命令就够# 开发模式直接跑 mvn spring-boot:run # 打包后运行 mvn clean package -DskipTests java -jar target/second-hand-0.0.1-SNAPSHOT.jar如果本机没装Maven用IDEA右侧的Maven面板直接点clean和package也可以。第一次跑会自动下载依赖网络不好容易卡在下载阶段多试几次或者换个国内镜像源就好。6.3 运行期高频报错速查我把这个项目运行期间最高频的报错整理一下基本覆盖80%的情况报错现象原因解决办法启动即报端口占用8080被其他程序占用改server.port或杀进程访问登录页JS/CSS全挂静态资源路径配置错误检查static-path-pattern和存放目录图片上传后不显示路径是Linux绝对路径但目录不存在检查image-root-dir指向的目录是否有权限数据库中文乱码连接串没配characterEncoding按上面的连接串补上打印SQL显示问号控制台编码不对IDEA设置里把File Encoding调成UTF-8Maven下载依赖中断网络问题给Maven配置阿里云镜像6.4 二次开发建议跑通只是第一步。如果你想用这套源码做毕业设计或作品集我建议你往这几个方向做一点增量开发性价比很高一是把项目改成Maven多模块结构拆出common、system、goods、order几个模块架构上马上看起来专业一个档次二是给热门商品加Redis缓存商品列表的响应速度立刻有感知提升三是如果想让系统更像真实产品就把聊天功能做了二手交易里买卖双方沟通是刚需这个功能点非常加分。最后说一点个人体会。这类从zip解压下来的Spring Boot项目最容易翻车的往往不是业务代码而是环境匹配JDK版本、数据库版本、字符集、路径分隔符任何一个不对都够折腾半天。所以拿到源码别急着改功能先把建库、配库、启动、登录这条主链路完整跑通一次再动手改造否则你会分不清报错到底是代码问题还是环境问题。我做这个二手交易系统时最深的感受就是状态机的设计一定要在写接口前想清楚数据库字段能覆盖所有状态变化比任何花哨的框架技巧都重要。先把这条主线理顺剩下的功能都是搭积木。本文还有配套的精品资源点击获取