如果你准备用 SpringBoot 做一个农产品批发服务系统我建议先把“批发”两个字咬住。市面上大部分教学项目都是一个标准电商闭环注册、登录、购物车、下单、支付这套逻辑搬到农产品上会水土不服。我去年协助一个师弟完成了基于 SpringBoot 的农产品产销对接服务平台设计与实现整个过程踩了不少坑也梳理出一套可复用的做法。这篇文章就把从需求拆解、数据模型、核心接口到部署演示的完整思路写出来供正在做计算机毕业设计或者想快速搭建农业交易系统的人参考。这里要先说清楚一个容易跑偏的点标题里的“批发服务系统”“产销对接平台”“产地直供与批发交易管理系统”其实是同一个系统的三个侧面。批发服务偏业务场景产销对接偏撮合能力交易管理偏订单结算。我最后没有把它做成一个普通商城后台而是做成了一个撮合平台加交易管理一体化的系统。后面所有设计都围绕这个判断展开。1. 先想清楚农产品批发系统到底在解决什么问题很多人在接到这个题目后第一件事就是打开 Spring Boot 教程搭 CRUD。我的建议是先别急着写代码花半天时间把批发场景拆清楚。否则到答辩时老师随便问一句“你这个系统跟普通商城有什么区别”很容易答不上来。1.1 批发交易和零售电商的三个本质区别第一个区别是商品粒度和标准化程度。零售电商的商品有稳定 SKU一件是一件库存和价格都相对固定。农产品恰恰相反同一批土豆在不同产地、不同等级、不同采收时间下外观和品质差异很大。批发商买货是“看货议价”不是“看图下单”。所以系统里的商品不能只建一张 goods 表必须把“产品”和“批次”分开。产品是品名比如“红富士苹果”批次才是可以交易的具体货物包含产地、等级、单价、库存、质检信息。这是整个数据模型的起点。第二个区别是价格形成方式。零售价格由商家定好顾客支付就行。批发交易里价格多数是“一单一议”买卖双方可能线下谈好价再到系统里录单确认。所以平台不能只有“立即购买”还要有供货报价、询价记录、订单改价这些能力。即使是毕业设计也至少要做一个“提交供货价格 平台审核 批发商下单”的可控流程才能体现批发场景。第三个区别是交易参与方和结算方式。零售电商主要是 C 端用户对商家支付基本走线上。农产品批发链路更长农户、合作社、产地经纪人、批发商、下游餐饮或零售商每一方都有自己的诉求。而且大宗交易很少一手交钱一手交货常见的是定金加尾款、线下转账后回填凭证、月底对账。做毕设时不需要真接支付网关但应该在系统里预留“待结算单”和“结算确认”的概念不能一下单就显示“交易完成”。1.2 从标题里拆出三个功能域把标题的三个名称放到一起看会发现它们正好覆盖了一个完整系统应该具备的三个功能域。“农产品批发服务系统”偏业务运营要有商户管理、档口管理、商品批次管理、订单管理。“农产品产销对接服务平台”偏信息撮合要有供需信息发布、平台审核、商品检索、直供专区展示。“农产品产地直供与批发交易管理系统”偏交易管理要能把“产地农户发布货源—批发商下单—供货方确认—交货完成—结算”这条链路管起来。我最后做的是这三个功能域的组合没有把它们拆成三个独立项目。用表格表示会更清楚功能域核心模块关键表/字段批发服务档口、商品批次、订单、库存supplier、goods_batch、t_order产销对接货源发布、审核、检索、直供专区supply_info、audit_status交易管理订单流转、结算、统计报表order_item、settlement1.3 毕业设计的功能边界演示闭环比大而全更重要很多同学喜欢把功能清单堆得很满比如接入支付、物流、实时竞价、在线客服。我的建议是做减法。毕业设计最怕的不是功能少而是功能多但每个都做不透。参考我最终敲定的角色和闭环系统里有平台管理员、产地农户可代表合作社、批发商三种角色。核心闭环是一条可演示的完整链路农户登录后填写产地直供货源信息管理员在后台审核审核通过后货源出现在直供专区批发商检索到货源后下单农户确认订单双方确认交货后系统生成待结算记录管理员在数据看板看到当日交易额和商品热度。这条链路只要跑通答辩时老师无论问业务还是问技术你都有东西可讲。而支付、物流轨迹、实时行情、聊天室这些完全可以放在“未来展望”里一句话带过没必要在代码里硬做。2. 技术选型复盘为什么这套组合能扛住毕业设计技术选型不需要追求最新而要根据两个字来判断稳和熟。你熟悉什么就用什么遇到问题能快速查资料才是完成项目的关键。我帮师弟定的方案是 Spring Boot 2.7 JDK 8 MyBatis-Plus MySQL 8.0前端用 Vue 3 Element Plus Axios认证用 JWT缓存看情况引入 Redis。2.1 SpringBoot 版本怎么定先问自己用的 JDK 是什么先说结论如果环境允许用 JDK 8 Spring Boot 2.7.x 是最省心的组合。原因很简单市面上绝大多数教程、博客、错误解决方案都基于这个版本组合MyBatis-Plus 的兼容性也最好。如果电脑上已经装了 JDK 17 甚至 JDK 21我建议直接改用 Spring Boot 3.x但一定要记得两个坑。第一个坑是命名空间的变化。Spring Boot 3 从 javax.servlet 换成了 jakarta.servlet很多老代码里的 import javax.* 会直接报错。第二个坑是部分第三方 starter 的版本没有及时跟上可能在整合时出现不兼容。比如一些老版本的 knife4j 文档工具在 Spring Boot 3 上就不好使。所以选版本时不要只看“最新”先确认团队里所有人能否快速排错。项目Spring Boot 2.7.xSpring Boot 3.xJDK 要求8 及以上17 及以上命名空间javaxjakarta成熟资料多正在增多毕设推荐度高中2.2 持久层、缓存和前端够用就好持久层我推荐 MyBatis-Plus 3.5.x。它的 BaseMapper 可以省掉大量单表 CRUD 代码分页插件也很方便对毕业设计来说效率提升非常明显。虽然很多人说 MyBatis-Plus 在复杂 SQL 上不如手写 XML 直观但农产品系统里真正复杂的 SQL 只有订单统计和看板报表完全可以单独写到 XML 里两者搭配并不冲突。数据库选 MySQL 8.0使用 InnoDB 引擎。InnoDB 支持事务和行级锁这是后面处理库存扣减的关键。如果你用 MyISAM很多并发控制手段根本用不上答辩时也会被追问。缓存方面我给的意见是可选的。如果项目时间充足建议用 Redis 缓存“商品分类”和“热点货源列表”并在答辩时说清楚缓存淘汰逻辑。如果时间紧张先把功能跑通不引入 Redis 也完全不影响主线。与其用一个不熟的中间件不如把 MySQL 查询优化讲清楚。前端如果时间充裕用 Vue 3 Vite Element Plus。如果之前只接触过 Vue 2那就老老实实用 Vue 2 Element UI不要在毕业设计期间额外学一套新框架。图表展示用 ECharts接入成本低效果也好看。2.3 项目分层怎么拆才能不被答辩老师问倒我建议用最经典的五层结构controller、service、mapper、entity、common。另外增加 dto 和 vo 两个包。有人嫌麻烦直接把实体类往外抛短期看代码写得快但答辩时很容易被一句“如果表结构变更会不会影响前端返回结构”问住。我的分层习惯是这样的com.example.agri ├── common // 统一返回结果、异常处理、常量、工具类 ├── config // 跨域、拦截器、MyBatisPlus分页配置 ├── controller // 接收请求不做业务逻辑 ├── service // 业务接口和实现事务写在实现类 ├── mapper // MyBatis-Plus的Mapper接口复杂SQL写XML ├── entity // 数据库表实体 ├── dto // 接收参数比如SubmitSupplyDTO └── vo // 返回给前端的视图对象比如GoodsBatchVO为什么要单独区分 DTO 和 VO我举个例子新增货源时前端提交的字段可能是 productId、batchName、origin、grade、price、stock、description。但后端返回货源列表时前端还需要展示品类名称、供应商名称、审核状态。如果直接把实体返回实体字段会被前端看到而且多表关联时往往要额外包一层。用一个 GoodsBatchVO 把这个批次对应的品名、供应商名、状态字符串拼好前端拿到的就是刚刚好能渲染的结构。这个过程在答辩时可以当成一个“接口设计规范”的亮点来讲。事务注解我习惯加在 Service 实现类的 public 方法上而不是 Controller 上。因为 Controller 只负责接参数和回结果事务范围应该覆盖真正的业务操作比如下单时既要扣库存又要生成订单明细两者必须同时成功或同时失败。3. 数据库设计农产品批次数据模型才是系统的灵魂我见过不少半成品项目数据库表就那么四五张商品表里直接塞价格和库存订单表里又塞了一堆冗余字段。这样的表结构跑演示可以但经不起深问。农产品批发系统最值得认真设计的就是批次、订单、结算这三块。3.1 商品表为什么不叫 goods 而叫 batch前面已经提过农产品交易的核心不是“商品”而是“批次”。我设计时用的两张表product 和 goods_batch。product 表只放稳定的基础信息比如产品名称、产品分类、默认单位、默认图片。它描述的是“红富士苹果”这类品名。goods_batch 表才是一个可以卖的具体货物字段包括批次编号、所属产品ID、供应商ID、产地、等级、规格、单价、库存、上架状态、质检说明、图片、创建时间。这么拆的好处很明显。同一个品名下面可以挂很多批次每个批次有自己的库存和价格。比如今天有两个不同合作社都发布了红富士苹果一个产自山东一个产自陕西价格和品相都不同它们就是两个独立批次。如果强行做成一个商品再添加多规格反而会把批发场景搞变味。下面是一个简化的建表关键字段示例CREATE TABLE goods_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, supplier_id BIGINT NOT NULL, batch_no VARCHAR(32) NOT NULL, origin VARCHAR(64) NOT NULL COMMENT 产地, grade VARCHAR(16) DEFAULT 一级 COMMENT 等级, spec VARCHAR(64) COMMENT 规格如10kg/箱, price DECIMAL(10,2) NOT NULL COMMENT 批发单价, stock INT NOT NULL COMMENT 可售库存, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审 1通过 2驳回, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未上架 1已上架 2已下架, create_time DATETIME );3.2 订单、订单明细、结算单三张表的账目逻辑批发订单不比零售订单。一个批发商可能在一个订单里同时要了土豆和白菜而土豆又可能来自两个不同的批次。所以订单头表、订单明细表一定要分开。订单头表 t_order 存的是整笔交易的主信息订单编号、采购方ID、供货方ID、订单总金额、订单状态、创建时间。一张订单的总额等于明细表里所有行金额之和。订单明细表 order_item 每一行对应一个批次存批次ID、单价、数量、小计金额。这样做的好处是以后如果要打印发货单、做统计报表都能根据订单号把明细拉出来。结算表我建议单独建不要和订单表混在一起。批发交易里“下单”和“结算”不是一回事。用户提交订单后供货方确认双方交货这时订单可能已经完成了但账未必结清。所以我加了一张 settlement 表记录结算单号、关联订单号、应收金额、应付金额、结算状态、确认时间。简化版流程里订单完成时自动生成一条待确认结算单供应商和批发商都可以对它做“确认”操作双方确认后才算一个完整交易闭环。表主要职责关键字段t_order记录一笔批发生意的整体信息order_no, buyer_id, seller_id, total_amount, order_statusorder_item记录订单关联的批次和明细order_id, batch_id, price, quantity, amountsettlement记录订单完成后的对账结算order_id, total_amount, status, confirm_time3.3 库存扣减与并发控制别再用“先查再减”这是很多新手最容易翻车的地方。写下单接口时不少人会这样写先根据批次ID查库存再用 if 判断库存是否够够了再执行 UPDATE 扣减。这套逻辑在单人测试时没问题但要是有两个批发商同时下单两个请求都查出库存为 10然后都判断可以扣 8最终库存可能被扣成 6而不是正确的结果。更糟的情况是库存不够却都下单成功。正确做法是把扣减条件直接写进 UPDATE 语句让数据库用行锁保护数据。比如下单时扣减库存UPDATE goods_batch SET stock stock - #{num} WHERE id #{batchId} AND stock #{num}这段 SQL 的意思是先尝试扣减只有库存足够时才更新受影响行数为 1 表示扣减成功为 0 表示库存不足。它依靠数据库的行锁和原子更新天然避免了并发覆盖。业务代码可以这样补一层判断int rows goodsBatchMapper.deductStock(batchId, num); if (rows 0) { throw new BizException(库存不足或批次已下架); }如果你希望有乐观锁配合可以在 goods_batch 表加一个 version 字段Update 时同时带上 version 条件。我个人的建议是用 MyBatis-Plus 的 Version 注解加乐观锁插件再配合上面的“带条件库存扣减”双保险。订单取消时执行反向操作把库存加回去。这里还有一个细节扣库存和生成订单必须放在同一个事务里否则会出现订单未生成但库存已经扣了的情况。3.4 用户和角色权限不要为了 Security 浪费大量时间很多同学一看到“系统管理”就把 Spring Security 加上配一堆过滤器链和登录流程最后反而不知道怎么接自己的业务接口。我的建议是如果项目时间有限用“拦截器 自定义注解 JWT”完全可以满足需求。用户表 user 里加一个 role 字段可以设计为 ADMIN、FARMER、WHOLESALER 三个值。登录成功后生成 JWT前端后续请求在 Header 里带 token。后端写一个拦截器解析 token 并把用户信息放进 ThreadLocal。再定义一个 RequireRole 注解标注在 Controller 方法上拦截器里校验当前用户角色是否匹配。这样做的优势非常明显不需要理解 Spring Security 复杂的过滤器链遇到的问题也更直观。等答辩被问到权限安全时你能说清楚 token 校验和角色鉴权的实现路径已经足够支撑毕设答辩场景。4. 核心功能实现与代码走读从产地直供到交易结算数据库模型定下来之后业务实现其实就是顺着一条链路走发布货源、审核货源、检索下单、确认订单、生成结算、数据看板。下面挑四个关键节点说。4.1 产地直供信息发布与审核链路产地直供的价值在于减少中间环节所以平台必须对货源信息有审核机制。我给货源表设计了两个状态字段audit_status 表示审核状态status 表示上下架状态。农户新发布的数据默认 audit_status 0在直供专区里查不到管理员在后台看到待审核列表审核通过后 audit_status 1农户再把货源手动上架或系统自动置为上架状态。审核接口核心代码如下Transactional public void auditSupply(AuditSupplyDTO dto) { GoodsBatch batch goodsBatchMapper.selectById(dto.getBatchId()); if (batch null) { throw new BizException(货源不存在); } if (batch.getAuditStatus() ! 0) { throw new BizException(该货源已审核请勿重复操作); } GoodsBatch update new GoodsBatch(); update.setId(batch.getId()); update.setAuditStatus(dto.getPass() ? 1 : 2); update.setAuditComment(dto.getComment()); update.setAuditTime(LocalDateTime.now()); goodsBatchMapper.updateById(update); }前端直供专区查询时只查 audit_status 1 且 stock 0 的批次。这一步用 MyBatis-Plus 的 QueryWrapper 就能完成。很多同学忽略的是“审核意见”字段如果管理员驳回农户得知道原因。我把 audit_comment 放进表里驳回时必填这样演示时流程会很完整。4.2 批发商下单与订单状态机订单状态不建议直接用数字散落在代码里最好用枚举收口。我定义的简化流程是待确认、已确认、已完成、已取消。批发商提交订单后状态为待确认供货方确认后变为已确认双方完成交货后变为已完成任何一方在允许阶段取消订单则变为已取消。状态机用一张表维护最简单public enum OrderStatus { PENDING_CONFIRM(0, 待确认), CONFIRMED(1, 已确认), COMPLETED(2, 已完成), CANCELLED(3, 已取消); public boolean canTransitionTo(OrderStatus target) { switch (this) { case PENDING_CONFIRM: return target CONFIRMED || target CANCELLED; case CONFIRMED: return target COMPLETED || target CANCELLED; default: return false; } } }下单接口比较关键我贴一段伪代码展示调用顺序Transactional public String createOrder(CreateOrderDTO dto) { String orderNo PO System.currentTimeMillis(); // 1. 遍历明细逐个扣减批次库存 for (OrderItemVO item : dto.getItems()) { int rows goodsBatchMapper.deductStock(item.getBatchId(), item.getQuantity()); if (rows 0) { throw new BizException(批次库存不足 item.getBatchId()); } // 2. 生成明细记录 orderItemMapper.insert(buildItem(orderNo, item)); // 3. 累计总金额 totalAmount totalAmount.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } // 4. 生成订单头 orderMapper.insert(buildOrder(orderNo, dto.getBuyerId(), totalAmount)); return orderNo; }注意这里我用的是先扣库存再插订单并且整个方法加了 Transactional。如果中间任何一步失败事务回滚库存扣减也会撤销。这就是为什么前面要强调事务注解必须放在 Service 方法上而不是 Controller。4.3 交易数据看板一个能让你答辩加分的地方数据看板不需要做得多花哨但要能回答两个问题平台今天交易情况怎么样哪些农产品卖得好我用 MyBatis 写统计 SQL按天聚合下单数据SELECT DATE(create_time) AS date, COUNT(*) AS orderCount, SUM(total_amount) AS totalAmount FROM t_order WHERE create_time #{startTime} AND create_time #{endTime} GROUP BY DATE(create_time) ORDER BY date前端把结果丢给 ECharts 画柱状图和折线图一天一张图答辩效果立竿见影。这里有一个非常实用的建议统计金额不要用 Double直接在 SQL 里用 SUM(total_amount)Java 端用 BigDecimal 接收避免精度问题。还有一点如果今天还没有交易数据库查不出当天的分组数据。前端做图之前可以先把连续日期补齐否则折线图会断答辩时看起来不太专业。5. 从开发到部署踩过的坑和我的最终配置建议最后这部分写一些实际开发中容易踩中的细节。它们看起来小但影响体验不小而且稍不留神就会在演示当天翻车。5.1 前后端跨域、Token 与 Session 的三角关系我用的是前后端分离所以第一步就碰到了跨域。本地开发时可以在 Vite 里配置代理把 /api 开头的请求转发到后端端口这样浏览器看到的还是同一个源避开了跨域问题。但如果你把前端打包后想放进 Spring Boot 一起部署或者用 Nginx 反代也要注意后端接口的跨域配置。给后端写一个全局 CorsFilter 是最简单的办法Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }我用的鉴权方式是 JWT服务端不保存 Session所以对这个跨域配置不是特别敏感。如果你用了 HttpSession那就要注意 allowCredentials 和 allowedOrigins 不能设为 *否则浏览器会直接拦截响应。5.2 时间格式化与金额精度两个容易丢分的细节前后端分离后LocalDateTime 默认序列化出来的字符串是“2025-06-01T10:30:00”这种带 T 的格式前端如果不处理显示会很难看。我建议在 application.yml 里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时把所有金额相关的实体字段都定义为 BigDecimal不要用 double。double 是二进制浮点数计算金额会出现类似 19.990000000000002 的问题零售场景都受不了更别说大宗批发。数据库 DECIMAL(10,2) 配合 BigDecimal是最省心的组合。5.3 图片上传放在本机还是 MinIO农产品系统里货源图片和资质图片基本都会涉及。最简单的做法是后端接收 MultipartFile保存到本地磁盘一个专门目录然后通过虚拟路径映射对外提供访问。Spring Boot 里用 WebMvcConfigurer 的 addResourceHandlers 方法配置一下即可。我踩过的一个坑是如果直接把图片保存到项目的 target/classes 或 resources/static 下面重新打包时文件会被清掉演示时图片就丢了。正确做法是保存到服务器固定路径比如 /data/agri/images/然后用一个 uploadDir 配置去读。如果时间允许也可以集成 MinIO把它当对象存储用接口更规范但这会增加不少部署复杂度。毕业设计阶段本机存储已经足够。5.4 打包部署演示的细节最终交付时我给了师弟一套“一键演示”的物料初始化 SQL 脚本、jar 包、前端构建产物、使用说明。后端打包命令很简单mvn clean package -DskipTests java -jar target/agri-platform-0.0.1-SNAPSHOT.jar前端则用 npm run build 生成 dist 目录。我建议用 Nginx 托管前端同时把 /api 路径反向代理到后端 8080 端口。这样演示时只启动 Nginx 和 jar 包浏览器访问前端页面不需要额外开 IDEA。演示前一定要做两件事第一初始化脚本里准备几个已经审核通过的货源、一个已完成的订单、一些最近几天的交易数据这样打开看板不至于空白第二提前测试上传图片的磁盘目录存在并有写权限。很多人现场演示时栽倒不是代码有问题而是环境准备不充分。做完这套系统我最深的体会是技术难点其实不在接口怎么写而在业务流程有没有被模型表达清楚。农产品批发里最值得花时间的三个点——批次、结算、状态机——看起来表象都只是表字段和 if 判断但它们决定了系统能不能被真正使用。如果以后再让我做一遍我仍然会先把这几张核心表画清楚再动手写代码。希望这篇偏实战的记录能给正在做类似毕业设计或想落地农产品交易系统的人提供一点参考。