最近后台收到好几个同学的留言都在问同一个方向Java毕业设计到底做什么好上手、又能体现工作量我每次都会提到一个经典套路——高校二手商城系统。这个题目不挑基础、功能边界清晰、业务链条也完整从发布商品到下单支付再到库存管理该有的模块全都有拿来练手或者直接当毕设都非常占优势。今天就把我当时做这套系统的完整思路和关键实现拆开讲一讲所有细节都基于SSM框架展开项目本身是Java开发的高校二手商城服务平台覆盖了从用户端到后台管理的全流程。这套系统不是简单的CRUD堆砌它里面藏着几个毕设答辩时特别容易问到的地方表怎么设计、状态怎么流转、事务怎么控制、库存怎么扣这些我都会逐一说清楚。如果你是刚开始学Spring、SpringMVC和MyBatis这套组合的我还会顺便解释为什么这个项目就是为理解SSM量身定做的。别急咱们一个模块一个模块来。1. 从选题到功能全景校园二手交易系统的核心骨架1.1 为什么“高校二手商城”是毕设的常青树一个毕设题目能不能做下去首先看业务逻辑是否清晰。校园二手商城的好处在于它的用户角色、交易流程、物品状态都非常明确不需要像电商平台那样引入复杂的推荐算法、支付网关、物流追踪却又完整保留了“用户—商品—订单”这条最核心的交易链路。市面上很多付费毕设提供的二手商城系统实际上就是一套标准的SSM三层架构项目视图层用JSP或者Thymeleaf控制层用SpringMVC业务层和持久层交给Spring和MyBatis。听起来简单但真要把每个功能做到闭环一样会碰到不少细节问题。例如商品图片上传之后的回显路径、订单超时未支付的状态处理、并发下单时库存数据的正确性——这些都是真实业务中才会出现的坑也正是这些坑让你的项目在答辩时“有话说”。我当时的选题定位是“高校二手商城全流程管理系统”侧重点在于把完整业务流程跑通并且给管理员提供一个可视化的后台统计界面。这样用户端有商城的样子后台又有管理的深度工作量自然就上去了答辩展示的时候也更能撑场面。1.2 功能模块全景买卖双方与管理员三条主线在设计系统之前先把角色理清楚。这套系统一共三类角色普通学生用户、卖家以及系统管理员。其中普通学生用户和卖家往往是同一个注册实体用户在平台里既能发布闲置商品也能购买别人的商品所以设计时不需要分成两张用户表只需要给用户表增加一个状态标记再在商品表记录发布者即可。用户端的功能我分为三个核心闭环商品闭环发布闲置→商品展示→商品搜索/筛选→商品详情→收藏或留言咨询。交易闭环加入购物车→提交订单→支付模拟支付→订单状态变更→确认收货→交易完成。个人中心闭环我发布的商品上下架/编辑/删除→我买到的→我卖出的→我的收藏→地址管理非必选但加上会显得完整。管理员后台的功能则围绕业务数据管理来设计商品审核可选用很多毕设为了省事直接不审核、用户管理、订单管理、分类管理、公告管理、数据统计。其中数据统计模块可以画柱状图和折线图再配上ECharts一天就能搞定展示效果却非常加分。1.3 平台特有的业务规则设计二手商城和普通商城相比有两个业务规则值得特别注意这两个规则能体现你对业务的思考深度。规则一商品不能重复上架。用户点击“发布商品”后商品默认状态是在售如果商品被下单购买状态应该变成已售出或锁定只有交易取消/退款后商品才恢复在售状态。很多初学者把商品状态设计成简单的0和1甚至不设置状态字段结果同一个商品被两个人同时下单库存就变成负数了。规则二订单与商品的关系是一对一。校园二手交易场景里一个商品只有一个所有者、一个买家所以订单表直接关联商品ID即可不需要设计订单项子表。电商系统的“订单包含多个商品”模型在二手平台反而不适用这一点在答辩时可以主动提出来说明你是理解业务场景后再设计的表结构而不是盲目照抄常规商城表。提示业务规则不要堆在一张表里用一堆字段硬扛通过状态机的方式去管理商品和订单状态代码写起来会清爽很多后面我会详细讲状态机的设计。2. SSM三大件各自扛什么活框架选型的底层逻辑2.1 Spring把对象管理交给容器先说Spring。很多初学者第一次接触Spring的时候只知道IOC和AOP这两个概念但真正在SSM项目里看代码依然说不清Spring到底干了什么。其实在这套二手商城里Spring管理的核心对象是Service层的业务类。例如UserService、ProductService、OrderService这些对象都由Spring容器创建并通过依赖注入的方式传给Controller使用。你不需要在Controller里写new UserService()也不需要担心这些对象的生命周期和销毁问题容器自动帮你搞定。AOP在这个系统里最典型的应用有两个。一是事务管理声明式事务配置好之后addOrder方法内的多个数据库操作要么全部成功要么全部回滚避免出现订单生成但商品状态没改的脏数据情况。二是日志记录我在管理员操作模块上加了切面用户进行删除商品、修改订单状态等操作时会自动记录日志但这里用AOP主要是为了演示效果答辩时可以作为亮点提一句。2.2 SpringMVC请求怎么走进来、走出去SpringMVC负责Web层的请求分发。浏览器请求经过DispatcherServlet由处理器映射器找到对应的Controller方法方法执行完成后返回逻辑视图名再经视图解析器拼接出JSP路径。这一套流程很像公司的前台所有访客来了先到前台DispatcherServlet前台根据来访目的URL找到对应的接待人员Controller方法接待人员处理完事情之后安排你从对应的出口离开视图渲染。我在Controller层设计时遵循一个原则Controller只做参数接收、参数校验和结果返回不写业务逻辑。业务逻辑一律下沉到Service层。这样做的直接好处是方法短小清晰答辩时被问到一个业务相关的代码路径你能用几分钟时间在IDE里快速定位到具体方法不至于翻半天代码还讲不清。前端传输格式上页面提交方式我采用了两种普通表单使用application/x-www-form-urlencoded提交数据交互接口使用JSON格式Controller方法用RequestBody接收返回结果统一封装成Result对象里面包含状态码、消息、数据和成功标识这几个字段。统一响应结构的好处后面还会提到至少在做前端统一弹窗提示时不用每个方法单独处理。2.3 MyBatisSQL可控性是关键MyBatis在SSM里的定位是持久层框架操作数据库的SQL写在XML映射文件里。相比Hibernate很多人更喜欢MyBatis的一点就是SQL完全由自己控制映射关系透明可见。商城系统的SQL复杂点主要在多表关联查询和动态SQL上。比如首页的商品列表如果是全量查询倒还好但实际筛选条件非常多分类ID、价格区间、商品名称模糊匹配、商品状态、是否是我自己的商品等。用MyBatis的动态标签可以灵活拼接select idlistProducts resultTypeProductVO SELECT p.*, u.nickname AS sellerName FROM product p LEFT JOIN user u ON p.seller_id u.user_id where if testcategoryId ! null AND p.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (p.title LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if if teststatus ! null AND p.status #{status} /if if testminPrice ! null AND p.price #{minPrice} /if if testmaxPrice ! null AND p.price lt; #{maxPrice} /if /where ORDER BY p.create_time DESC if testoffset ! null and limit ! null LIMIT #{offset}, #{limit} /if /selectwhere标签会自动处理第一个条件前面的AND关键字这种写法在业务条件经常变化的场景下极其好用。如果你用JDBC这套拼接逻辑可能会写成几十行的if判断维护起来很痛苦用Hibernate又不如这种写法直观。这也是我最终选择MyBatis的原因——在“可控性”和“开发效率”之间取得了一个平衡点。2.4 为什么不直接上SpringBoot我在做这个项目的时候特意没有选SpringBoot而是采用了最传统的SSM手工整合方式。原因很现实毕设项目如果直接用SpringBoot框架自动配置把很多底层细节都藏了起来答辩时评委问“SpringMVC的核心控制器是什么”“MyBatis的SqlSessionFactory是怎么创建的”很多同学答不上来。而SSM整合过程中applicationContext.xml、spring-mvc.xml、mybatis-config.xml这些配置全部要手写你会被迫理解每个配置项的含义基础打得扎实答辩也更有底气。当然如果你想用SpringBoot做也不是不行很多同学改成SpringBoot之后确实缩短了开发周期配置上确实方便很多但如果你选的是“SSM框架”这个题目我建议还是老老实实走XML配置路线。这不是固执而是从“学到东西”和“顺利答辩”两个角度出发的最优解。3. 数据库设计从用户表到订单表状态怎么流转3.1 核心表结构拆解数据库设计是我在写代码之前花的时间最长的一步。表结构设计得合理后端的开发顺畅度能提升一个量级表设计得混乱后期改起来会非常痛苦。我设计的核心表大概有7张表名字段要点设计说明useruser_id, username, password, nickname, avatar, phone, create_time用户表学生使用学号注册categorycategory_id, name, sort_order商品分类表如教材、数码、生活用品productproduct_id, seller_id, category_id, title, description, price, original_price, cover_image, status, create_time, update_time商品表状态字段用于判断商品生命周期product_imageimage_id, product_id, image_url, sort_order商品多图存储表cartcart_id, user_id, product_id, quantity, create_time购物车表favoritefavorite_id, user_id, product_id, create_time收藏表ordersorder_id, order_no, product_id, buyer_id, seller_id, price, status, create_time, pay_time, finish_time, cancel_time订单表包含买卖双方字段commentcomment_id, product_id, user_id, content, create_time评论留言表用户表要注意一个细节密码字段需要加密存储不要直接用明文。我用的是MD5加盐的方式后来想更安全一点可以换成BCrypt不过对于教学项目只要能说出“密码不能明文存储”这个意识答辩印象分就有了。商品表与商品图片表分离是常见设计。主表存封面图用于列表展示副表存所有图片用于详情页轮播。这样列表查询的时候不需要把所有图片数据都捞出来查询效率更高。你可能会问为什么不直接把图片地址用逗号拼接存在主表里确实有项目这么干但后患很多——比如删除某一张图片时你得先查出来再拆分字符串再拼接回去而用子表的实施就是一条DELETE操作清爽利落。3.2 商品状态机与订单状态机的设计状态机是我觉得这套系统里最值得拿出来讲的部分。毕设项目里把状态流转设计清楚不仅代码少那么多if嵌套数据也不容易乱。商品表里我定义了四个状态0下架用户手动下架或在售状态被禁用1在售正常展示给所有用户2锁定已被下单等待买家付款或交易完成3已售出交易完成商品不可再售订单表里我同样定义了五个状态0待付款用户下单成功商品状态变为锁定1待发货/待交付2已完成3已取消4退款为什么要给商品增加“锁定”状态主要是为了避免超卖问题。校园二手商城跟B2C电商平台不同每件商品都是独一无二的闲置物不存在“库存100件只卖掉一件还剩99件”的情况。当买家下单成功的那一刻商品就应该从“在售”变为“锁定”防止其他用户同时下单这个商品。等到订单最终取消或超时关闭再将商品状态解锁恢复为在售。订单状态变更我集中在Service层的一个updateOrderStatus方法里把“查询订单→校验当前状态与目标状态是否合法→更新订单→联动修改商品状态”这个完整事务包在一个方法内一旦操作过程中抛出异常Spring事务会整体回滚保证订单和商品状态始终处于一致状态。3.3 表关联的几个容易踩的坑多表查询时的别名和字段映射是最容易出低级错误的地方。MyBatis的resultMap配置里如果数据库字段是下划线命名如create_time而Java实体属性是驼峰命名如createTime需要开启驼峰映射配置setting namemapUnderscoreToCamelCase valuetrue/这个配置不开启你会发现查出来的对象一堆属性是null但你在数据库里分明能看到数据。遇到这个问题不要怀疑SQL先检查MyBatis配置。还有一个常见问题是分页查询时的COUNT语句。很多人直接写SELECT COUNT(*)还好但如果SQL特别复杂COUNT语句的性能会很差。我的解决方案是分页查询时单独写一个countProducts方法只做计数不做多表关联查询效率明显提升。删除操作也要思考清楚。用户发布过的商品不要物理删除否则订单表引用的外键就悬空了到时候查询历史订单时关联不到商品信息。可以用逻辑删除字段用户删商品时只是把状态改为下架订单记录依然保留商品快照信息。4. 三个核心业务流程的实现细节与关键代码4.1 商品发布与图片上传商品发布是一个流程较长的功能因为涉及到图片上传、字段校验、数据落库多个环节。我的设计是前端先调用图片上传接口把图片传到服务器拿到返回的图片URL后再和商品信息一起提交到发布接口。图片上传场景下有几个关键配置必须处理上传文件大小限制。SpringMVC默认允许上传的文件大小是1MB如果你不修改配置一张手机拍出来的照片通常3-5MB就上传失败。我一开始就踩了这个问题在spring-mvc.xml里配置了bean idmultipartResolver classorg.springframework.web.multipart.commons.CommonsMultipartResolver property namemaxUploadSize value104857600/ property namemaxUploadSizePerFile value5242880/ property namedefaultEncoding valueUTF-8/ /bean文件存储路径也不要写在代码里写死。我在项目根目录外建了一个专属的上传目录然后把路径配置到配置文件里方便以后统一迁移。同时在保存文件时生成UUID文件名String uuid UUID.randomUUID().toString().replaceAll(-, ); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String newFileName uuid suffix;为什么要用UUID重命名原因有两个一是避免用户上传的文件名包含中文或特殊字符在部分浏览器和服务器环境下会导致乱码或路径解析异常二是避免同名文件互相覆盖别人上传了photo.jpg你也上传了photo.jpg如果不重命名后上传的会把先上传的覆盖掉。图片保存之后数据库里记录的是虚拟路径比如/upload/20240612/xxxxx.jpg。页面通过这个虚拟路径访问时需要一个资源映射配置否则请求会被404。这里也需要在spring-mvc.xml里增加静态资源映射把/upload/**这个URL映射到服务器上的真实物理路径。4.2 下单与事务边界下单是整个系统中事务性最强的操作。表面上看起来逻辑不复杂往订单表插入一条记录再把商品状态改为锁定。但如果你仔细考虑各种边界情况就会意识到这里面有多个操作需要保持一致性。我先说一下事务边界怎么划定。用户提交订单时要做的操作是检查商品是否在售、检查商品是否属于当前用户不能买自己的商品、生成订单号、插入订单记录、修改商品状态为锁定、清空购物车中对应的商品记录。这五个步骤只要任何一步失败数据库的数据都不能出现中间状态。所以我用Transactional把这个方法包裹起来Transactional Override public Order addOrder(Long userId, Long productId) { // 1. 查商品 Product product productDao.findById(productId); if (product null || product.getStatus() ! 1) { throw new BusinessException(商品已下架或已被购买); } // 2. 校验是否为自己发布的商品 if (product.getSellerId().equals(userId)) { throw new BusinessException(不能购买自己发布的商品); } // 3. 生成订单号并插入订单 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setProductId(productId); order.setBuyerId(userId); order.setSellerId(product.getSellerId()); order.setPrice(product.getPrice()); order.setStatus(0); orderDao.insert(order); // 4. 锁定商品 productDao.updateStatus(productId, 2); // 5. 删除购物车中相关记录 cartDao.deleteByUserIdAndProductId(userId, productId); return order; }Transactional在这里的语义是Spring AOP在方法执行前开启数据库事务方法正常执行完毕才提交事务如果方法内抛出任何运行时异常整个事务回滚。这里要特别注意一个坑默认情况下Spring的声明式事务只对RuntimeException和Error回滚对受检异常Exception的子类不回滚。如果你在Service方法里捕获了异常并且没有向上抛出事务是不会回滚的数据就会处于不一致状态。我建议的处理方式是自定义一个业务异常类BusinessException继承RuntimeException这样所有Service层的校验失败都可以直接抛出异常事务也能正确感知同时前端又能通过全局异常处理器拿到统一的错误提示。这里还值得一提的细节是订单号的生成。很多人直接System.currentTimeMillis()这样生成的订单号在并发量高的情况下大概率重复。我用的方案是当前时间 用户ID 随机数拼接成字符串或者用时间戳加自增序列号确保在答辩演示时每次生成的订单号都是唯一的。4.3 交易完成后的状态联动订单状态从“待付款”到“已完成”的整个过程代码都要处理状态变更之后的联动操作。模拟支付功能是毕设里常见的演示点。我们会做一个模拟支付页面用户点击“确认支付”后调用后端接口把订单状态从待付款改为待交付再把订单中的支付时间字段填充为当前时间。这一步不需要真的对接支付宝或微信支付网关答辩时说明“只做业务演示不涉及真实扣款协议”即可。买家确认收货后订单状态变为已完成此时要做几件事修改订单状态为已完成记录完成时间商品状态从锁定变为已售出给卖家发送一条站内信通知提示商品已卖出。站内信通知是我额外加的一个小功能有一个独立的消息表。用户登录后能看到未读消息数量点进去可以查看交易进度、有人留言等动态。这种小功能代码量不大但对系统的完整度和用户体验提升非常明显在答辩demo演示时也更有看点。如果订单在买家付款之后又被买家申请取消暂不支持卖家主动取消流程则是校验订单是否处于待交付状态如果合法则把订单状态改为退款商品状态改回在售。顺便提一句如果你的项目要增加“退款审核”流程就需要引入管理员操作了。有同学在退款流程上加了管理员的审核环节这会让后台管理的功能更饱满不过开发周期也会相应延长根据个人时间取舍即可。5. 答辩问倒一片的高频坑点并发、跨域与配置细节5.1 并发下单会导致库存超卖吗答辩时一个经典问题是如果两个用户同时给同一个商品下单你的系统会怎么处理这个问题的标准回答是数据库层面需要加锁或者使用状态更新条件来保证并发安全。我当时的做法是在更新商品状态的SQL里加上状态条件判断如果影响行数为0说明商品已经被人抢先下单了UPDATE product SET status 2 WHERE product_id #{productId} AND status 1这条SQL利用数据库行锁机制完成了“比对并更新”两个动作。如果返回的影响行数是1说明更新成功商品是从在售状态改成了锁定如果返回0说明商品状态已经不是1了说明在并发场景下已经有别的订单抢先处理了此时业务层直接提示用户商品已被购买。这是一种非常精简的乐观锁写法不需要额外引入Redis分布式锁但对于毕设项目来说这个方案完全够用而且体现出了并发控制的意识。5.2 程序配置层面的三个坑第一个坑是JDBC连接MySQL时的时区问题。如果你使用MySQL 8.0以上版本连接字符串必须增加时区参数jdbc.urljdbc:mysql://localhost:3306/campus_secondhand?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai不配置时区驱动启动时会直接抛The server time zone value й׼ʱ is unrecognized这个异常我大四那年第一次做项目时就卡在这个地方半天后来发现就是少了时区参数。第二个坑是JSP的页面路径。SSM框架里Controller返回的字符串是逻辑视图名例如return product/list;视图解析器会拼成/WEB-INF/views/product/list.jsp。如果项目没有配置prefix和suffix或者JSP页面放在了/webapp/根目录下面return的路径怎么都找不到页面。第三个坑是Spring版本兼容。有的人用Spring 5系列配MyBatis 3.4以下的版本会出现Invalid bound statement (not found)的报错。这个报错通常意味着Mapper接口和Mapper.xml文件没有正确绑定需要检查Mapper接口的包名、方法名、XML文件中的namespace是否一致以及Spring配置里是否扫描到了Mapper接口。这类问题排查的时候先检查配置文件再检查代码效率会高很多。5.3 前端对接时的JSON序列化问题现在做毕设很多同学已经不会自己从零写JSP页面了而是采用前后端分离的方式Vue3 SSM。如果你选择了前后端分离那么Controller返回给前端的数据必须是JSON格式而且要注意日期字段的序列化格式。我在Result对象里包含了一个Date类型的字段没有加格式化注解时前端拿到的是时间戳字符串非常不直观。解决方法是加上JsonFormat注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private Date createTime;另外前后端分离后还要处理跨域问题。你前端跑在http://localhost:8081后端跑在http://localhost:8080端口不同浏览器会判定为跨域。如果不在后端配置跨域过滤器或使用CrossOrigin注解请求即便发出的数据也是被浏览器拦截的。我建议在SpringMVC配置类里全局注册CORS配置统一处理所有接口的跨域访问前端调试的时候就不用每个方法单独标注跨域注解了。还有一个非常隐蔽的小坑如果你用RequestBody接收前端的JSON对象前端必须设置请求头的Content-Type为application/json。很多人前端代码用axios时只在GET请求里传了参数没有将对象转换为JSON字符串后端就直接报HttpMessageNotReadableException。这个问题排查起来最耗时间一次确认前端代码类型就能看出来。5.4 答辩演示时容易翻车的场景预防最后说几个我亲眼见过的演示翻车场景。图片上传功能演示前务必确认上传目录的可写权限别等演示时点了上传按钮报500手忙脚乱不知道怎么回事。演示下单流程时如果商品已经被之前测试下单了状态是锁定界面会一直提示“商品已被购买”给评委造成的印象就是这个功能有问题。所以演示前要用管理员账号把测试订单清掉或者重新发布一个状态为在售的新商品。另外如果使用了Tomcat服务器注意JSP编译的Java版本要和本机JDK版本一致。有些同学的电脑装了JDK21Tomcat版本却较老启动时可能报UnsupportedClassVersionError最简单的办法就是统一使用同一条技术链或者在演示前检查Tomcat启动日志。数据库连接池我推荐使用Druid比Tomcat自带的连接池多了监控页面可以在浏览器里直接查看当前的数据库连接数、SQL执行耗时。答辩时给评委展示一下Druid的监控页面比光看代码更有说服力。收尾的实际体会这套高校二手商城系统从设计到编码我前后大概用了三周时间真正动手写代码之前花了一周看视频和捋思路。现在回头看SSM这个技术栈确实比SpringBoot要繁琐一些但正因为繁琐你在手写配置的过程中把Spring容器、SpringMVC请求链路、MyBatis映射这些底层的机制都扎扎实实过了一遍。之后我再去学SpringBoot看到那些自动配置时真的有一种“原来它帮我干了这些活”的豁然开朗感。如果你也准备做这个题目我的建议是别急着敲代码。先把用户角色、核心流程、表结构在纸上画一遍再去看项目代码你会发现自己对这套系统的理解会快很多。遇到不懂的配置和报错也别慌去查日志、多断点调试、自己动手改几遍踩过坑才能真正掌握这套技术栈。希望这篇内容能帮你少走些弯路顺利拿下毕设。