Spring Boot+Vue在线农产品销售系统毕设实战指南

最近有不少准备开始做毕业设计的同学来问我：在线农产品销售系统这个题目到底能不能选？作为去年刚用这套系统完成毕设、最后连源码带文档一起整理妥当的人，我的回答是：能做，而且很稳。先说明一下，我说的不是让你去网上随便扒一个源码直接交差，而是把这个题目当成一个完整项目去理解、去跑通、去改造。我当时从选题到前后端联调结束，前后大概花了三周，最后附带源码整理成一整套可以运行的项目，今天就把整个过程，包括技术选型、数据库设计、核心功能实现、部署调试和答辩避坑，一次性拆开讲给你听。

这套系统适合谁？适合正在发愁选题的计算机相关专业本科生，也适合打算把课程设计升级成毕设的人。它的业务边界很清晰：农户或管理员发布农产品，消费者浏览、加入购物车、下单，管理后台处理商品和订单。没有太多花哨的算法，但涉及到一个典型电商系统该有的完整流程。比起“图书管理系统”“学生管理系统”这类老掉牙的题目，它更容易在答辩时讲出业务深度，页面展示也更丰满；比起“电商秒杀”“分布式商城”这种容易把自己绕晕的题目，它又足够克制，周期和难度都能控制住。

1. 选题与整体设计：这个项目到底该怎么搭

1.1 为什么农产品销售系统适合当毕设

毕设题目最重要的一点是：评委能听懂，你自己能讲透。农产品销售系统的核心场景大家都很熟悉，买菜、买水果、下单收货，这些日常逻辑几乎没有解释成本。你要向老师说明白的主要是系统怎么通过技术实现这些业务，而不是花大把时间解释这个行业是干嘛的。

另一个原因是数据模型很典型。电商系统该有的实体它都有：用户、商品、分类、购物车、订单、订单项、收货地址。这些实体之间的关联关系天然就是一对多、多对多，非常适合展示数据库设计基本功。而且农产品自带一些特色字段，比如产地、单位、新鲜度、是否预售等，和普通通用商城区分开来，会显得贴合主题。

从开发量来看，这个题目也容易控制。核心功能少说也有六个以上：用户注册登录、商品浏览搜索、商品详情、购物车、订单提交、后台管理，再加上图片上传和简单的数据统计，工作量足够一篇本科毕设。同时又不需要接触消息队列、分布式事务这类高难组件，三到六周做完是正常的。

1.2 技术栈选型：我用的Spring Boot加Vue，为什么

技术选型是第二个必须想清楚的问题。我当时选的是：Spring Boot + MySQL + MyBatis-Plus + Vue + Element UI，前端构建工具用的Vite，后端接口鉴权用JWT。这套组合现在仍然是毕设项目里的主流方案，原因很简单。

后端用Spring Boot，省掉了一大堆XML配置。比如以前写SSH或者SSM，光配置文件就要好几个，数据源、事务、扫描包、拦截器都要手动声明。Spring Boot的自动配置把这些默认行为全部处理好，你只需要在application.yml里写上数据库连接，项目就能跑起来。对一个三周要完成毕设的人来说，这等于把底层的重复劳动砍掉了大半。

MyBatis-Plus在MyBatis基础上提供了通用的增删改查方法。比如实体类User，可以直接调用userMapper.selectById(id)、userMapper.selectList(wrapper)，不用自己写SQL。复杂的多表查询再写XML，这样既有开发速度，又能保留手写SQL的空间。和JPA比起来，MyBatis-Plus对数据库控力度更高，很多同学也更熟悉，排查问题时心里有底。

前端用Vue是因为组件化开发方便，Element UI直接把表格、表单、对话框、分页做好了。页面在视觉上不会显得太“课程设计”，老师打开系统看到的是一个舒服的后台界面，第一印象就会好很多。如果用纯JSP加Bootstrap，也不是不行，但前后端代码混在一起，后面加功能、改样式都会很痛苦。

