Spring Boot农产品交易平台毕设实战：从表设计到并发扣库存避坑指南

1. 先搞清楚：农产品交易平台这个选题到底在考察什么

1.1 为什么一个CRUD项目能难住这么多人

接手一套Spring Boot农产品交易平台的源码，准备当作计算机毕业设计二次开发的人，十个里至少有七个栽在同一件事上：以为这东西就是网站后台的增删改查。真正打开源码会发现，用户、商品、购物车、订单、支付流水、评论、后台统计，七八张表互相牵连，前端页面二三十个，数据库脚本还不一定跟他本机环境匹配。于是“下载即跑通”的幻想，在第一行报错面前碎了一地。

老师布置这个题目，想验证的从来不是你会写一张表，而是你有没有完整的业务建模能力。农产品交易不是简单卖货，它涉及选的商品有产地、规格、单位，价格会波动，库存会变化，买家有收货地址，商家有发货动作，管理员要看经营数据。每一环都要能自圆其说。很多人代码能跑，但问他“订单取消之后库存应该回退吗”，直接答不上来，就是这个项目没吃透。

1.2 为什么这个题目在毕设清单里常年存在

这些年源码市场里，Spring Boot农产品交易平台属于出现频率很高的一类，原因不复杂：农产品交易紧贴生活，农户、买家、平台三方角色清晰，做信息撮合和在线支付都有现实意义。对毕设而言，难度不高不低——不用碰推荐算法，不用做高并发，但足以让一个学生把Spring Boot的核心用法展示完整。

同时它又有很大的扩展空间。做基础版就是商品展示加下单；想冲优秀论文，可以引入二维码溯源，在商品详情页展示产地、检测报告图片和采摘时间，再配合后台按地区统计销量。这种灵活度让它可以适配不同学校的要求。我建议拿到这类源码后不要满足于“能跑”，先把自带的核心流程跑通，再挑一个自己写的模块加进去，变成有个人属性的项目，答辩时才站得住。

2. 技术选型：围绕Spring Boot把周边组件一次配齐

2.1 服务端骨架怎么搭

默认基调：Spring Boot 2.7.x + MyBatis Plus + MySQL。为什么不是Spring Boot 3？因为3.0开始强制JDK17，很多学校机房、答辩机器和网上下载的依赖教程还停留在JDK8，你明明可以在项目里用一行java.version解决兼容问题，没必要给自己找麻烦。2.7.x本身就是Boot 2.x的长期维护版本，配合JDK8或11都很顺，社区资料也全。

我还会坚持用MyBatis Plus而不是原生MyBatis。它自带分页插件、逻辑删除、代码生成器，尤其是selectPage方法，做订单列表、商品列表翻页时能省掉大量手写SQL。下面是一个可复用的最小依赖清单，直接把版本写死，减少启动时版本解析的时间：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> </dependencies>

这个组合不需要再手动引spring-boot-starter-jdbc，MyBatis Plus启动器会带上数据源相关依赖。项目里如果出现“ClassNotFound: driver”，大概率是mysql驱动版本和数据库版本不匹配，MySQL8就统一用上面这个8.0.33，老项目里的com.mysql.jdbc.Driver也要改成com.mysql.cj.jdbc.Driver。

2.2 前端与静态资源该选哪条路

农产品交易平台的前端有两条主流路线。一种是传统服务端渲染，用Thymeleaf加Bootstrap，把页面放在resources/templates里，Spring Boot直接读取模板，部署时一个jar包全部搞定，适合时间特别紧、只要求能演示的情况。另一种是前后端分离，后端只出JSON，前端用Vue3 + Element Plus通过代理访问接口，页面更现代，后期扩展方便，也是当下源码项目里更常见的形式。

我倾向于后者，但不是因为它“新”，而是答辩时能讲出的东西更多。你可以在演示中提到“前端是独立工程，后端只负责接口，通过JWT维持会话”，这比“页面和后端代码混在一起”听起来专业得多。当然，前后端分离也意味着要处理跨域，后端加一个CORS配置类，注意拦截器不要拦截OPTIONS预检请求，否则前端登录后列表页依然会报“403”。

