基于SpringBoot的农贸市场管理系统毕业设计全流程解析

又到了毕业设计选题的时候，我最近被问到最多的问题就是：SpringBoot农贸市场管理系统这种题目是不是太简单了？做出来会不会显得没有技术含量？说实话，两年前我自己接触这个方向时也有同样的疑虑，但真正把一个基于SpringBoot的农产品在线交易平台从零搭起来之后，才发现这个题目的水很深——它表面是个“管理系统”，实际上要求你在一套B/S架构里跑通生鲜电商的完整链路：商品管理、购物车、订单、库存、支付、统计分析全都要有。它的业务复杂度介于“图书管理”和“电商秒杀”之间，既不会让你无从下手，又能把SpringBoot生态里的核心知识点全部串起来，是非常典型的毕业设计优质选题。

这篇文章我会把整个项目的落地过程拆开来讲，内容包括需求边界怎么圈定、技术栈怎么选型、数据库表怎么设计、核心交易链路怎么实现、开发过程中最容易被扣分的几个坑，以及最后论文和答辩怎么准备。不管你是想直接参考这个题目，还是打算在它基础上换个场景（比如社区团购、校园二手交易），这套思路都能复用。

1. 三个关键词帮我圈定了需求边界

1.1 系统里到底有哪几类角色

刚开始拿到这个题目时，最容易犯的错误是上来就写代码。我见过一位同学第一版把系统做成了“商户后台+管理后台”两个界面，消费者端的浏览和下单功能完全没有，答辩时被导师问了一句“你的农产品卖给谁？”，当场就没接上话。

这里要先把标题里的三个关键词拆开理解：

• “农贸市场管理系统”：强调的是线下市场管理侧，比如摊位（商户）管理、市场公告、投诉建议、交易数据汇总。
• “农产品在线交易平台”：强调线上交易侧，消费者可以逛、加购物车、下单。
• “生鲜电商服务系统”：强调业务的电商属性，订单状态流转、库存扣减、支付流程要设计得像样。

把这三个维度合并后，系统的角色应该是四类：

我在项目里最终实现的版本中，消费者走C端页面，商户和管理员共用一套后台管理界面，通过角色权限来控制菜单和数据范围。这样做的好处是页面数量不会失控，同时又能体现“不同角色看到不同内容”的权限设计思路。

1.2 哪些功能必须做，哪些可以直接砍掉

毕业设计不是商业项目，最忌讳“功能堆砌”。我在需求阶段列了一个优先级清单，原则是：先保证主链路完整，再考虑锦上添花。

必须做的主链路功能：

• 用户注册登录（手机号+密码，JWT鉴权）
• 商品分类浏览和关键字搜索
• 购物车增删改查
• 下单（生成订单、扣库存）
• 模拟支付（回调支付结果、更新订单状态）
• 商户端商品上下架、库存维护
• 后台用户管理、公告管理
• 基础数据统计（订单量、销售额、商品销量Top10）

可以后期扩展的功能（论文里写成“未来展望”即可）：

• 优惠券和满减活动
• 菜品推荐算法
• 配送路线规划
• 用户评价和投诉
• 秒杀活动

这里有个很重要的经验：如果时间只有两到三个月，主链路能跑通、能讲清楚就已经超过大部分人了。把4个模块做深，远比把10个模块都做出来但每个都是“增删改查”更有说服力。

1.3 把需求翻译成页面清单

我习惯用“用户故事”来梳理页面。比如“消费者小明在首页看到今日推荐，点击商品详情，加入购物车，结算支付，然后在订单列表里看到物流状态”。每个用户故事对应一组页面，列出来后需求边界就非常清晰。

最终页面清单大致是：

• 消费者端：首页、商品列表、商品详情、购物车、结算页、订单列表、订单详情、个人中心
• 商户端：Dashboard、商品管理、订单处理（发货/缺货）、销售统计
• 管理端：用户管理、商户入驻审核、公告管理、分类管理、系统统计

2. 技术选型不是越新越好，够用且能讲清原理才重要