我给这套组合的基本定位是：不要为了炫技上微服务、上高并发组件。毕设评分的重点不是你用了多冷门的框架，而是你的工程结构清不清楚、业务逻辑有没有漏洞、自己写的代码能不能讲明白。

1.3 功能模块拆分：从登录到订单，哪些是必需品

我不建议一开始就堆功能。先把业务闭环打通，再考虑锦上添花。我的模块划分如下。

从使用角色角度，系统分成三类：管理员、商家（农户）、普通用户。管理员负责商品审核、分类管理和订单查看，商家负责自己商品的上下架和库存维护，普通用户负责浏览、加购、下单、支付模拟、查看订单。

从功能模块角度，最核心的是四个闭环：

• 用户中心：注册、登录、地址管理、个人信息。
• 商品中心：商品分类、商品列表、商品详情、搜索、上下架。
• 交易中心：购物车、下单、减库存、模拟支付、订单状态更新。
• 管理后台：商品管理、订单管理、用户管理、统计仪表盘。

这句话我在写文档时也用过，就是“先打通用户从看到菜到买到菜的全流程”。其它比如首页轮播图、公告栏、评论留言，都属于添加功能，有余力再做。毕设最怕的就是功能表写了十几个，结果核心流程还有bug，那答辩时很难圆场。

2. 数据库设计与源码目录解析

2.1 核心数据表：一张表一张表讲清楚

数据库是整个项目的地基，表结构如果设计得不好，后面写代码到处都不痛快。我实际用了七张核心表，外加一张省去不用的支付表。

这里列出我最关键的几张表的字段设计，不是全部字段，但足够表达核心思路：

表名	关键字段	用途说明
user	id, username, password, nickname, phone, role, avatar, create_time	保存用户和商家信息；role区分管理员、商家、普通用户
category	id, name, parent_id, sort	商品分类；可以用parent_id做两级分类，也可一级先用
product	id, category_id, name, cover_image, detail, price, stock, sales, status, farmer_id, origin, unit	商品表；farmer_id关联商家，status控制上架/下架
cart	id, user_id, product_id, quantity, checked	购物车；checked用于下单时选中标记
orders	id, order_no, user_id, total_price, status, receiver_name, receiver_phone, receiver_address, create_time	订单主表；保存收货人信息快照，见2.2
order_item	id, order_id, product_id, product_name, product_image, price, quantity, subtotal	订单明细表；保存下单瞬间商品信息快照
address	id, user_id, consignee, phone, province, city, district, detail	收货地址表；用户可维护多个地址，下单时选一个

有些同学会把商品图片表单独拆出来，这在项目里可以合并成一个cover_image加一个详情图字段，因为不做多图轮播的话，从简即可。category表里虽然写了parent_id，但如果你的商品分类不超过两页，直接用一级分类也能跑通。表设计不是越多越好，够用并且能自圆其说最重要。

还有一个细节：密码字段不要存明文。我用了Spring Security自带的BCryptPasswordEncoder加密，或者你也可以用MD5加盐。答辩时老师只要看到密码是密文存储，安全这一块印象分就上来了。

2.2 表关系与字段取舍：为什么订单里要存地址快照

很多人会把orders表设计成直接存user_id，然后下单后要查收货地址时再去address表里取。这个设计在初学者眼里没毛病，但实际业务中会有问题：如果用户改了地址，你再去查地址表，拿到的就是新地址，可历史订单里用户当时买的东西是送到旧地址的，这就不符合真实电商场景。

订单表里的receiver_name、receiver_phone、receiver_address这几个字段，我明确是下单时从address表复制过来的快照，这样以后无论用户在个人中心怎么改地址，都不会影响已经生成的订单。同样，order_item表里的product_name和product_image也是快照，因为商品名称和图片可能在后续被商家改掉，但历史订单明细应该保持下单那一刻的样子。

这个设计在答辩时是一个非常好的加分点。老师问“你的订单为什么这么冗余”的时候，你可以从数据一致性和历史数据可追溯两个角度回答，远比说“为了满足同学需求”有力得多。