2.3 数据库与文件存储的取舍

这块儿容易踩两个极端：一是表建得太少，把订单和订单明细合成一张表，数据乱得没法看；二是表建得太多，光用户就拆成五张表，给自己增加无谓的维护成本。合理的边界是：覆盖用户、角色、分类、商品、购物车、订单、订单明细、地址、评论、支付流水这十来张核心表即可。

农产品和非生鲜电商有一个明显区别：商品必须有产地、单位、检测信息。所以商品表里除了常规的title、image、price、stock，还建议加origin_place、unit、certification、description。这些字段在答辩时就是你“考虑过农产品业务特点”的直接证据。图片存储建议用本地目录映射，配置一个上传路径，再用虚拟路径映射成URL访问；不要一上来就接第三方对象存储，申请密钥、配置桶、设置权限都是额外成本，毕设阶段不值得。

另外要提醒一点：不要用外键约束把表关系绑得太死。很多毕设项目为了画ER图好看，给订单表加了外键指向用户表，结果删除测试数据时被外键卡住，后面查询性能也受影响。我的建议是业务上保留主外键关系，数据库层不建物理外键，只在 Mapper XML 里用JOIN查询。这样既能在ER图上讲清楚关系，又不会在删除和导入数据时被约束误伤。

3. 核心业务模块拆解：从农户注册到订单完成的全链路设计

3.1 用户、角色与登录态

先说角色。用户直接落在user表里，加一个role字段区分BUYER、FARMER、ADMIN，不需要单独做一套RBAC。毕设阶段用角色字符串控制菜单显示和接口权限足够，做细了反而说不清楚。密码必须用BCrypt加密，不能出现任何“明文入库”的代码。使用PasswordEncoder的encode和matches方法，注册时加密，登录时比对哈希即可。

登录后返回JWT，前端把Token放在请求头Authorization里，后端写一个拦截器解析Token，并把 userId 放进ThreadLocal。一个我亲眼见过的bug：有人把JWT密钥直接写死在业务类里，结果换密钥后所有旧Token都失效，用户全被踢下线。正确做法是把密钥放在配置文件里，预留一个版本号字段，想强制下线就更新版本号，不用改代码重打包。

权限这块也要提前设计好。农户端只能管理自己的商品和订单，买家端只能操作自己的购物车和订单，管理员可以查看全量统计。最简单的落地方式是写一个自定义注解@RequireRole，在Controller方法上加注解，拦截器里判断当前用户角色是否匹配。这样接口权限的代码会集中很多，答辩时也容易讲清楚。

3.2 农产品商品模型的两个隐藏难点

第一个难点是计价单位。苹果可以按斤，也可以按箱；茶叶可以按两，也可以按盒。商品表里单价和库存必须绑定同一个单位，否则买家看到“1元/500g”，订单却按整箱算，金额直接错乱。我建议商品表额外存unit和spec_info，展示价格时把单位带上，下单时禁用“前端传单价”的做法，服务端永远以数据库单价为准。

第二个难点是图片和详情。一个商品至少三四张轮播图，如果只在商品表存一个字符串，后面需要动态加图就很麻烦。简单方案是建一张product_image表，外键product_id，再配一个排序字段；懒人方案是用逗号分隔存在商品表的一个字段里。毕业设计不追求极致性能，我更推荐懒人方案，但要在代码里写清楚分隔规则，避免图片路径里本身就带逗号。商品详情建议直接用富文本编辑器的HTML存detail字段，后端不做任何拦截，前端展示时再过滤危险标签。

3.3 购物车与订单状态机

购物车表很直接：user_id、product_id、quantity、checked。难点在于“加购时库存够，结算时不够”的情况。所以在点击结算时，必须重新查一次商品库存和价格，不能直接信任购物车里的快照数据。我见过很多项目里购物车存了价格字段，结算时直接用它，这是很典型的设计错误——商品调价后，购物车里还是旧价格，订单金额就会和商品列表不一致。

