去年夏天老家做杨梅生意的一个同学打电话问我能不能帮他搞一个能线上卖杨梅的东西。我一下子问住了因为当时我刚把手头的毕业设计做完题目恰恰是springboot_ssm846农产品特产品网络交易平台设计与实现。电话里我想得最多的不是技术而是农产品滞销这件事——很多时候不是货不好是产地信息和交易链路断了。做一个交易平台本质上就是把产地信息公开 在线下单 订单履约串成一条完整的路。这篇文章不算严格的教程更像是我把这个项目从零到一复盘了一遍角色怎么设计、表结构怎么拆、核心接口怎么写、我在开发里踩过哪些坑以及答辩时评委到底会问什么。如果你正好在做类似的Java毕设或者想练一个能讲清楚业务闭环的SSM/SpringBoot项目可以直接拿我的思路做参照省去很多试错时间。1. 先把题目拆明白SpringBoot与SSM的关系以及平台的三类角色1.1 特产品交易和普通商城区别到底在哪普通电商平台的核心是多快好省但农产品特产品平台完全不一样。消费者要的是产地、应季、新鲜度以及一个真字——这箱杨梅是不是真的来自仙居这批茶叶是不是那个山头产的所以这个系统表面上长得像普通商城实际在功能设计上必须有所偏重商品必须带上产地信息而且产地能作为独立筛选条件需要一个尖货/新品的曝光位因为农产品有强烈的季节性比如杨梅只有短短两周的黄金销售期商家端得能主动上下架、维护库存毕竟生鲜类目对售罄很敏感平台侧要能发布公告比如阳澄湖大闸蟹预售开启订单流程必须有发货、确认收货这些履约环节如果只是写一个标准增删改查商城答辩时最容易被问你这个系统到底解决了什么实际问题。我在设计第一天就把产地和季节放进了分类、商品、搜索这几个核心模块里后面所有的页面和接口都围绕它们展开。1.2 SpringBoot SSM到底是不是一个伪命题SSM不是被SpringBoot取代了吗这是我被问得最多、也是最容易答错的一个问题。准确的说法是SpringBoot并没有取代SSM它用自动配置把Spring、SpringMVC、MyBatis三者重新组织了一遍。SpringBoot引入了spring-boot-starter-web内部仍然是SpringMVC那套处理器连上mybatis-spring-boot-starter之后底层依然是Spring容器管理Bean、MyBatis管理SQL映射。跑起来的功能边界和传统SSM没有本质区别。区别在配置方式。传统SSM项目要手写applicationContext.xml、spring-mvc.xml、mybatis-config.xml三套配置文件还要手工装配数据源、事务管理器。到了SpringBoot一个application.yml加几个starter就全搞定内嵌Tomcat让部署也省了。所以你可以这样回答评委SpringBoot不是替代了SSM而是SSM技术栈在现在这个阶段最主流的组织方式。这句话一出口为什么你用了SpringBoot还叫SSM项目这个问题就翻篇了。我给自己项目起目录名的时候就直接用了springboot_ssm846846是当时的项目代号也提醒我底层是SSM外壳是SpringBoot。1.3 三类角色与一条主链路平台有三类用户普通用户消费者注册、浏览特产、搜索、加入购物车、下单、模拟支付、确认收货、评价商品商家农户/合作社注册商家账号、申请开店、发布特产、管理库存、发货、回复评价管理员审核商家和商品、发布公告、查看订单和销售统计这三类角色在系统里的互动形成了一条完整主链路用户浏览产地特产 → 加入购物车 → 提交订单 → 模拟支付 → 商家备货发货 → 用户确认收货 → 评价商品。我整个项目的页面和Controller都围绕这条链路展开。后来复盘发现真正让系统像个产品的不是某个页面多华丽而是这条链路上每一步的状态变化都有人负责、有地方可查。2. 技术选型的判断为什么是SpringBoot重写的SSM而不是其他花活2.1 依赖清单两分钟把SSM环境搭完我选型是SpringBoot 2.7.18 JDK 8 MySQL 8.0 MyBatis PageHelper分页插件 Thymeleaf模板引擎 Bootstrap和jQuery做页面管理后台的图表用ECharts。pom.xml核心依赖长这样parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies !-- Web启动器内置SpringMVC Tomcat -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 模板引擎对应传统SSM里的JSP -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependency !-- MyBatis整合对应传统SSM的MyBatis部分 -- dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency !-- 分页插件记住要选spring-boot-starter版本 -- dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version1.4.7/version /dependency !-- MySQL驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这套组合的好处是沉淀了很多年网上资料多、报错好搜团队协作时互相问一句也能接上话。SpringBoot版本我特意选了2.7系列而不是3.x因为3.x强制JDK 17很多老式教程代码要改对一个毕设来说没有收益反而增加不确定性。2.2 为什么不用MyBatis-Plus也要说清楚我承认MyBatis-Plus的BaseMapper确实省事单表CRUD几乎不用写SQL。但毕设场景下我更建议手写Mapper XML。原因有两条第一答辩老师极大概率会问这个SQL是怎么写的、为什么这么写如果你能当场指着XML讲出LEFT JOIN、乐观锁更新、PageHelper分页拦截的原理比说我调了BaseMapper方法有说服力得多。第二手写SQL能逼你把表关系想清楚。农产品交易平台的查询不是单表能搞定的商品要连商家、连分类订单要连明细这块用MyBatis-Plus顶多算锦上添花真要搞懂业务还得回到SQL本身。2.3 Thymeleaf还是Vue我的最终选择动手前我纠结过要不要做前后端分离。后来还是选了Thymeleaf Bootstrap jQuery。理由很务实题目里写了SSM传统SSM的形态就是服务端渲染Controller方法直接返回视图名是标准打法交易平台这种以页面跳转为主的应用用模板渲染反而比前后端分离更直接前后端分离至少要处理CORS、Token鉴权、跨域Cookie问题多出一周的活对毕设不划算如果你更想展示Vue能力换成SpringBoot Vue也不是不行但要注意两点登录态别再依赖Session换成JWT后端要开启跨域配置。这个话题我放在答辩部分展开。2.4 文件存储先放本地再谈对象存储商品主图、详情图、商家资质图片我在开发环境直接存本地上传目录然后由SpringBoot配置静态资源映射暴露出去。生产环节可以用Nginx指向同一个目录做静态服务。至于MinIO这种对象存储属于加分项我把接入思路放在最后一章不影响主流程。3. 数据库设计一张特产订单是怎么流转的3.1 十二张表的拆解我建库前先用表格把表结构画了一遍最终落成12张表核心结构如下表名作用核心字段user消费者账号username, password, phone, nickname, avatarseller商家账号shop_name, real_name, phone, address, cert_image, statuscategory商品分类name, parent_id, sortproduct商品信息seller_id, category_id, name, origin, price, stock, sales, image, detail, statuscart购物车user_id, product_id, quantityaddress收货地址user_id, receiver, phone, province, city, district, detail, is_defaultorders订单主表order_no, user_id, seller_id, total_amount, status, receiver, phone, address, remark, create_time, pay_time, ship_time, confirm_timeorder_item订单明细order_id, product_id, product_name, product_image, price, quantity, subtotalcomment商品评价product_id, user_id, content, rating, create_timenotice平台公告title, content, create_timecollect商品收藏user_id, product_idadmin管理员账号username, password这张表结构有两个设计主见值得细说。第一order_item里冗余了product_name、product_image、price三个字段这是典型的商品快照思路。如果商家改了价格或者把商品删了历史订单仍然能显示出用户购买时的真实信息。没有这个快照订单页面会突然出现商品名、价格为空的情况这在演示时很丢分。第二orders表冗余了seller_id。商家端查看我的订单时直接按seller_id过滤主表就行不需要从order_item再join商品表绕一圈。冗余字段换查询效率在这个场景是值得的。3.2 价格字段必须用BigDecimal不接受反驳农产品价格很容易出现零头比如12.5元/斤、3.5元/个。如果MySQL字段用doubleJava用Double计算时会遇到一个经典尴尬10.5减去10.2结果可能是0.3000000000000007。这不是什么玄学是二进制浮点数在表示十进制小数时天生存在精度损失。金额、库存相关的计算我在MySQL里统一用decimal(10,2)Java侧对应BigDecimal所有涉及加减乘除的操作都走BigDecimal API。这一步做对了后面统计销售额、绘制折线图时才不会出现差一分钱的尴尬。3.3 订单状态机不允许跳步的状态流转订单状态我用int字段表示语义如下状态值含义对应操作0待付款用户下单后提供模拟支付入口1待发货支付成功后商家在后台看到待发货2待收货商家发货后用户看到物流等待确认3已完成用户确认收货订单闭环4已取消超时未支付或用户主动取消状态流转不允许跳步。我在写更新逻辑时采用了一个小技巧用当前状态作为where条件进行更新只有状态匹配时才允许变到目标状态。update orders set status #{targetStatus}, ship_time now() where id #{orderId} and status #{currentStatus}如果返回的影响行数是0说明前端拿到的状态已经过期直接抛业务异常让前端刷新重试。这个思路和乐观锁异曲同工。虽然订单表没有专门加version字段但靠where条件已经达到了同样的并发保护效果。3.4 分类设计parent_id撑起两级导航农产品分类天然有层级感比如新鲜水果 - 杨梅茗茶专区 - 龙井。我直接用parent_id字段支持两级分类parent_id为0表示顶级分类首页导航按顶级分类分组展示每个顶级分类下挂子分类。查询子分类商品时SQL里可以提前把该顶级分类下的所有子分类id收集起来做in查询。这段逻辑我放在了Service层避免在XML里写死。4. 核心功能实现从注册登录到订单完成的全链路代码4.1 登录注册与密码加密密码坚决不能用明文也不能用MD5。MD5撞库成本太低随便一个彩虹表就能还原常见密码。我选的是BCryptPasswordEncoder每次加密都会生成不同的盐存进数据库的是带盐的哈希值。Bean public BCryptPasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } // 注册时加密 user.setPassword(passwordEncoder.encode(user.getPassword())); // 登录时校验 if (!passwordEncoder.matches(rawPassword, user.getPassword())) { throw new ServiceException(用户名或密码错误); }BCrypt的校验过程自动从哈希中提取盐再比对不需要单独存盐字段。这是目前最稳妥的密码存储方案之一也是面试题密码怎么存的标答。4.2 商品发布与图片上传商家发布商品的页面包含商品名称、产地、单价、库存、主图上传、详情富文本。默认状态下新发布的商品status为0待审核管理员审核通过后变为1上架前台才能搜到。这套先审后上的机制为平台侧争取了管理入口答辩时也是业务完整性的体现。图片上传的核心代码如下PostMapping(/seller/product/imageUpload) ResponseBody public R upload(MultipartFile file) throws IOException { if (file.isEmpty()) { throw new ServiceException(请选择文件); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); // 文件名全部用UUID重命名防止中文、空格、重复名引发URL问题 String fileName UUID.randomUUID().toString().replace(-, ) ext; // 按日期分目录避免单目录文件过多 String datePath new SimpleDateFormat(yyyyMMdd).format(new Date()); String dir uploadDir / datePath; File dirFile new File(dir); if (!dirFile.exists()) { dirFile.mkdirs(); } file.transferTo(new File(dir / fileName)); return R.ok(上传成功, /upload/ datePath / fileName); }这里有两个细节很容易被忽略文件名用UUID重命名能防止用户上传的原始文件名里带中文或空格导致URL拼接异常按日期分目录能让上传目录在长期运行时保持结构清晰。开发时我把uploadDir配置在application.yml里路径是绝对路径后面静态资源映射的坑在第5章详细说。4.3 购物车与下单事务库存校验不能少下单接口是整个项目最惊险的地方流程一共6步根据用户勾选的cartId查询购物车项逐个校验商品status为上架状态、库存充足生成订单主表数据和订单明细快照扣减商品库存product.stock stock - quantity清空对应的购物车项返回订单号跳转到模拟支付页这6步必须整体包在一个事务方法里任何一步失败都要全部回滚。否则会出现订单生成了库存没扣或者库存扣了订单失败这种严重的数据不一致。库存扣减我用了最简单也能讲清楚的方式// 先锁定该商品行 Product product productMapper.selectByIdForUpdate(productId); if (product.getStock() quantity) { throw new ServiceException(商品库存不足); } product.setStock(product.getStock() - quantity); productMapper.updateById(product);selectByIdForUpdate对应的SQL是select * from product where id #{id} for update在MySQL InnoDB默认的RR隔离级别下这条语句会锁住该商品行其他并发事务要等当前事务提交后才能修改。毕设的并发量不大for update已经足够向评委展示我考虑了并发问题。下单方法我还刻意做了另一个设计订单主表和明细分开。主表orders记录订单整体信息order_item记录每个商品项的独立快照这样一张订单可以下多个商品未来统计单品销量也方便。4.4 商家发货与用户确认收货的状态接力商家登录后可以查看待发货订单列表。点击发货时后端接口做了两个校验一是订单状态必须是1待发货二是操作商家的seller_id必须与订单上的seller_id匹配。第二点很容易被忽略如果不做归属校验理论上商家A就能操作商家B的订单虽然前端页面不一定暴露这个入口但接口层面必须防住。用户确认收货时订单状态从2变为3同时更新商品销量orderService.confirm(orderId, userId); productMapper.increaseSales(item.getProductId(), item.getQuantity());这里商品销量累加放到了确认收货阶段而不是下单阶段因为只有用户真正确认收货了才算一次有效成交。在商品列表按销量排序时刷单的干扰也能少一点。评价功能我是挂在已完成订单下面的订单表加了一个commented字段每次评价前检查防止同一订单对同一商品重复好评。评价内容进入comment表商品详情页展示评分和留言。4.5 首页聚合、搜索分页与管理统计首页拆成了三个数据源轮播公告、分类导航、尖货新品列表。列表统一走分页接口保证数据量大时不至于首页塞几百条商品。商品分页查询SQL加了两个动态条件最重要的是把产地也纳入搜索范围select idselectProductPage resultTypecom.farm.vo.ProductVO SELECT p.*, c.name AS category_name, s.shop_name FROM product p LEFT JOIN category c ON p.category_id c.id LEFT JOIN seller s ON p.seller_id s.id WHERE p.status 1 if testcategoryId ! null AND p.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (p.name LIKE CONCAT(%, #{keyword}, %) OR p.origin LIKE CONCAT(%, #{keyword}, %)) /if ORDER BY p.create_time DESC /select把origin加进LIKE条件这个做法很关键。用户可能不搜杨梅而是搜仙居产地词也能命中这正好呼应当初产地信息可视化的设计目标。管理后台的统计页我挂了两个指标订单总量和总销售额。用ECharts画了每日订单量的折线图SQL按create_time分组统计。虽然数据量小但图表一出来整个后台的完成度观感立刻不一样。5. 我在这套代码里踩过的四个真实坑5.1 PageHelper分页在多线程/嵌套查询下的乱分页第一次做商家后台分页时我点击下一页返回的数据却是从第1页开始的全部商品然后在SQL控制台看到某个不求甚解的方法后面多了一条select count(*)。根因是PageHelper基于ThreadLocal机制工作当你调用PageHelper.startPage(pageNum, pageSize)之后它会在下一个被拦截的Mapper查询上自动追加limit并且自动查询count。如果你startPage之后没有立刻调用目标查询而是先调用了别的Mapper方法分页条件就会加到错误的SQL上如果一次请求里连续调用了多个Mapper而最后一个不是你想分页的那个数据就全乱了。我在Service层封装了PageUtils.startPage方法并用注释强制约定startPage之后必须紧接目标Mapper调用中间不许做任何其他数据库操作。分页结果统一用PageInfo包装前端只需要拿pageInfo.list和pageInfo.total连总页数都不用自己算。5.2 Transactional静默失效同类自调用问题有段时间用户下单后我查数据库发现订单生成了库存却纹丝不动。第一反应是Service方法没加Transactional查下来加了怀疑Controller调了两次也没调。最后一步步排查才发现问题出在同类自调用我在CartService的一个方法里直接写了this.createOrder()而this调用不会经过Spring的AOP代理Transactional注解自然就失效了。这就是著名的同类自调用坑。Spring事务是基于代理实现的只有通过代理对象调用的方法才会被拦截。修正方式有两个把下单方法挪到独立的OrderService在CartService里注入OrderService再调用或者在启动类开启exposeProxy用((CartService) AopContext.currentProxy()).createOrder()来强制走代理。我选了前者更干净、也更好解释。5.3 上传的图片刷新后不显示不是文件问题是映射问题图片明明上传到了本地目录浏览器请求却一直404。原因是SpringBoot默认只把classpath:/static/当作静态资源位置上传目录在项目外面根本不在默认处理范围内。解决办法是重写WebMvcConfigurer的addResourceHandlers把URL前缀映射到物理路径Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir /); }这里要注意uploadDir必须以/结尾写成file:/home/farm/upload/。另外页面里的img src千万别存本地绝对路径比如D:/project/upload/20250618/xxx.jpg部署到服务器后路径全乱正确存法是相对URL/upload/20250618/xxx.jpg这样无论是本机还是服务器都能访问。5.4 LocalDateTime被Jackson序列化成一串数字商品列表页的时间字段创建时间一开始显示成了一大串数字看起来像1718672400000。这是因为Jackson默认序列化LocalDateTime时会把它转成数组或时间戳而不是我们习惯的2025-06-18 14:30:00格式。处理方式我用了双保险application.yml里统一配置再在实体字段上补JsonFormatspring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8JsonFormat(pattern yyyy-MM-dd HH:mm:ss) private LocalDateTime createTime;这个坑在答辩演示时特别显眼因为首页、订单列表到处都是时间一旦全变成数字评委一眼就能看出你遗漏了全局配置。6. 部署、演示与答辩让评委觉得你真做过这件事6.1 Maven打包与Docker部署路线本地演示用最直接的方式mvn clean package -DskipTests java -jar target/ssm846-platform-0.0.1-SNAPSHOT.jar数据库连接、上传目录、日志级别全部拆到application.yml再配合spring.profiles.active切换dev和prod环境。如果你是给老师演示这个程度已经足够。如果有云服务器上Docker的成本其实很低。我写了一个精简Dockerfile基础镜像用带JRE的精简版而不是完整JDK最终镜像只有180MB左右启动速度也快。部署时注意把上传目录通过-v挂载到宿主机否则容器销毁后图片全没了。6.2 演示流程怎么走最丝滑强烈建议演示时讲故事线不要按菜单一个个点。我当时的演示顺序用消费者账号注册一个小号搜索杨梅加购、下单、走模拟支付切到商家账号看到那条待发货订单点击发货切回消费者确认收货写一句评价再用管理员账号登录审核一条新商家申请、发布一条公告15分钟能把全部模块串成一个有来有回的完整业务故事。评委顺着故事走一遍对系统的逻辑清晰度会有直观感受讲完之后再让他随便点哪块细节你都不慌。6.3 答辩必问的四个问题我整理了评委大概率会问的四个问题以及我的回答方向SpringBoot和SSM到底是什么关系答SpringBoot没有替代SSM它用starter和自动配置把Spring、SpringMVC、MyBatis整合到了一起底层依然是SSM这套东西。金额为什么不用double答二进制浮点数表示十进制小数有精度损失金额计算要求精确必须用BigDecimal和decimal。库存超卖怎么处理答下单和扣库存放进同一个事务扣库存前用select for update锁定商品行再检查库存保证并发下不会出现超卖。前端后端数据怎么交互如果用了Thymeleaf就答Controller通过Model传值到模板渲染如果你改用了Vue就答Ajax加JSON登录态用JWT。这四个问题答完了评委基本就认定你是真的做过而不是网上找个项目改了名字。6.4 有余力的话三个加分扩展主流程做完之后如果想再加亮点我建议考虑下面三个方向支付模块接入支付宝沙箱或微信Native支付把模拟支付换成真实支付回调商家发货改成支付回调成功后触发。这一步对行业应用的完整度提升巨大。文件存储把上传目录从本机换成MinIO对象存储商品图片URL改成对象存储的公开地址顺便解决了多机部署后图片不同步的问题。消息通知下单、发货、收货这些关键节点用Spring的事件发布机制向外发送通知替代往数据库硬塞消息表。这三个扩展不碰主流程做任何一个都能成为答辩时讲项目亮点的素材而且实现成本都在可控范围内。最后说点经验之外的东西。做这个项目前我最大的误区是以为毕设等于页面多、功能全后来才发现一套系统能不能站住看的是业务闭环和边界意识。农产品交易平台真正难的从来不是注册登录而是订单状态、库存扣减、价格精度、角色权限这几件事在一条链路上怎么互相约束。把这些边界想清楚代码量其实不大但讲出来的时候整套逻辑非常完整。如果你也在做类似题目先把状态机画清楚再动手建表写代码能少走很多弯路。