2.3 源码目录结构：后端分层和前端路由怎么拆

拿到源码或者自己写源码，目录结构要让人一眼看明白。后端我用的是经典分层，controller、service、mapper、entity（或者说domain）、config、common、utils。前端用Vue Router组织页面，views下面建了home、product、cart、order、user、admin等文件夹。

后端需要注意的分层原则是：Controller只负责接收参数和返回结果，不写业务逻辑；业务逻辑放到Service层；数据库操作在Mapper层。比如下单这个动作，Controller里就是接收购物车选中列表和地址信息，调用OrderService.createOrder()，Service里完成减库存、生成订单、生成订单明细、清空购物车，整个过程加上事务。

前端目录里，我单独建了一个api文件夹，把axios请求统一封装。每个页面的请求都从api模块导入方法，而不是直接在组件里写axios.post。这样后期改接口地址只改一处，代码可维护性强很多。源码拿到后，你先看这个目录，基本就能判断这个项目写得好不好，如果所有代码堆在一个文件里，那后续扩展和维护都是噩梦。

3. 核心功能实现：登录、商品浏览、下单全链路

3.1 JWT登录鉴权：从依赖到拦截器

登录模块我推荐用JWT。它和Session最大的区别是状态不保存在服务端，服务端只需要在用户登录时生成一个带签名的token字符串发回去，客户端之后每次请求都在请求头里携带这个token，服务端校验签名和过期时间就行。

实际用到的依赖，如果是Spring Boot 2.x，可以引入：

• io.jsonwebtoken:jjwt-api
• io.jsonwebtoken:jjwt-impl
• io.jsonwebtoken:jjwt-jackson

生成token的代码思路是：登录成功后，通过Jwts.builder()，设置subject为userId，设置过期时间，再用密钥签名。注意这里三个细节：

第一，密钥不要放在代码里写死，或者至少不要放在别人一眼能看到的地方。可以在application.yml里配置一个字符串。虽然毕设不需要特别严格，但别把安全写得太儿戏。

第二，拦截器校验token时，要允许登录接口、注册接口、商品列表接口这些不需要登录就能访问的请求放行。我在WebMvcConfigurer里注册拦截器，通过addPathPatterns和excludePathPatterns配置放行路径。这个操作很简单，但很多新手会忘记放行Swagger或者前端静态资源，导致页面打不开。

第三，token过期时间我设成了24小时。毕设演示时如果token过期又要重新登录，很影响展示节奏，所以稍微设长一点也合理。

拦截器代码的核心逻辑如下：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BusinessException("未登录"); } Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } }

注意实际项目里不能直接把异常抛给前端就完事，应该写一个全局异常处理器，给前端返回统一格式的JSON：状态码、消息、数据。我写了一个GlobalExceptionHandler，用@RestControllerAdvice拦截异常，这样前端才能统一处理错误提示。

3.2 商品分页搜索：MyBatis-Plus的QueryWrapper

商品列表要支持分类筛选、关键词搜索和分页。MyBatis-Plus提供了一套非常方便的条件构造器QueryWrapper。比如：

QueryWrapper<Product> wrapper = new QueryWrapper<>(); if (categoryId != null) { wrapper.eq("category_id", categoryId); } if (StringUtils.hasText(keyword)) { wrapper.and(w -> w.like("name", keyword) .or().like("origin", keyword) .or().like("detail", keyword)); } wrapper.eq("status", 1); wrapper.orderByDesc("sales"); Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);

这里重点说一下like查询。不要在代码里手动拼接字符串百分号，容易产生SQL注入风险。QueryWrapper的like方法会自动做参数绑定，相对安全。另一个容易忽略的是status状态过滤，只显示上架商品。如果忘了这个条件，后台下架的商品还会出现在前台，这是一个非常低级的逻辑bug。

分页插件要单独配置。我在config目录里加了MybatisPlusConfig类，加入分页拦截器：

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