订单状态机建议用整型字段status，0待支付、1待发货、2已发货、3已签收、4已完成、5已取消、6售后中。状态流转要在Service层做一个统一方法，比如changeOrderStatus(orderId, targetStatus)里先校验当前状态是否允许跳转，再执行更新。千万不要把状态判断散落在各个Controller里，否则后面想统计“取消率”时会发现数据对不上。

我把这几种主要流转整理成了下面这张表，答辩讲到异常流程时很有用：

每次状态变化都要记一条操作日志，表名叫order_log就行，包含操作人、操作时间、旧状态、新状态、备注。这样老师问“用户投诉订单状态丢失怎么办”，你可以说有日志能追溯，一下子就从“会写代码”上升到“有工程意识”。

3.4 支付环节的毕设级实现

个人开发者没有资质直接对接第三方支付，所以毕设项目里用“模拟支付”是主流。用户点击确认支付后，后端先创建一条支付流水，状态为支付中，然后调用一个本地模拟方法，直接把它改成支付成功，同时更新订单状态、扣减库存。这个流程已经足够表达“你理解支付与订单间的联动”。

如果想更贴近真实，可以接支付沙箱。但我劝你先评估时间：沙箱申请、密钥配置、回调验签这些步骤，即使顺利也要一两天。对大多数同学来说，自建余额支付模拟加一个payment_record表，讲讲清楚支付流水字段（订单号、金额、支付方式、回调时间、状态）就够了。真正加分的是强调一致性：支付成功这个动作必须在同一个事务里完成“更新订单”、“扣库存”、“写流水”，否则中途抛异常会出现钱付了但库存没减。

我在实际项目里还会加一个pay_no字段，每次支付都生成唯一的支付流水号，格式比如PAY20250101001，既方便对账，也能防止支付回调重复处理。将来真要接第三方支付，这个表结构稍微加个transaction_id字段就能对接，不需要大改。

4. 把源码从仓库跑到浏览器：环境、配置、启动三步走

4.1 本地环境版本对齐

拿到任何一套源码，不要直接双击启动，先问自己一句：这个项目依赖的JDK、MySQL、Redis版本是什么。盲启动常见的报错有三类：端口被占、MySQL密码不对、Redis没启动。我整理了一套本地组合，按这个来可以少踩很多坑：

如果在IDEA里打开项目后编译报错，先检查Project Structure里的Project SDK是否选成了别的版本，再检查Maven的runner JRE，两处不一致会出现“invalid source release”的怪问题。启动前先把MySQL和Redis服务开起来，在命令行试一下redis-cli ping，返回PONG再往后走。

4.2 配置文件里最容易出错的三处

第一处是数据库连接串。一定要写全时区和编码参数，尤其serverTimezone=Asia/Shanghai，少了它连接池初始化大概率报时区错误。第二处是Redis地址和密码，如果你的本地Redis没有密码，配置里就不要写password那行，或者用spring.redis.password=空值替代，千万不要在配置里抄一个别人的密码。第三处是上传目录，很多源码写死成/home/upload或者D:/upload，换机器后根本不存在的目录会导致上传接口返回404。可以找一个本地已存在的目录，比如项目根目录下的/data/upload，再通过配置类映射成静态资源访问。

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/farm_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: your_password redis: host: localhost port: 6379 mybatis-plus: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true

上面这份yml是很多项目通用的骨架，唯一要改的是数据库名和密码。改完之后如果启动还是报认证失败，去MySQL里执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';，这能解决MySQL8下部分客户端插件不兼容的问题。

4.3 初始化数据与验证路径

数据库脚本通常是一个farm.sql，导入之前先新建库，再source导入。导入完成别急着启动，先用一条SQL确认基础数据真的进来了：SELECT count(*) FROM user;，如果管理员账号都不存在，说明导入顺序或库选错了。后端启动后，先访问接口文档地址，确认Swagger页面能打开；再用接口工具调用一次登录接口，拿到Token。拿到Token不代表系统完全正常，还要带Token请求一次商品列表，能返回JSON列表，才能说明认证链路是通的。