2.1 选型清单和背后的理由

我做这套系统时用的技术栈如下：

当初没有选Spring Security是因为它的过滤器链、UserDetailsService、权限表达式这套体系对新手来说学习曲线比较陡，很容易把时间耗在配置上而不是业务上。而JWT方案的核心逻辑就三件事：登录后签发token，拦截器校验token，从token中解析用户身份。这个链路自己写一遍之后，对“无状态鉴权”的理解会比直接用框架深得多。

2.2 B/S架构分层的直观理解

面向B/S架构意味着用户在浏览器里访问系统，不需要安装客户端。代码层面上，一次请求的完整链路是：

浏览器（Vue页面或HTML） -> 发起HTTP请求 -> Controller层接收参数、校验请求 -> Service层处理业务逻辑、管理事务 -> Mapper层与MySQL交互 -> 返回数据封装成统一格式 -> 浏览器渲染展示

我在实际开发中严格要求自己遵守“Controller里不写业务代码”的原则。很多同学最终代码的Service层很薄，所有逻辑都堆在Controller里，虽然功能能跑，但答辩时一问“你的业务逻辑在哪一层”，就会露怯。

2.3 开发环境上两个容易卡住的地方

Maven和MySQL的版本搭配是第一个坑。Maven 3.6.3配合JDK 8是安全的组合，SpringBoot 2.7.x原生支持JDK 8，不需要额外配置。如果你用的是JDK 17，则要注意SpringBoot必须使用2.7.0以上版本，否则会报Caused by: java.lang.IllegalArgumentException之类的兼容性错误。

第二个坑是MySQL 8.0的驱动变化。SpringBoot 2.7.x默认用的是com.mysql.cj.jdbc.Driver，如果你在配置文件里写了老版的com.mysql.jdbc.Driver，启动时会告警。最保险的配置是：

spring.datasource.url=jdbc:mysql://localhost:3306/market_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai spring.datasource.username=root spring.datasource.password=你的密码 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

注意serverTimezone=Asia/Shanghai不能省略，否则时间字段的查询结果会和本地时间差8个小时。

3. 数据库设计：钱和库存是两个最容易出错的地方

3.1 核心表清单与关系

数据库设计是整个项目的根，后面的代码都是围绕表结构展开的。我把核心表整理成下面这个清单：

为什么订单要拆成主表和明细表？因为订单和商品是多对多的关系。一个订单里可能有胡萝卜和白菜两样商品，如果把商品名和价格直接放在订单表里，那订单表里的字段就会冗余且难以扩展。拆成orders + order_item之后，订单主表只管总金额、状态、下单人等核心信息，明细表记录每个商品的快照。

3.2 金额为什么必须用Decimal

生鲜商品的价格涉及小数点（比如土豆2.58元/斤），很多初学者喜欢用double或float来存价格，这是一个非常经典的错误。看看这段代码：

double a = 0.58; double b = 0.01; System.out.println(a + b); // 输出 0.5899999999999999

原因在于浮点数在计算机中是以二进制存储的，很多十进制小数无法精确表示。涉及金额的场景必须使用BigDecimal，数据库字段类型用DECIMAL(10, 2)。下单计算总价时也要用BigDecimal而不是先转成double再乘。

[[注意]]：在JSON序列化时，BigDecimal默认会输出成数字，前端展示没有问题。但如果你在计算时把BigDecimal除以100之类的操作，记得用divide方法时必须指定小数位数，比如price.divide(new BigDecimal("100"), 2, RoundingMode.HALF_UP)，否则会报ArithmeticException: Non-terminating decimal expansion。

3.3 库存字段设计：预留扩展余地

生鲜商品的库存单位可能不是“件”而是“斤”“份”，所以product表里我加了unit字段。库存字段名不要用count（这是SQL关键字），最好用stock。另外，哪怕你现在不做并发控制，也要提前在表里留一个version字段，后面做乐观锁扣库存时可以派上大用场。

商品表的建表SQL核心部分大致是这样：

CREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY, category_id BIGINT NOT NULL COMMENT '分类ID', merchant_id BIGINT NOT NULL COMMENT '商户ID', name VARCHAR(100) NOT NULL COMMENT '商品名称', price DECIMAL(10,2) NOT NULL COMMENT '单价', stock INT NOT NULL DEFAULT 0 COMMENT '库存', unit VARCHAR(20) DEFAULT '斤' COMMENT '单位', image VARCHAR(255) COMMENT '商品图片', status TINYINT DEFAULT 1 COMMENT '1上架 0下架', version INT DEFAULT 0 COMMENT '乐观锁版本号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

3.4 订单状态机的设计

订单状态是整个系统里最容易讲出彩的地方。我设计的状态流转是：

待支付(0) -> 已支付(1) -> 备货中(2) -> 配送中(3) -> 已完成(4) 待支付(0) -> 已取消(5) 已支付(1) -> 申请退款(6) -> 已退款(7)

状态用整数存，并单独建一个常量类或者枚举类来定义，千万不能直接在Controller里写魔法数字。比如：

public class OrderStatus { public static final int PENDING_PAYMENT = 0; public static final int PAID = 1; public static final int PREPARING = 2; public static final int DELIVERING = 3; public static final int COMPLETED = 4; public static final int CANCELLED = 5; }

这里说一个经验：订单状态更新时，SQL里一定要带上“当前状态”条件。比如用户点击“取消订单”时，更新语句是：

UPDATE orders SET status = 5 WHERE id = #{orderId} AND status = 0

如果返回的影响行数是0，说明订单已经不是待支付状态了，这时候要提示用户“当前状态不可取消”。这种写法叫乐观锁在状态流转上的应用，能防止两个操作同时把订单状态覆盖掉。

4. 核心交易链路代码落地

4.1 注册登录与JWT鉴权

登录模块我采用的是JWT方案。用户在登录成功后，后端用用户的id、角色和过期时间生成一个token，返回给前端。前端把它存在localStorage里，之后每次请求在Header里带上Authorization: Bearer xxx。

JWT工具类的核心方法如下：