如果不加这个配置，Page对象的分页不会生效，查询结果会直接返回全部数据，到了前端页面却发现数据一直重复，排查起来很头疼。

3.3 下单事务：减库存、生成订单、清空购物车一个都不能少

下单是整个系统最核心、最容易出错的地方。我把逻辑梳理成五步：

1. 根据前端提交的购物车商品列表，查出所有商品最新价格和库存。
2. 计算总金额，写入订单主表。
3. 写入每个商品的订单明细。
4. 循环扣减每个商品的库存，并累加销量。
5. 删除购物车中已下单的商品。

这五步必须在一个事务里完成，任何一步失败都要回滚。否则会出现订单生成了、商品库存没扣，下次下单库存不对的问题。我直接在Service层方法上加@Transactional注解。

还有个容易忽略的点：判断库存不足不是简单的if (stock < quantity)。因为并发情况下，两个用户同时下单，都读到库存是10，都扣减到9，但实际库存可能已经变成负数。毕设环境可能不会遇到这么大的并发，但答辩老师一定会问。

我当时的处理方案是：扣库存的SQL使用原子更新，比如：

UPDATE product SET stock = stock - #{quantity}, sales = sales + #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

如果影响行数等于0，说明库存不足或者商品不存在，立即抛异常回滚。这种方式叫乐观锁的思路，虽然没加version字段，但通过“带条件的原子更新”避免了超卖。这个方案足够应对毕设层面的并发要求，而且代码量很小。

3.4 购物车批量下单的实现细节

购物车批量下单有个小坑：前端传过来的是一个被勾选的商品列表，里面可能包含productId、quantity，也可能同时包含后端不该信任的价格字段。我明确要求前端不传价格，后端下单时根据productId重新查库，以数据库里的价格为准。这样就算有人绕过前端伪造请求，也没法把单价改成0.01元。

下订单时还有一个要考虑的点是生成订单号和计算总金额。订单号我用了时间戳加随机数，格式类似202506011234560001。这样看起来真实，而且方便排序。计算金额统一用BigDecimal，不要用double，不然会出现0.1+0.2精度问题，答辩时老师很容易问到你价格计算方式。

4. 前端页面与交互：从“能跑”到“能看”

4.1 页面结构：首页、商品列表、商品详情、购物车、订单、后台

前端这一块的核心是让业务闭环可视化。我当时做了这些页面：

• 首页：顶部导航、轮播图、推荐商品入口、农产品分类入口。
• 商品列表页：左侧分类，右侧商品卡片，支持搜索和分页。
• 商品详情页：大图、价格、库存、加入购物车和立即购买按钮。
• 购物车页：表格展示商品，修改数量，勾选，批量结算。
• 订单确认页：选择收货地址，展示金额，提交订单。
• 订单列表页：按状态展示订单，支持模拟支付、取消订单。
• 用户中心：个人信息、地址管理。
• 管理后台：商品管理、订单管理、分类管理、数据统计。

页面数量不需要多到吓人，关键是每个页面都有真实交互。比如首页不是纯静态轮播，而是从后端接口读取公告；商品卡片点击后能跳到详情页；购物车取消勾选后再提交订单不会带入未勾选商品。这些细节比多套一个空壳页面重要得多。

Element UI的表格和表单能显著提高样式完成度。下单确认页我用了一个el-steps组件展示“提交订单-支付-发货-完成”的步骤条，页面立刻专业不少。页面布局我统一使用了栅格系统，首页用el-row和el-col分隔。你打开源码后，主要看views和components目录，能很快定位到这些页面。

4.2 接口对接与跨域：axios封装和前端代理

前后端分离后，最常踩的就是跨域问题。前端运行在http://localhost:5173，后端运行在http://localhost:8080，浏览器的同源策略会拦截请求。

我在前端api目录下封装了一个request.js，创建axios实例时设置baseURL为'/api'，然后在Vite配置文件里加一个开发代理，把/api开头且未匹配到前端的请求，转发到http://localhost:8080，并去掉路径里的/api前缀。

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: path => path.replace(/^\/api/, '') } } }