最后一步是浏览器走业务主流程：注册一个新买家账号，浏览商品，加入购物车，提交订单，模拟支付，然后在商家端把订单置为已发货，买家确认签收，最后写一条评价。走完这条路径，源码才算真正“跑明白”。很多人忽略了这个验证，结果答辩前一天发现支付回调没生效，临时改代码手忙脚乱。

启动过程中如果一直报错，优先对照这个排查表：

5. 实战中最容易翻车的四个技术点

5.1 扣库存逻辑的并发问题

农产品促销场景下，十个人同时下单同一个苹果，如果代码是“先查库存，再减库存”，很容易出现超卖。因为两个请求可能同时读到库存还剩1，然后各自执行减1，最终库存变成-1。毕设阶段不用上消息队列，也不用分布式锁，最简单可靠的做法是条件更新：

int rows = productMapper.updateStock(productId, num); // update product set stock = stock - #{num}, version = version + 1 // where id = #{productId} and stock >= #{num}

如果更新影响行数是0，说明库存不足，立刻给前端返回“库存不足”，不要再往下创建订单。这个方案代码少、逻辑清晰，老师在黑板上画个并发图也很好讲。再进阶一点，可以在订单明细表加唯一联合索引，比如order_no + product_id，防止同一用户重复提交相同的订单明细，这是双保险。

很多人会在Controller方法上加synchronized锁来防超卖，这在单机部署下勉强能用，但一旦项目改成多实例部署就会失效，而且锁的范围不好控制。与其背一个看似“高级”的方案，不如把条件更新讲透，老师更认可这种务实的做法。

5.2 BigDecimal为主的价格精度

价格计算必须用BigDecimal，这条原则值得用红色标出来。Double和Float的二进制存储问题会导致0.1 + 0.2不等于0.3，这在订单金额、退款金额上完全不可接受。数据库字段用decimal(10,2)，Java实体属性用BigDecimal，不要把类型混着用。前端传过来的计价单位是“元”，服务端可以先转成“分”做整数运算，最后再转回“元”，这样可以绕开不同舍入模式带来的误差。

还有一个细节是前端JSON序列化。BigDecimal默认会序列化成数字，如果出现1.00被前端JS变成1，展示倒无所谓，但做金额校验时可能丢精度。可以在字段上加@JsonFormat(shape = JsonFormat.Shape.STRING)，让金额按字符串返回，前端保留两位即可。真要写优惠或运费计算，建议从项目一开始就封装一个AmountUtil，所有金额计算都走它，避免各写各的。

5.3 事务失效的场景识别

订单支付的成功动作必须加事务，最自然的方式是Service层方法加@Transactional。但要注意几个失效场景。第一，非public方法不生效，Spring的声明式事务基于代理，private方法根本无法被代理拦截。第二，同类内部方法调用不生效，一个Service的payOrder调用同类的updateStock，如果updateStock上加了事务，也不会生效，因为内部调用绕过了代理对象。

第三，异常被catch后不抛出，事务照样提交。比如你在事务方法里调了库存接口，库存不足时抛了个RuntimeException，但外层顺手catch并把异常吞了，事务就无法回滚。我排查数据不一致的固定顺序是：看方法修饰符、看是否同类调用、看异常是否上抛、看数据库引擎是不是InnoDB。MyISAM不支持事务，这是个很隐蔽的坑，建表时一定要指定InnoDB。

这是我带一位同学改项目时真实遇到的情况：支付成功日志打出来了，但库存没有扣减。查到最后发现updateStock是private方法，被同一个Service的payOrder内部调用，事务根本没生效。改成独立Service方法后，同一套代码逻辑马上正常。这种问题光看代码很难看出来，所以一定要理解Spring的代理机制。

5.4 时间字段与跨天订单

订单创建时间用LocalDateTime+ 数据库datetime是最常见的组合。但涉及定时任务时，时区问题就来了。比如一个“超时未支付订单，15分钟后自动取消”的定时任务，如果要按数据库时间直接now() - create_time > 15分钟，很可能因为容器时区和数据库时区不同而误判。要么统一把时间存成UTC，展示时再转本地；要么在配置文件中固定spring.jackson.time-zone和数据库连接的serverTimezone为同一个值。

