SpringBoot+SSM二手交易系统实战：从建模到部署的完整复盘

基于 Java SpringBoot SSM 的二手物品交易网站系统在毕业设计和培训班项目里差不多是最常见的题目了。常见到什么程度随便搜一下就有上百个模板。但做一个能跑的二手交易网站和把一个二手交易系统讲明白、调明白、部署明白是两码事。我最近刚完整地从零搭建和调试了一套这样的系统从需求拆解、数据库建模到核心接口实现再到并发问题和部署上线过程不复杂但坑位密集。这篇就是我的完整复盘给正在做毕设、项目实训或者想入门 Java 全栈的朋友做个参考你不需要照抄代码重点是理解背后的取舍逻辑。1. 项目背景与需求边界这个二手交易系统到底要解决什么问题1.1 二手交易网站的业务根模型一个二手交易平台表面上看就一句话有人卖有人买平台做撮合。但当你真的开始设计数据表的时候撮合这两个字会衍生出一堆问题卖家是普通注册用户不是商家所以没有传统电商那种复杂的商家后台全靠个人中心管理自己发布的商品买家在C2C场景下通常不会走购物车而是看中了直接下单线下或者站内沟通商品状态比普通电商复杂待审核、在售、已售、下架、删除这些状态之间不是任意跳转的用户既是买家也是卖家同一个账号要同时维护我买到的和我卖出的两套订单视角我在动手之前先画了一张业务流程图把所有可能的功能点全部列出来然后用一句话筛选标准砍功能这个功能如果不存在核心交易链路会不会断不会断的一律砍掉或者标为可选。最后定下来的功能清单如下用户端注册、登录、个人信息维护包括头像上传商品发布、编辑、上下架管理商品列表浏览、关键词搜索、分类筛选、价格区间筛选商品详情、收藏、留言咨询下单购买、订单查看、取消订单管理端用户管理支持禁用/启用商品审核与下架商品分类管理基础数据统计购物车、优惠券、秒杀、站内聊天这些统统一律不做。原因很直接毕设或练手项目的核心价值在于把主链路做深做透而不是把功能面铺得很宽。每次答辩我都听到同学说我做了购物车但当老师追问购物车的库存锁定逻辑时就答不上来了。与其这样不如把订单状态流转、并发下单这些真正有含金量的点做好。1.2 角色模型与核心流程设计系统一共三类角色管理员、卖家、买家。需要特别说明的是在C2C二手交易场景下买家和卖家本质上都是普通用户只是一个账号在不同业务节点上的不同身份。所以我强烈建议不要设计成 buyer 表和 seller 表两张表而是统一用 user 表 role 字段区分是否管理员。普通用户的买和卖身份通过订单表里的 buyer_id 和 seller_id 来体现根本不需要在用户层面做拆分。这个设计决策直接影响订单表的结构。我在订单表里冗余存了 seller_id虽然可以通过商品表 join 用户表查出来但每次查订单都要拆两次 joinSQL 又长又慢。冗余字段虽然违反第三范式但在这个场景下换来了查询效率和代码简洁度属于典型的时间换空间的取舍。核心流程我梳理成四条主链路每条都对应一套状态机卖家发布商品 - 管理员审核 - 上架在售买家浏览搜索 - 查看详情 - 下单 - 卖家确认 - 交易完成买家取消订单 - 商品状态回滚为在售用户注册 - 登录 - 进入个人中心其中订单状态机是最核心的待付款、待发货、待收货、已完成、已取消。状态之间的跳转我全部在 Service 层用校验方法控制而不是放任代码随意 set 字段。这样一来哪怕后面接手的同学不熟悉业务看到校验逻辑也能明白订单应该怎么流转。2. 技术选型的底层逻辑SpringBoot 与 SSM 的搭配怎么理解2.1 标题里SpringBoot SSM到底是什么组合这个值得专门解释一下因为太多人在这上面犯迷糊。SSM 是 Spring SpringMVC MyBatis 的缩写这是国内 Java Web 开发非常经典的一套组合。而 SpringBoot 是基于 Spring 的快速开发脚手架它本身已经把 Spring 的核心功能涵盖了。所以严格来说SpringBoot SSM在字面上是有点重复的——你不可能在一个项目里同时用两个 Spring。实际项目中大家说的SpringBoot SSM指的是SpringBoot 作为基础和自动配置框架Web 层用 SpringMVC 的模式写 Controller持久层用 MyBatis或 MyBatis-Plus做数据库操作。分层依然是 Controller - Service - Mapper 三层经典架构但不再需要手写那些繁琐的 XML 配置。我之所以用这套组合而不是传统的纯 SSM XML 配置核心就一个字快。Spring 的 XML 配置对于老开发者来说是肌肉记忆但对新手来说简直是地狱——数据源配置、事务管理器、组件扫描、视图解析器、MyBatis 的 SqlSessionFactory每一处都有细微的坑。SpringBoot 用自动配置把这些全部收编了我搭项目的时候从创建工程到跑通第一个接口不到半小时。2.2 持久层为什么选 MyBatis 而不选 JPA持久层我没有用 Spring Data JPA选的是 MyBatis。这纯粹是业务场景决定的第一联表查询是高频操作。商品列表要展示分类名称、卖家昵称、收藏数量一个页面就涉及三四张表的 join。JPA 的 Entity 关联虽然也能做但延迟加载和 N1 查询问题处理起来非常别扭。MyBatis 直接手写 SQLjoin 逻辑写在 XML 里复杂查询一眼就能看明白。第二动态 SQL 是搜索功能的刚需。用户在搜索页可能填了关键词、也可能勾选了分类、还可能拖了个价格区间。这些条件任意组合MyBatis 的whereif标签天然支持而 JPA 的 Specification 写起来又长又难读。第三答辩层面的考虑。用 MyBatis 意味着你能讲清楚每一条 SQL 的联表逻辑能解释动态 SQL 的拼接过程。用 JPA 的话很多同学被问到底层的 SQL 长什么样就直接卡壳了只能含糊说框架自动生成。这种场景我见得太多了。2.3 前端方案与配套组件前端我用的 Thymeleaf 模板引擎 Bootstrap jQuery没有搞前后端分离。这个选择在现在的技术讨论里可能会被质疑但放在毕设和练手项目的场景下其实是深思熟虑的不需要处理跨域问题。前后端分离必然要面对 CORS 或代理配置这个坑能绕就绕不需要维护两套工程。一个 SpringBoot 工程搞定全部war 包或 jar 包部署都省心服务端渲染天然支持 SEO商品详情页能被搜索引擎收录数据库用 MySQL 8.0连接池用 Druid密码加密用 BCrypt这些都属于 Java Web 项目的标配不需要太多解释。倒是 Redis 我特别说一下很多培训机构喜欢把 Redis 硬塞进毕设里理由往往是加分项。但如果你的项目里有多个模块操作缓存又要考虑缓存穿透、雪崩、数据一致性复杂度蹭蹭往上涨。这个项目体量下热门商品列表用 Spring 自带的本地缓存就够了何必给自己找麻烦。3. 数据库建模三张核心表如何撑起交易闭环3.1 用户表别把买家和卖家拆成两张表用户表是整套系统的基石。字段设计如下字段名类型说明idint自增主键usernamevarchar(50)用户名唯一索引passwordvarchar(100)BCrypt 加密后的密码avatarvarchar(255)头像相对路径phonevarchar(20)手机号roletinyint0 普通用户1 管理员statustinyint0 正常1 禁用create_timedatetime注册时间三个设计要点展开说第一username 必须加唯一索引。注册接口如果没做唯一校验两个请求同时进来就会插入两条相同用户名。虽然 Service 层做了查重但查重和插入之间存在时间窗口唯一索引是数据库层面的最后防线。第二密码绝对不能存明文。我见过不止一个同学的项目源码里数据库存的密码就是 123456答辩时老师看一眼数据库就不想继续问了。BCrypt 加密的好处是自带盐值同一个密码每次加密结果都不一样而且内置了强度参数比 MD5 加固定盐安全得多。第三status 字段是给管理员用的。普通用户违反平台规则时管理员可以一键禁用账号。这个字段的设计要配合登录拦截器一起用——登录时不仅校验密码还要校验 status 是否为 0。3.2 商品表状态字段是设计灵魂商品表是字段最多的表我这里给出核心字段id自增主键user_id发布者关联用户表category_id商品分类title标题长度控制在 50 字以内description详细描述TEXT 类型priceBigDecimal精确到分original_price原价可选填cover_image封面图images多图地址逗号分隔status0 待审核1 在售2 已售3 下架4 删除view_count浏览次数create_time、update_timeprice 用 BigDecimal 而不是 double这是交易类系统的铁律。double 在二进制里无法精确表示 0.1当商品价格 99.99 经过多次运算后可能变成 99.9900001累计误差在订单对账时就是灾难。status 字段是整个商品表的灵魂。我在 Service 层提供了几个校验方法查询详情时必须是 status1 的商品才能正常浏览下单时必须是 status1 才能创建订单编辑商品时必须是 status1 或 3下架后可重新编辑再上架。这些规则不放在数据库层面而是放在 Service 层目的是让业务报错信息更友好。你要是用数据库约束用户看到的是SQLException而用 Service 层校验用户可以收到该商品已下架这样明确的提示。3.3 订单表状态机与并发控制订单表是交易闭环的落点。核心字段idorder_no订单号唯一我用的是时间戳 用户ID 随机数拼接product_id商品IDbuyer_id买家IDseller_id卖家ID冗余存储避免重复 joinprice成交价下单时从商品表快照过来status0 待付款1 待发货2 待收货3 已完成4 已取消create_time、pay_time、finish_time订单号为什么要单独生成而不是直接用自增ID因为自增ID会暴露系统真实的订单量而且在打印订单、客服沟通时一个纯数字的 ID 既不美观也容易被恶意遍历。时间戳 用户ID 随机数的组合基本可以保证全局唯一。下单是整个系统里唯一必须使用事务的接口。我的实现逻辑是Transactional public void createOrder(Integer productId, Integer buyerId) { Product product productMapper.selectById(productId); // 校验商品状态 if (product.getStatus() ! ProductStatus.ON_SALE) { throw new BusinessException(商品不存在或已下架); } // 创建订单 Order order new Order(); // ... 填充订单字段 orderMapper.insert(order); // 更新商品状态注意条件包含 status 1 int rows productMapper.updateStatus(productId, ProductStatus.ON_SALE, ProductStatus.SOLD); if (rows 0) { throw new BusinessException(商品已被抢购); } }这里最关键的是最后这条 update 语句。它的含义是只有当商品当前是在售状态时才能改成已售。在高并发场景下多个请求同时通过了前面的 status 校验但数据库层面的条件更新会把它们卡住——只有一个人能更新成功其他人都返回 0 行受影响。这就是典型的 CASCompare and Swap思想一句话就解决了超卖问题。4. 核心接口的落地细节登录、发布、搜索的实现4.1 基于 Session 拦截器的登录鉴权因为没有做前后端分离所以我没有用 JWT而是选择了 Session 拦截器这套最贴合服务端渲染的方案。登录接口的核心逻辑PostMapping(/login) public String login(String username, String password, HttpSession session) { User user userService.login(username, password); if (user null) { return redirect:/login?error1; } if (user.getStatus() 1) { return redirect:/login?forbidden1; } session.setAttribute(user, user); return redirect:/index; }登录成功后把完整的用户对象放进 Session。后续不管是个人中心、商品发布还是下单所有需要身份的操作都从 Session 里取用户不再查库。这里有个小优化Session 里存的是完整用户对象如果管理员改了用户昵称旧数据还在 Session 里。简单的做法是每次进入个人中心时刷新一次 Session 里的用户信息成本极低但能避免很多奇怪的展示问题。拦截器的实现重点是放行规则。我第一次配置的时候把静态资源也拦了结果整个页面的 CSS、JS、图片全部加载不出来页面跟裸奔一样。正确的做法是注册拦截器时把所有需要免登录访问的路径都配置进去registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /register, /index, /product/**, /category/**, /search, /static/**, /upload/**);这里 /static/** 和 /upload/** 必须放行前者是前端资源后者是上传的图片。4.2 商品发布与图片上传的完整流程商品发布页面需要一个支持多文件上传的表单。前端的核心结构form th:action{/product/add} methodpost enctypemultipart/form-data input typetext nametitle input typehidden nameprice textarea namedescription/textarea select namecategoryId.../select input typefile namefiles multiple button typesubmit发布/button /form后端的接收逻辑PostMapping(/product/add) public String addProduct(Product product, RequestParam(files) MultipartFile[] files, HttpSession session) { if (files ! null files.length 0) { ListString paths new ArrayList(); for (MultipartFile file : files) { String fileName UUID.randomUUID().toString() getExtension(file.getOriginalFilename()); String filePath uploadDir / fileName; file.transferTo(new File(filePath)); paths.add(/upload/ fileName); } product.setCoverImage(paths.get(0)); product.setImages(String.join(,, paths)); } // ... 保存商品 }这里有几个细节值得展开第一文件名一定要用 UUID 重命名。原始文件名比如毕业设计答辩PPT.jpg如果直接落盘两个用户在不同时间上传了同名的图片后上传的会把先上传的覆盖掉。我见过某个项目因为这个问题一个用户的商品图和商品描述对不上号排查了两天才发现是文件名冲突导致图片被顶掉。第二Upload 目录要独立配置。不要在代码里写死绝对路径而是在配置文件里定义比如web: upload-path: /data/secondhand/upload/然后配置虚拟路径映射Configuration public class WebConfig implements WebMvcConfigurer { Value(${web.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(uploadPath /); } }这样浏览器访问 /upload/xxx.png 时就会映射到服务器磁盘上的真实文件。部署后如果要迁移文件位置只改配置文件就行不用动代码。第三上传大小限制。前面提到过SpringBoot 默认单个文件最大 1MB必须调整。如果你用的是内嵌 Tomcat还需要在 application.yml 里把 maxSwallowSize 也调大否则大文件上传时连接会被强制关闭报错还不是很好找。4.3 动态 SQL 实现多条件搜索搜索功能是二手交易系统和普通企业管理系统最大的区别。用户进来不一定带着明确目标可能只搜关键词可能只看某个分类可能限制价格区间。这些条件全部可选就要用 MyBatis 的动态 SQL 来拼。核心的 select 语句我在前面已经贴过这里补充三个容易踩坑的点第一模糊搜索的写法。不要直接写 LIKE %#{keyword}%MyBatis 会报语法错误因为 #{} 会被预编译成占位符不能直接拼进 LIKE 的字符串里。正确写法是 CONCAT(%, #{keyword}, %)。第二多表 join 后要注意字段名歧义。商品表和分类表都有 id 和 create_time 字段select 里定义了别名就一定要在 WHERE 和 ORDER BY 里用别名。我之前就写过一次没有加别名的 order by create_timeMySQL 直接报了 ambiguous column 错误。第三分页参数的计算。前端传页码 pageNum 和每页数量 pageSize后端计算 offset (pageNum - 1) * pageSizeLIMIT 后面第一个参数是偏移量。注意 pageNum 从 1 开始不是从 0 开始。select idsearchProducts resultTypecom.example.entity.Product SELECT p.*, c.name AS categoryName, u.username AS sellerName FROM product p LEFT JOIN category c ON p.category_id c.id LEFT JOIN user u ON p.user_id u.id where p.status 1 if testkeyword ! null and keyword ! AND p.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND p.category_id #{categoryId} /if if testminPrice ! null AND p.price gt; #{minPrice} /if if testmaxPrice ! null AND p.price lt; #{maxPrice} /if /where ORDER BY p.create_time DESC LIMIT #{offset}, #{pageSize} /select分页这里我用的是手写 LIMIT没有引入 PageHelper 插件。PageHelper 虽然方便但它在多表 join 和嵌套查询时偶尔会出分页数据错乱的问题手写 LIMIT 对毕设体量来说完全够用而且答辩时能讲清楚分页原理。5. 调试实录我跑通这个系统时遇到的三类典型问题5.1 依赖与版本兼容问题SpringBoot 的项目虽然比纯 SSM 省心但版本问题依然是最早遇到的拦路虎。我一开始用的是 SpringBoot 2.7.x引入的是 mybatis-spring-boot-starter 2.3.1启动时报了一个Failed to configure a DataSource的警告看似是数据库没连上实际上点击堆栈发现是 MyBatis 自动配置类没被识别。排查过程是这样的先检查 application.yml数据库连接参数都对再检查 mapper 接口加了 Mapper 注解最后用 mvn dependency:tree 查看依赖树发现是我手动指定的 mybatis-spring-boot-starter 版本和 SpringBoot 版本不兼容自动配置的 class 被覆盖了。解决方式很简单去掉手动指定的 version改用 SpringBoot BOM 里统一管理的版本。另外 MySQL 驱动的依赖也需要注意MySQL 8.0 对应的是 mysql-connector-java 8.x如果项目里还留着 5.x 的驱动连接数据库时会报 Public Key Retrieval is not allowed 的错误。解决方式是在 JDBC URL 后面加 allowPublicKeyRetrievaltrueuseSSLfalse。5.2 数据库时区与连接编码问题这个项目在本地跑起来之后页面上的时间比系统时间整整快了 8 个小时。查了半天发现是 MySQL 8.0 的时区配置问题——如果没有在 JDBC URL 里指定 serverTimezoneMySQL 默认使用 UTC 时区而本地系统是东八区所以差 8 个小时。解决方案就是在连接 URL 里显式写好jdbc:mysql://localhost:3306/secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueuseSSLfalse顺便说一句很多同学在这个问题上偷懒不指定 characterEncoding结果就是中文乱码接踵而至。商品描述里存的中文变成问号排查链路通常是先看数据库表字符集 - utf8mb4 没问题 - 再看连接 URL - 没指定编码 - 加上后 OK。这个坑基本每个 Java Web 项目都会踩一次与其到时候排查不如一开始就写全。5.3 并发场景下的超卖与数据一致性这是我用压力工具模拟 50 个并发请求下单同一件商品时暴露的问题。现象是商品只有一件但订单表里却插入了 20 多条记录都是同一个商品ID。根因分析下单接口里先查商品状态再创建订单最后改商品状态。三个步骤之间存在时间窗口多个请求同时通过状态检查后各自都认为自己抢到了商品。这是最典型的竞态条件。我最终的解决方案是前面提到的 CAS 更新UPDATE product SET status 2 WHERE id ? AND status 1把状态检查 状态修改合并成一条原子 SQL数据库层面的行锁保证只有一个请求能更新成功。这样订单创建和商品状态更新必须同时成功否则事务回滚。这个问题非常值得在答辩时拿出来讲因为它把一个看似简单的问题暴露出了系统设计的深层考量是区分会写代码和会设计系统的分水岭。6. 从能跑到能交付部署、文档与答辩复盘6.1 打包部署的两种方式开发环境一切正常后部署到服务器又是一轮折腾。SpringBoot 项目有两种打包方式第一种是打 war 包部署到独立 Tomcat。需要把启动类继承 SpringBootServletInitializer同时改打包方式为 war。优点是可以复用服务器上已有的 Tomcat缺点是多了部署目录的管理成本。第二种是打 jar 包直接运行SpringBoot 内嵌 Tomcatmvn clean package -DskipTests nohup java -jar secondhand-1.0.0.jar --spring.profiles.activeprod app.log 21 我推荐 jar 方式运维成本低一条命令搞定启动。生产环境的配置用独立的 application-prod.yml数据库地址、密码、上传路径全部从开发环境配置中剥离。服务器上的 MySQL 一定要改掉默认的 root 密码并且项目里连接数据库的账号不要直接用 root而是单独建一个只有 secondhand 库权限的账号。这些虽然是安全底线但很多练手项目的同学根本不在意直到被人发现了才后悔。6.2 文档的价值为了三个月后的自己项目交付时除了代码文档同样重要。我维护了三份文档第一份是 README写清楚项目是什么、技术栈、目录结构、如何部署。这份文档的目标读者是接手的同学或者一个月后的自己。第二份是数据库设计说明包含 ER 图、每张表的字段含义、状态字段的取值说明。我用表格把 status 的所有取值和对应含义列出来远比看代码猜状态要高效。第三份是踩坑记录记录我调试过程中遇到的所有问题和解决方案。这份文档在答辩准备阶段尤其有用因为老师最爱问你遇到过什么问题怎么解决的有记录在手回答起来从容得多。说句实话写文档这件事在项目开发阶段最容易被人忽略但也是最值得投入的部分。你写的时候觉得是负担三个月后回看会觉得是救星。特别是这种带源码、说明文档和调试手册的项目一份清晰的文档能让你在交付和复盘时省下大量时间。6.3 讲解与演示的节奏建议如果这个项目要用于答辩或者作为作品展示我的建议是讲解逻辑按这个顺序走背景与需求 - 技术选型 - 数据库设计 - 核心功能演示 - 亮点与总结。演示环节建议挑三个场景第一次演示从注册到逛商品展示系统整体的完成度第二次演示发布商品加图片上传展示比较完整的功能链路第三次专门演示异常场景比如重复下单、访问不存在的商品展示系统的健壮性。最核心的讲解点是并发超卖问题的处理和订单状态机的设计。这两个点能体现你对系统设计的理解深度比演示一百个页面都有用。老师在考察时真正关注的是这个项目有没有真做、有没有想明白而不仅仅是功能能不能点通。最后如果时间和精力允许可以想想后续扩展方向。比如给系统加上收藏功能一张 user_id product_id 的关系表加上站内留言一张 sender_id receiver_id content is_read 的消息表甚至引入 Redis 做热门商品的缓存。这些扩展不用真的写完但能讲出扩展设计本身就说明你对系统有全局认知。我在实际开发中的体会是二手交易系统这种体量的项目最大的价值不是代码量而是它逼着你把用户、商品、订单三张表的关系想透把状态流转的边界理清。把这些基本功打扎实后面接触更复杂的系统时你会感谢当时认真建模的自己。