这样开发阶段不需要后端开启CORS，避免跨域和路径重写互相纠缠。当然后端也加了一个CorsFilter作为兜底，但生产部署时我推荐统一用反向代理，比如Nginx。

axios拦截器的核心作用，是在每个请求发出前自动把token加到请求头里：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; });

同时在响应拦截器里统一处理401状态码，比如跳回登录页并提示“登录已过期”。这个封装非常重要，不然每个页面都要自己判断登录状态。

4.3 图片上传：本地目录与静态资源映射

图片上传是又一个容易让项目“看起来有问题”的环节。很多人把图片上传上去之后，前端拿到的路径是类似D:/upload/1.jpg，然后直接拼到img标签的src里，页面当然显示不出来。

正确做法是：后端保存图片文件到一个目录（比如项目的upload/文件夹），数据库里只存相对路径，然后通过配置把upload目录映射成一个URL前缀访问。

我的配置是在application.yml里加：

file: upload-dir: D:/agri-upload/

然后写一个WebMvcConfigurer，把外部目录映射到/resources/upload/**：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadDir + "/"); }

这样前端图片地址就是 http://localhost:8080/upload/abc.jpg。上传接口用MultipartFile接收文件，生成文件名时用UUID加原文件后缀，避免不同用户上传同名文件互相覆盖。这个点十有八九在你答辩演示时会用到，一定要提前测好。

5. 本项目源码的运行与调试：从导入到启动

5.1 环境准备：版本别随便拿最新的

如果你想复现这套源码，最好按照我列的环境来，不然会出现一些莫名其妙的报错。

• JDK：1.8或者11，我用的1.8。
• Maven：3.6以上。
• MySQL：5.7或者8.0。
• Node：16以上。
• 前端包管理器：npm或者pnpm。

最好不要直接用JDK 17加Spring Boot 2.3的组合，虽然大概率能跑，但有一些老项目的依赖可能没有适配。MyBatis-Plus版本和Spring Boot版本也要对应。如果你拿到的源码里pom.xml已经写好了版本，尽量保持一致。

导入后端时我用的是IDEA，选择Import Maven Project，等待依赖下载完成。前端用WebStorm或VSCode都行，在根目录执行npm install，如果网络慢，可以临时切换镜像源。

5.2 初始化数据库和修改配置

源码压缩包里一般会提供一个db.sql或者init.sql。在MySQL命令行或者Navicat里执行这个脚本，数据库会创建好表和初始数据。初始数据里最好带一个管理员账号，比如admin/admin123，方便演示时直接登录后台。

然后打开后端application.yml，按实际环境修改数据库连接：

spring: datasource: url: jdbc:mysql://localhost:3306/agri_sales?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码

端口配置默认8080，如果被占用，改成8081，同时前端代理也要改成8081。这个不一致是新手最常见的启动问题之一。

前端项目启动前，检查.env.development文件中的VITE_API_BASE_URL，如果已经配置过开发代理，甚至可以不单独配置baseURL。我习惯把baseURL留空，全部走代理，因为这样部署到服务器环境时改动最小。

5.3 常见启动报错与排查清单

我把实际运行中遇到的几个典型报错整理成表，照着排查会快很多：

报错现象	可能原因	解决方法
启动后端报“Access denied for user”	数据库用户名密码不对	修改application.yml
报“Unknown database 'agri_sales'”	没有执行SQL脚本	先建库再导表
启动后接口返回“Failed to obtain JDBC Connection”	MySQL未启动或连接被拒	检查MySQL服务和端口3306
前端npm install报错	依赖版本冲突或网络问题	清缓存重装，换镜像源
页面请求返回404	前端代理路径写错	检查proxy里的target和rewrite
商品图片显示不出	图片映射路径或数据库路径不对	检查upload目录映射和数据库路径

还有一个问题很隐蔽：MySQL 8的驱动类名是com.mysql.cj.jdbc.Driver，MySQL 5.7是com.mysql.jdbc.Driver。Spring Boot 2.x会根据连接串自动判断，但如果你手动指定driver-class-name，新旧版本不能混用，否则会报错。这种情况你用navicat连数据库正常，代码里就是连不上，十有八九是驱动类写错了。

6. 毕设答辩与二次开发：源码不是拿去交差，是拿去加分的

6.1 答辩常问问题和回答思路

答辩时老师不会一个字一个代码去审查，但一定会问你几个核心问题。我建议你提前准备：

• “你这个项目用了什么技术架构？”——回答Spring Boot + Vue前后端分离，后端三层架构，数据库用MySQL，鉴权用JWT，ORM用MyBatis-Plus。
• “订单表为什么要保存收货地址快照？”——参考2.2，强调历史数据一致性。
• “库存不足或者并发下单怎么办？”——讲@Transactional回滚和带条件的原子更新SQL。
• “如何区分管理员、商家和用户？”——用user表的role字段，后端拦截器校验接口权限。
• “图片是怎么存储的？上传到服务器还是数据库？”——文件存磁盘，数据库存相对路径，再通过资源映射访问。用BLOB存数据库会让数据库膨胀，不好维护。
• “这个项目的难点在哪里？”——推荐讲订单处理和图片上传统筹，以及购物车批量下单时价格可信性问题。

这些问题都不会超出我在正文里写的范围。你只要对每一个业务逻辑有自己的理解，回答问题就不会卡壳。

6.2 二次开发建议：给项目加一两个有区分度的功能

如果你的时间有余量，我特别建议在源码基础上做一点“有区分度”的改造。这不是让你把别人的东西包装得更好，而是通过自己动手理解整个系统的脉络。

我推荐以下几个方向，难度都不大：

• 在商品详情页增加累计销量排行，SQL用order by sales desc，后端加一个接口即可。
• 在管理后台加一个简单的销售统计，用柱状图展示最近七天的订单数。这里只需要简单分组查询然后交给前端ECharts画图。
• 给订单增加“发货”状态，管理员在后台填写物流单号，用户端可以看到物流信息。
• 给评论模块增加一个简单评分，不用做多级评论，一张表就能完成。

每加一个功能，你都要能说清楚它的表结构、接口流程和页面交互。这些功能代码量不大，但在答辩时会让老师觉得你有独立思考能力，比一个“完美复刻”的项目更有价值。

6.3 个人实操经验：源码拿到手先做三件事

最后分享一点我最想提醒你的经验。不管这套源码从哪来，拿到手之后不要急着直接跑、直接交，先做三件事：

第一，通读后端的所有Controller，了解有哪些接口。每看到一个路由，就记录它是给哪个页面用的。这样就算老师现场随机点一个页面功能，你也能立刻说出对应的接口路径和大致代码位置。

第二，删掉一两个“冗余功能”再重新实现一遍。比如把首页轮播图改成从数据库读取，把原先写死在页面的数据改成接口动态返回。这种二次改造规模很小，但对理解前后端数据流动非常有帮助。

第三，把代码里的注释改成自己的语言。不是改得一塌糊涂，而是把关键方法上方的注释重新整理一遍，加上自己理解的业务说明。这样如果老师让你现场打开某个文件讲解，你能讲得比照着注释念自然得多。

我在做这套在线农产品销售系统时，最深的感受是：它的难度不在于代码量，而在于能不能把一个看似简单的业务流程，用工程化思维拆解成数据库、接口、页面三层，并且在每一层都处理好细节。商品图片能否显示、下单后库存是否同步、权限是否生效，这些细节决定答辩现场是顺利演示还是手忙脚乱。

如果你正准备做这个题目，我的建议是先从数据库表结构开始看，再打开商品列表接口跟前端页面做一次联调，把完整购物流走通一遍。这个过程走通之后，整个系统对你来说就不存在理解盲区了。到时候不管是答辩、写报告还是后续找工作把项目写进简历里，你都能说得头头是道。