跨天统计也是高频bug源。按日期范围查订单金额，正确的写法是create_time >= '2025-01-01 00:00:00' and create_time < '2025-01-02 00:00:00'。很多人会用between，两边闭区间，结果把1月2日零点整的订单也统计进去，导致月度汇总重复。这类问题不起眼，但答辩老师最喜欢听这种“我踩过坑后来改对了”的细节，比背概念有说服力。

6. 答辩演示的节奏与高频追问准备

6.1 演示时先讲业务再讲技术

演示一定要控制节奏，最忌讳一上来就打开代码。我建议开场先说一句“这是一个面向农户和买家的在线交易平台”，然后用一条用户故事把全流程串起来：农户在后台发布苹果，买家在首页搜索，加入购物车，提交订单，模拟支付，农户发货，买家确认收货后评价，管理员在后台查看商品和订单统计。讲完这条路径，再切回代码页面，按模块讲你负责的重点。

每演示一个功能，停一下，用一句话点出背后技术点。比如登录页可以提“登录后签发JWT，前端每次请求带上，后端有全局拦截器校验”；商品浏览页可以提“分类通过Redis缓存，减少数据库压力”；提交订单时可以提“我用了一个事务保证支付、扣库存、写流水的一致性”。这样整场答辩就变成“业务故事+技术注解”，比单纯对着PPT念要好很多。

时间也要控制好，整个演示最好控制在十分钟左右。不要每个页面都点一遍，核心链路走完，挑两三个模块深入讲即可。老师想看的是你对项目的掌控力，不是你把所有功能都表演一遍。如果你在演示中途发现某个按钮没反应，不要慌，先说出预期行为，再补一句“这个问题是因为当前测试环境的某个数据状态导致的，我可以切换到日志看具体原因”，这比沉默或乱点强得多。

6.2 老师可能会追着问的四个问题

这里总结四个高频问题，每个问题都给一个可以直接说的回答方向：

这些问题不需要背标准答案，关键是理解。建议自己在本地故意制造几个异常场景，比如库存设为0再下单、重复提交同一个订单、支付时手动抛异常，然后观察系统行为。能现场演示“我这里做了异常拦截，所以不会出现超卖”，比你解释十条理论都加分。

7. 源码学习后的扩展思路与一点个人体会

7.1 把源码变成自己项目的三步改造

拿到源码之后，至少要改三处才算“自己的项目”。第一步是把包名、项目名、数据库名全部改掉，别答辩时PPT上写着“基于Spring Boot的农产品交易平台”，代码包里还是别人的com.xxx，老师一眼就看出来。第二步是改前端界面布局和主色调，哪怕只是把首页的横幅文案改成你设计的平台口号，都会显得不一样。第三步是加一个别人没有的小功能，比如“按省份展示农产品产量分布图”，难度不大，但能作为你“独立完成部分”的证明。

改的时候要保留核心模块不动，先在项目里复制出一个新分支，做一个小功能从Controller到Service到Mapper完整走一遍。这个过程比你看十篇教程都有用，因为它逼着你搞清楚现有代码的调用链。我带一位同学改过一套类似的源码，他后来答辩时老师问“你这个新增功能出了问题会怎么排查”，他直接说“我先看控制台日志，再顺着Controller到Service到Mapper分层定位”，全场都认可了。

7.2 我在实际跑完这套流程后的体会

说实话，这类毕设源码真正值钱的不是代码本身，而是把它从“别人的项目”变成“自己能讲清楚的项目”的过程。我每次带同学看源码，都会强调一件事：先不要在意某个具体方法怎么写，先把“一个订单从创建到完成经过了哪些表和哪些状态”画出来，代码只是这条业务线在Spring Boot里的投影。业务逻辑清楚了，后面所有修改都顺理成章。

如果你现在还在纠结启动报错，先按第4章的步骤核对环境和配置；如果你已经能跑了，建议立刻做一次“清空数据库重新走全流程”的测试，很多隐藏问题会在第二次跑通时暴露。最后再分享一个习惯：接手源码的第一天就把数据库表和核心接口的说明写成一个简单的开发文档，后面前端联调、写报告、答辩都用得上，这个投资非常划算。