public class JwtUtil { private static final String SECRET = "your-secret-key-change-me"; public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

拦截器里校验token并放行：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String authHeader = request.getHeader("Authorization"); if (authHeader != null && authHeader.startsWith("Bearer ")) { try { Claims claims = JwtUtil.parseToken(authHeader.substring(7)); request.setAttribute("userId", Long.parseLong(claims.getSubject())); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }

注册时密码一定要加密存储，至少使用BCryptPasswordEncoder。千万不要明文存密码，这在论文里体现“安全性设计”时也是一个得分点。

4.2 下单事务的边界：哪些操作要放在同一个事务里

下单看起来简单，但它的原子性边界需要想清楚。我最终把以下四个操作放在一个事务方法里：

1. 校验商品状态和库存是否充足
2. 生成订单主表和订单明细
3. 扣减商品库存
4. 生成支付流水（状态为待支付）

对应的Service方法上加@Transactional注解：

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(OrderCreateDTO dto, Long userId) { // 1. 从购物车或前端传来的商品列表获取items // 2. 遍历items，校验库存 // 3. 计算总金额 // 4. 批量扣库存 // 5. 插入orders和order_item // 6. 插入payment记录 return orderVO; }

rollbackFor = Exception.class这一行值得专门解释一下。默认情况下Spring只能对RuntimeException进行事务回滚，如果你在方法里抛出了一个受检异常（比如自定义的BizException extends Exception），事务是不会自动回滚的。很多同学在这个细节上栽过跟头，我比较推荐自定义异常时直接继承RuntimeException。

4.3 扣库存时用乐观锁防止超卖

这是整个项目里最有技术含金量的点。在第一次测试时，我用两个账号对同一件只剩1份的商品同时下单，结果两个订单都成功了，库存变成了-1。原因很简单：代码里的“先查库存，再更新库存”不是原子操作。

修复方法是把库存校验和扣减合并成一条SQL，同时判断库存数量：

int updated = productMapper.updateStock(productId, quantity);

对应的XML：

<update id="updateStock"> UPDATE product SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{productId} AND stock >= #{quantity} </update>

如果updated == 0，说明库存不足或商品已被修改，此时直接抛出“库存不足”异常，让整个事务回滚。这里没有用数据库悲观锁SELECT ... FOR UPDATE，是因为生鲜商品高频短小的查询场景更多，乐观锁在读多写少的毕业设计流量下完全够用，而且更容易在答辩时解释清楚。

4.4 模拟支付：把接口设计成可以替换的样子

真实对接第三方支付需要商户号、证书和回调验签，这在毕业设计中不太现实。但我采用了一种“接口隔离”的方案，让模拟支付和真实支付能够无缝切换：

public interface PaymentService { PaymentResult pay(Long orderId, BigDecimal amount); } @Service public class MockPaymentServiceImpl implements PaymentService { @Override public PaymentResult pay(Long orderId, BigDecimal amount) { // 模拟支付，固定延迟1~2秒后返回成功 // 更新订单状态为已支付 // 更新支付流水状态为已支付 return PaymentResult.success("模拟支付成功"); } }

前端在支付页调/api/payment/pay，后端直接执行模拟逻辑。答辩时如果你说“这里做了一个支付接口抽象层，如果接真实支付，只需要新写一个实现类替换即可”，这个回答是很加分的。

5. 真实开发中踩过的坑

5.1 前端跨域和统一返回格式

前后端分离之后，本地开发时Vue在8080端口，后端在8081端口，浏览器默认会拦截跨域请求。最初我在Controller里一个一个写@CrossOrigin，非常丑陋也不规范。后来配置了一个WebMvcConfigurer全局跨域：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

同时我封装了一个统一返回格式Result<T>，包含code、message、data三个字段。成功返回Result.success(data)，失败返回Result.error("参数错误")。这样前端只需要拦截一次响应，根据code做统一处理，而不是每个接口各自为政。

5.2 MyBatis-Plus的分页插件没配置就会导致分页失效

使用MyBatis-Plus分页时，selectPage()方法如果不配置分页插件，你会发现它对传入的Page参数无动于衷，直接查出全表。这是因为分页功能依赖MybatisPlusInterceptor里注册的PaginationInnerInterceptor：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

这个坑的症状非常隐蔽，页面能出数据，但数据库里明明有50条记录，第一页却显示了全部。排查办法是看控制台打出的SQL有没有LIMIT关键字。

5.3 前端时间字段显示差8小时

订单创建时间传给前端后，页面上显示的时间比实际时间少了8个小时。原因有两个：一是MySQL连接串没有加serverTimezone=Asia/Shanghai（前面提过），二是Jackson序列化LocalDateTime时默认采用UTC时区。

解决方式是在application.yml里明确序列化格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

实体类里时间字段习惯上用LocalDateTime而不是Date，配合上面的配置后，前后端显示时间就一致了。

5.4 文件上传：图片路径到底存什么

商品图片上传时，我犯过一个错误：直接把上传后的文件完整路径（比如D:/upload/xxx.jpg）存进了数据库。这个路径在本地能用，但换一台机器部署就失效，而且前端浏览器也不会允许直接访问本地的D盘路径。

正确的做法是：把文件上传到项目的静态资源目录下，比如/resources/upload/，然后用http://localhost:8081/upload/xxx.jpg这样的相对URL风格访问。配置一个静态资源映射：

registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadDir + "/");

数据库里只存/upload/xxx.jpg，前端通过后端域名拼接出完整的图片地址。这样项目换服务器后，只要上传目录路径改一下配置，图片就能继续访问。

5.5 统计报表里的小数计算

管理端的数据统计功能里，销售额需要按月汇总。如果在SQL里用SUM(order_item.subtotal)直接计算，由于subtotal是Decimal类型，结果没问题。但如果你把Decimal转成Float去计算汇总，就会碰到浮点数精度问题。

我最终在SQL层面全部使用ROUND(SUM(amount), 2)来处理，Java代码中统计结果的DTO字段类型也用String或BigDecimal来承接，避免JSON序列化带来的精度丢失。

6. 答辩准备和论文结构怎么搭

6.1 做一份演示脚本

答辩时最尴尬的事不是bug崩溃，而是演示到一半不知道下一步要操作什么。我建议提前准备一份演示脚本，按正常用户操作路径走一遍：

• 注册一个新用户，登录
• 在首页搜索“土豆”，加入购物车
• 购物车里调整数量，结算下单
• 订单列表看到待支付订单，执行模拟支付
• 切换商户账号，在订单管理里看到新订单，执行发货
• 切回消费者账号，看到订单状态变为配送中
• 切到管理员账号，查看销售统计，确认金额正确

演示时不要点开那种需要输入复杂数据的表单，尽量用提前构造好的演示账号和数据。也可以准备一个小号，专门用来演示登录注册流程。

6.2 论文的核心章节怎么写

虽然每个学校的论文模板不同，但大体逻辑是一样的。我的论文目录大致如下：

• 第一章 引言：背景、目的与意义、国内外现状
• 第二章 相关技术介绍：SpringBoot、MyBatis-Plus、Vue、Redis、JWT
• 第三章 系统分析：可行性分析、需求分析、用例分析
• 第四章 系统设计：总体架构、功能模块设计、数据库设计
• 第五章 系统实现：每个功能模块的实现和核心代码
• 第六章 系统测试：测试用例、测试结果、性能分析
• 第七章 总结与展望

关于“国内外现状”这一章，很多同学写不好，大段抄别人的话。我的建议是聚焦“农产品电商在国内的生鲜配送模式演进”，比如从传统B2C到前置仓到社区团购，然后落脚在“如何在校园/农贸市场场景设计轻量级交易系统”，这个定位就很自然顺畅。

6.3 常见答辩问题清单

根据我的经验，导师最喜欢问的问题集中在以下几个方向：

1. 为什么选择SpringBoot而不是SSM？——回答框架演进、约定优于配置、生态整合
2. 订单超卖问题是怎么解决的？——乐观锁SQL更新库存、事务回滚
3. 用户密码是怎么存储的？——BCrypt加密，不存明文
4. 如果楼上说的模拟支付换成真实微信支付，需要改动哪些地方？——增加微信支付实现类，配置回调接口，验签等
5. 系统安全性怎么体现？——JWT身份认证、权限拦截器、统一异常处理、密码加密

这些问题要提前用自己的语言组织好答案，特别是“乐观锁”那段，需要能把SQL和事务讲清楚，最好配合代码示意。

6.4 时间安排建议

我做这个项目整体用时大约两个月，主要时间分配是：

如果你的基础比较薄弱，我建议把技术预演的时间拉长一点，先单独做一个涉及“两个表联合查询+新增数据”的小Demo，确认自己对SpringBoot的请求流转和MyBatis-Plus操作熟练后再开始正式开发，否则很容易在项目初期就陷入“到处搜报错”的泥潭。

最后再说几个我亲测有效的小建议

第一，一定要用Git从第一天就开始管理代码，哪怕只有你一个人开发。每完成一个模块就提交一次版本，写论文时按提交记录来回忆开发过程，比翻聊天记录和桌面文件高效得多。第二，开发过程中把遇到的异常和解决方案记录在一个笔记文件里，这部分内容可以直接转化成论文中的“系统调试与问题分析”小节，也是答辩时展示你真实做过项目的证据。第三，系统的命名和注释尽量规范，类名用ProductController而不是productController，注释写清楚业务意图，因为论文里会直接放核心代码截图，代码质量会直接影响老师对论文的印象。

农贸市场管理系统和农产品在线交易平台这个题目，看似朴素，但它把B/S架构下最典型的业务场景完整覆盖了一遍。做扎实之后，你收获的不仅仅是一份能通过答辩的项目，而是对SpringBoot开发流程和电商业务逻辑的整体感知。如果你正在考虑类似的题目，希望这篇复盘能帮你减少一些摸索的时间。