SpringBoot+Vue+MySQL：助农产品采购平台毕设实战全解析

每年到这个时间点，都有不少人在毕设选题上纠结。作为经历过也帮别人改过不少项目的过来人，我一般会给出一个方向性建议：与其做一个泛泛的“网上商城”，不如做一个细分场景的采购平台。比如标题里这种“助农产品采购平台”，表面看是一个电商类系统，但拆开来看，它把SpringBoot、Vue、MySQL这套最经典的Java Web技术栈完整串了起来，同时业务上又有农户、采购商、平台运营方三方角色，复杂度够、工作量够、论文也好写。这篇文章就来完整拆解这个项目从选题、数据库设计、后端接口开发、前端页面联调，到部署上线和论文答辩的全过程，并把我在实操中遇到的各种坑一并列出，希望能给正在做同类项目的同学提供一份可以直接参考的实战笔记。

1. 项目整体设计与业务拆解

1.1 这不是普通商城：助农采购平台的业务特殊性

很多人拿到这种题目，第一反应是“这不就是商城吗，用户注册登录、商品展示、加购物车、下单，完事”。如果你真按这个思路去写，项目做完之后会发现两个问题：一是论文没东西可写，二是答辩时评委随便问一句“你的平台和普通电商的区别是什么”就答不上来。

实际做起来，助农采购平台和普通B2C电商有一个核心区别：普通电商用户是“消费者”，买完就走；助农采购平台的用户结构更复杂，至少包含三类角色——平台管理员、入驻的农户或合作社、下游的采购商（甚至可能是To B的批量采购）。这三类角色对系统的诉求完全不同，所以在功能设计上不能只做一个单角色的CRUD。

举个例子：普通电商的商品类目一般是“服饰、数码、家居”这种通用分类，而农产品更关心的是“产地、季节、品质等级、物流运输条件”。再比如订单流程，普通电商一般是“下单—支付—发货—收货—评价”，助农采购还得考虑预售、按批次发货、商品溯源信息展示等环节。这些业务细节上的差异，最终会直接反映到数据库字段设计、页面交互流程和后端接口设计上，也正好能成为论文里“业务需求分析”章节的重点素材。

1.2 三类角色与核心业务流程梳理

项目立项后，第一件事是先把角色和用例画清楚。这个平台我建议至少拆成三个端，分别是：

• 平台管理员端：负责农户资质审核、商品上下架管理、订单监管、平台数据统计，以及售后纠纷处理。
• 农户/合作社端：负责店铺信息维护、农产品发布、库存管理、订单发货、销售数据查看。
• 采购商/消费者端：负责注册登录、浏览搜索商品、查看溯源与产地信息、购物车结算、在线支付（毕设可模拟）、订单跟踪、收货评价。

你可以把这三类角色的功能做成一张角色-功能对照表，放表格比放一堆文字更直观。实际项目里，后端就是围绕这三个角色设计权限控制接口，前端则对应三个不同的页面路由组。

流程上最核心的一条链路是：农户发布商品 → 管理员审核通过 → 采购商浏览并加购 → 下单生成订单 → 支付（模拟） → 农户发货 → 采购商确认收货 → 评价。这条链路就是整个系统的业务主流程，数据库设计和后端接口都围绕它展开。

1.3 从毕设评分角度反推项目设计

做毕设不能只图“能跑”，要反推评分标准来设计项目。一般来说，毕设评分看重几个方面：工作量是否充足、技术复杂度是否达标、业务逻辑是否完整、论文表达是否清楚、答辩表现是否扎实。

“助农产品采购平台”这个题目之所以好写，是因为它在工作量和复杂度之间找到了一个平衡点：比“学生管理系统”这种纯CRUD项目复杂得多，有角色权限、状态流转、购物车事务、文件上传、统计图表这些常见亮点；又不会像“秒杀系统”“分布式电商”那样，需要Redis、MQ、分布式事务等超出毕设范畴的技术栈。

项目做完以后，你在论文里至少能写出三到四个技术亮点：JWT身份认证与拦截器设计、订单状态机与事务管理、多角色权限控制方案、前后端分离部署方案。这些亮点都是答辩时可以直接讲的“硬货”。

2. 技术选型解析：SpringBoot + Vue + MySQL为什么是黄金组合

2.1 为什么选SpringBoot而不是SSH或SSM

如果你用的教材还是SSH（Struts2 + Spring + Hibernate）或者手写XML配置的SSM，我只能说，该换名字了。现在企业级开发，SpringBoot基本就是默认起点。它的核心优势是“约定优于配置”，靠自动装配和起步依赖（starter）把大量繁琐的Bean配置给省略掉了，配合内嵌Tomcat，后端项目可以被直接打成可执行jar包，本地开发和生产部署都极其方便。

对毕设项目来说，SpringBoot还有一个隐藏好处：社区资料极其丰富。登录认证、分页查询、文件上传，随便一搜就是一堆现成案例。哪怕你只是参考别人的写法，也很少会卡在“这个配置到底怎么写”上。

不过我强烈不建议再手写传统SSM的XML配置来追求“显得有底层功底”。答辩时如果你被问到为什么选SpringBoot，标准答法就是：它解决了传统SSM中大量XML配置带来的开发效率问题，同时依然是市面上面试常考的Java Web框架，使用它能在确保技术成熟稳定的同时，把主要精力聚焦在业务逻辑上。

2.2 Vue前端：Vue2还是Vue3，怎么选

前端框架选择上，Vue是当前毕设项目中占比最高的方案，没有之一。原因很实际：上手曲线比React平缓，模板语法直观，中后台项目配套的Element UI / Element Plus组件库开箱即用，表格、表单、弹窗、分页这些毕设高频组件全都帮你封装好了。

具体选Vue2还是Vue3，我建议分情况：如果你的源码模板是基于Vue2 + Element UI的，那直接用Vue2没问题，胜在稳定、资料多；如果是从零开始写，直接上Vue3 + Vite + Element Plus，因为这是当前新项目的主流组合，启动速度快，打包链路也更新，论文里写“使用了Vue3组合式API”显然比写Vue2更有加分效果。

项目中前端工程标准结构一般是：src/api放axios请求封装，src/router放路由配置（由登录状态做路由守卫），src/store放用户状态管理，src/views按三个角色分别建文件夹。开发阶段用Vite的代理解决跨域，生产阶段把前端项目打包成dist目录交给Nginx托管，同时将后端接口反向代理到SpringBoot服务。

2.3 MySQL选择与数据库访问层的搭配

数据库方面，MySQL是绝大多数毕设项目的标准答案，免费、跨平台、参考文档和面试题覆盖非常全。版本上建议MySQL 8.x，注意8.x和5.7有几个明显的差异点：默认驱动类从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver，连接串里多了serverTimezone=Asia/Shanghai这样的必填参数，字符集方面也建议统一设置为utf8mb4，不然会频繁遇到中文乱码和表情符号存不进去的问题。

持久层框架我用的是MyBatis-Plus，没有用原生MyBatis。原因很直接：原生MyBatis虽然是“正统”，但写单表CRUD的SQL需要大量模板代码，对毕设项目来说效率偏低。MyBatis-Plus提供内置的BaseMapper，像增删改查、分页查询这种基础操作直接调用现成方法，复杂查询再用XML或注解写自定义SQL，既保证了开发效率，也不妨碍上难度。

分页查询是一个容易踩坑的地方：MyBatis-Plus的分页功能必须显式注册PaginationInnerInterceptor拦截器，不然selectPage方法会查回全部数据，这是一个极其隐蔽而且导致前端表格分页失效的问题。

2.4 整体架构与部署视角的决策

我定下来的整体架构是标准的前后端分离结构，前端Vue负责页面渲染和路由控制，后端SpringBoot只提供RESTful API接口，数据层通过MyBatis-Plus访问MySQL。开发环境用Vite代理解决跨域，生产环境用Nginx托管前端、反向代理后端接口。

这种架构有一个现实好处：项目前后端被拆成两个独立工程，答辩的时候你能够很清楚地向评委解释什么叫做前后端分离开发；部署的时候也能实际演示“前端静态文件由Nginx服务，后端采用jar包由Java进程运行”。这些都是面试中高频出现的话题，毕设阶段就亲手做一遍，绝对值。

3. 数据库设计：订单、商品、用户的核心表结构

3.1 数据库设计的整体原则

数据库是一个毕设项目的底盘，表结构设计得好不好，直接决定后端接口好不好写。我看到过很多应届生的项目，最大问题就是“一张表打天下”，用户信息和商家信息全塞在同一个表里，订单和订单明细也不拆分，导致后面写业务逻辑时改都改不动。

设计这个采购平台，我遵循的原则有四个：满足业务需要、适度冗余提高查询效率、关键字段加索引、所有时间字段统一用datetime类型。核心表大致拆分如下：

• 用户表 user（区分管理员、农户、采购商）
• 角色表 role 与用户角色关联表 user_role
• 农产品分类表 category
• 商品表 product
• 商品SKU/库存表（简化为商品表直接管理库存也可以）
• 购物车表 cart
• 订单表 orders
• 订单明细表 order_item
• 收货地址表 address
• 评价表 comment
• 农户/店铺信息表 farmer_info

3.2 用户表和权限相关表设计

用户表是最核心的基础表，一般结合role表和user_role关联表来实现多角色支持。Spring Security的UserDetails对象可以直接对应用户表结构。

sql复制CREATE TABLE `user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `username` varchar(50) NOT NULL COMMENT '登录用户名',
  `password` varchar(255) NOT NULL COMMENT 'BCrypt加密后的密码',
  `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名',
  `phone` varchar(20) DEFAULT NULL COMMENT '手机号',
  `avatar` varchar(255) DEFAULT NULL COMMENT '头像地址',
  `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态：1启用，0禁用',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

为什么密码字段要用255长度？因为BCrypt加密串本身长度约60字符，如果用varchar(50)就会导致认证时校验失败。这种细节看起来不起眼，但经常能卡住项目一整天。用户角色表则维护一个用户对应多个角色的关联关系，后端在登录时查询出该用户的角色列表，然后设置权限。

3.3 商品表和库存设计

农产品和普通商品区别比较明显，商品表除了基础名称、价格、描述之外，需要重点加几个字段：产地、品类（关联分类表）、单位（斤/箱/袋）、物流说明、是否预售以及上下架状态。部分项目还会加一个“溯源信息”字段，用来展示产地介绍或质检信息，这是助农类平台区别于普通商城的一个重要设计点。

关键SQL如下：

sql复制CREATE TABLE `product` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '商品ID',
  `farmer_id` bigint NOT NULL COMMENT '发布商品的农户用户ID',
  `category_id` bigint DEFAULT NULL COMMENT '商品分类ID',
  `name` varchar(100) NOT NULL COMMENT '商品名称',
  `cover_image` varchar(255) DEFAULT NULL COMMENT '商品主图',
  `images` text COMMENT '商品图集，多图用逗号分隔',
  `price` decimal(10,2) NOT NULL COMMENT '售价',
  `stock` int NOT NULL DEFAULT 0 COMMENT '库存数量',
  `unit` varchar(10) DEFAULT '斤' COMMENT '售卖单位',
  `origin` varchar(100) DEFAULT NULL COMMENT '产地',
  `description` text COMMENT '商品详情',
  `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0待审核，1上架，2下架，3审核不通过',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_category` (`category_id`),
  KEY `idx_farmer` (`farmer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='农产品商品表';

商品状态的四个取值是助农平台和普通商城的重要差异：农户发布的商品不是直接上架，而是先进入待审核状态，管理员审核通过后才开放给采购商。这个状态字段在后端接口中一定要做过滤，否则采购商搜索时会把“待审核”和“审核不通过”的商品也查出来，这是很多新手最容易忽略的逻辑漏洞。

库存的设计，我建议在商品表中直接用一个stock字段，下单事务里通过乐观锁或UPDATE ... WHERE stock >= 购买数量的方式扣除库存，避免超卖。如果你的项目想展示更高阶的设计，可以引入单独的库存表配合version字段做乐观锁，论文里也多一个亮点。

3.4 订单表与订单明细表：一对多关系

订单表与订单明细表拆分是必须的，理由很简单：一个订单可能包含多个商品，如果不拆表，一个字段就存不下，存逗号分隔字符串又无法做统计。拆成两张表后，订单表记录订单的整体信息（订单号、用户ID、总金额、订单状态、收货地址快照、创建时间），订单明细表记录每个商品的单价、数量、小计。

订单状态我用整数来存，比存字符串更稳定也更好写索引，取值大致如下：

订单状态流转是最适合在论文里画状态图的业务点。状态字段的更新一定要放在后端Service层，并且用事务控制，同时前端要做相应判断，不能让用户直接修改。比如“待发货”状态的订单只允许农户端调用发货接口，管理员可以查看但不能随意跳转状态，普通采购商也只能取消未支付订单。

考虑到毕设一般不接入真实支付，支付环节可以做一个“模拟支付”，即用户点击付款后生成一条支付记录并更新订单状态为“待发货”。如果你想让项目更完整，可以增加一个payment表，记录支付流水号、支付方式、支付金额和支付时间，这样论文里的“功能模块设计”又多一个层级。

3.5 其他表与索引心得

地址表主要服务采购商，字段包含收货人、联系电话、省市区、详细地址、是否默认地址。评价表则关联订单明细和商品，记录评分、评价内容和回复内容，方便农户在后台查看并回复。农户信息表可以单独抽出来，存执照图片、简介、资质证明等字段，管理员审核后字段才显示在店铺页面。

索引方面，不必所有字段都加索引，但外键字段（用户ID、商品ID、分类ID）和状态字段建议都加上普通索引。实际项目中，订单列表按用户查询、商品列表按分类查询都是高频SQL，索引能带来肉眼可见的查询提速。毕设数据量不大，但答辩时如果你能主动说出“在订单表的user_id上建了索引”，会显得思考更全面。

4. 前后端关键功能实现实录

4.1 登录鉴权：JWT + 拦截器，还是Spring Security

登录模块是毕设项目答辩时的热门提问点，这里有一个很经典的取舍：是直接用Spring Security还是自己写拦截器加JWT。

如果你追求稳定、资料多，建议用Spring Boot集成Spring Security，然后通过JWT做无状态认证。这个方案虽然配置比较多，但本身就是一套成熟的解决方案，关键代码网上也很容易找到。如果你希望项目更轻量，也可以选择自己写拦截器，登录成功后生成JWT，在请求头Authorization中携带token，拦截器里解析并校验。

我实际采用的是Spring Security + JWT的方案，因为它能非常自然地和用户角色结合起来。登录成功后，根据用户角色（farmer、admin、buyer）生成不同权限的token，在Security的过滤器链上增加一个前置过滤器，每次请求时校验token中的用户ID和角色，再写入SecurityContext。

代码层面的核心，就是写一个JwtAuthenticationTokenFilter，继承OncePerRequestFilter，从请求头取Token并解析，然后通过UserDetailsService加载用户信息，最终设置到SecurityContextHolder中。这里最需要关注的坑是：密码加密方式必须统一用BCrypt，passwordEncoder.encode和matches要配套使用，不然会出现“注册后永远登录不上”的诡异问题。

4.2 商品图片上传与访问路径处理

农产品项目商品图片是必备功能，图片上传的本质是：前端通过multipart/form-data把文件POST到后端，后端把文件保存到本地磁盘或云存储，然后把可访问的URL存到数据库中。

这里最容易踩坑的是路径映射。很多同学把文件存到了本地某个绝对路径，比如D:/upload/，然后数据库中保存的是D:/upload/xxx.jpg，结果前端<img src="D:/upload/xxx.jpg">根本访问不到。正确的做法是：后端把文件保存到磁盘后，返回一个以/api/file/开头的虚拟路径给前端，并在SpringBoot中配置静态资源映射，把这个虚拟路径映射到实际保存目录：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Value("${file.upload-path}")
    private String uploadPath;

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

这样配置以后，数据库中只存相对路径/api/file/xxx.jpg，前端拼上后端域名就能正常展示。部署到Nginx之后，也可以把/api/file/直接代理到SpringBoot服务上，或者让Nginx直接映射磁盘目录，灵活性很高。

另外，图片上传后要限制文件类型和后缀，不能只靠前端选择框做拦截，后端要校验Content-Type和文件名后缀，防止有人上传各种奇怪的文件。文件重命名建议用UUID加原始后缀，避免文件名冲突和中文路径导致的编码问题。

4.3 购物车结算与订单生成的事务处理

购物车和订单是业务逻辑密度最高的模块，也是最容易出bug的地方。购物车表的逻辑比较直白：用户ID + 商品ID + 数量，加购时如果已经存在相同记录就累加数量，否则新增记录。列表查询时要连商品表，查出商品名称、封面、价格、库存，前端把总价算出来展示。

真正要小心的是“提交订单”这一步，后端必须在一个事务里完成三件事：校验商品是否还在卖、库存是否充足；扣除库存；生成订单表和订单明细记录。如果不用事务控制，扣库存成功但生成订单失败，库存就白白扣掉了；或者订单生成了但库存没扣完，后面就会出现超卖和负库存。

下面是伪代码级别的执行顺序：

1. 根据提交的购物车条目ID列表，查出商品信息。
2. 逐条校验商品状态和库存，不满足直接抛异常回滚。
3. 使用乐观更新扣减库存（UPDATE product SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count}）。
4. 生成订单主记录，状态为“待付款”。
5. 批量插入订单明细记录。
6. 删除已购买的购物车记录。

在Service方法上添加@Transactional(rollbackFor = Exception.class)，表示任何异常都回滚。这里的rollbackFor不能漏，因为Spring默认只对RuntimeException回滚，如果业务中抛出了自定义Exception，不加这个参数就回滚不生效。

4.4 前端关键页面与接口联调

前端页面上，采购商端最核心的几个页面是：首页/商品列表页（带分类筛选、产地筛选、分页）、商品详情页（带加购和立即购买按钮）、购物车页（支持多选、删除、数量修改）、订单确认页（选择地址、提交订单）、订单列表页（按状态切换）、个人中心页。

无论写哪个页面，前端和联调的套路是一致的：在src/api里定义接口函数，页面里调用函数，拿到返回数据后填充到表格或表单里。Vue3项目中，我建议统一使用setup语法 + ref/reactive管理状态，用async/await处理异步请求，请求前加loading，请求失败用ElMessage提示错误信息。

路由守卫是前端访问控制的关键一环，原理是在router.beforeEach中检查用户是否登录（localStorage是否有token），未登录则跳转到登录页。同时根据用户角色，对/admin/**、/farmer/**这类管理端路由做额外校验，没有对应角色就跳回首页并提示无权访问。

5. 部署与调试：从本地跑通到线上发布

5.1 本地环境准备清单

很多同学项目代码是别人的，本地却一直跑不起来，原因多半不是代码问题，而是环境不一致。建议先列一张环境版本对照清单，确保每项都对齐：

特别提醒：很多老模板项目用的SpringBoot版本是2.7.x，对应Java8；如果你机器上装的是Java17，直接依赖Java8项目可能出现编译失败。反过来，如果用SpringBoot 3.x，因为包名从javax.*改成了jakarta.*，代码里所有import javax.servlet都要改成import jakarta.servlet。你拿到源码后第一件事不是打开运行，而是先确认版本匹配情况。

5.2 SpringBoot后端打包运行

后端开发调试时用IDEA直接run就可以，但最终交付和展示阶段需要会打包。在项目根目录执行：

bash复制mvn clean package -DskipTests

打包完成后，target目录下会生成一个xxx.jar文件。本地测试运行：

bash复制java -jar xxx.jar

如果是服务器部署，并且你不想让服务进程因关闭SSH窗口而退出，推荐用后台运行方式：

bash复制nohup java -jar xxx.jar --server.port=8080 > app.log 2>&1 &

生产环境的数据库密码、上传路径等敏感配置，建议在启动命令中以--参数覆盖默认值，比如java -jar xxx.jar --spring.profiles.active=prod --server.port=8080，这样可以保证源码中不暴露正式环境的敏感信息。

5.3 Vue前端打包与Nginx部署

前端项目需要修改几个配置文件才能正确打包。如果你的项目是Vue3 + Vite，在vite.config.js里设置构建输出的静态资源基础路径，因为默认情况下打包后的资源路径是绝对路径/assets/...，如果你把dist目录放在服务器子路径下，就会出现页面白屏问题。常规做法是设成base: './'，这样资源路径就是相对路径，部署到任何目录都能访问。

js复制export default defineConfig({
  base: './',
  plugins: [vue()],
  server: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
})

执行npm run build之后，项目根目录生成dist文件夹。把dist下的所有文件上传到服务器Nginx的html目录，并在Nginx配置里配好前端路由和反向代理：

nginx复制server {
    listen 80;
    server_name your-domain.com;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里try_files $uri $uri/ /index.html;是Vue Router history模式的关键配置，没有这一行，刷新页面时就会404。如果你用的是hash模式可以不用配，但URL会带一个#，体验差一点。

5.4 部署后的常见自检步骤

部署完以后，不要急着关终端，按照这个顺序自检：

1. 浏览器访问前端地址，看首页是否正常加载，F12查看控制台有没有红色报错。
2. 登录功能是否能正常使用，如果请求接口返回401或403，检查Token是否正常传递。
3. 访问图片接口，看图片能否正常显示，如果不能，优先检查静态资源映射或Nginx代理配置。
4. 提交一个完整订单，确认库存、订单记录、购物车清空都能正常执行。
5. 模拟管理员登录，审核一个商品状态，再切换到采购商端搜索该商品，验证状态过滤是否生效。

整个流程跑通后，项目才算是真正“可演示”的状态。很多同学项目在本地正常，一到服务器就各种白屏，我见过的原因几乎都集中在：前端资源路径错误、Nginx没有配置try_files、后端数据库连接串里serverTimezone缺失、防火墙没有放行端口这四类问题上。

6. 常见问题与排查技巧实录

6.1 启动类与编译阶段的问题

这类问题最常见，也是最容易劝退新手的。

经验之谈：任何报错的第一反应不要直接百度报错原文，先看你自己的版本。比如SpringBoot的spring-boot-starter-parent版本和mysql-connector-java版本不匹配，可能出现启动成功但数据库连接异常的情况。先在pom.xml里把版本调成推荐组合，往往能解决80%的诡异问题。

6.2 数据库相关的坑

MySQL相关的坑在毕设项目中占比极高，我说几个发生率最高的：

• Access denied for user 'root'@'localhost'：大概率是密码不对或当前用户未授权远程访问。本地连不上时，检查密码；服务器上连不上时，检查MySQL用户是否允许从%主机连接。
• Unknown database：说明连接串里的数据库名不存在，需要先手动在MySQL里执行建库语句，再执行SQL脚本导入表。
• 中文乱码：数据库建库时未指定utf8mb4字符集，或连接串没加characterEncoding=utf8。统一处理方式是登录MySQL后执行ALTER DATABASE 库名 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，并把连接串中加上编码参数。
• 时区报错：The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，原因是连接串缺少serverTimezone=Asia/Shanghai，补上即可。
• 连接数过多导致服务卡顿：如果项目运行一晚上后第二天数据库连不上，去MySQL配置里调大max_connections，或者在连接池配置中设置合适的maximum-pool-size和connection-timeout。

建议用数据库客户端（比如MySQL Workbench或Navicat）先把SQL脚本导入并跑一遍，确认没有语法报错和字段类型问题，再启动后端。直接运行项目然后让MyBatis自动建表的方案，对于简单的表可行，但一旦遇到外键和索引，脚本控制会更可控。

6.3 前端白屏与样式异常的排查

前端打包部署后，最常见的两个问题：页面白屏、布局错乱。

页面白屏先看两个地方：一是dist/index.html里引用的CSS和JS路径是不是/assets/...，如果是绝对路径而你把项目放在了子目录，就会白屏，对应修改base: './'；二是看看网络请求里静态资源是否有404，有就说明静态文件没放对位置或Nginx的root配置不对。

布局样式异常则要区分情况。如果是开发环境样式正常、打包后布局异常，优先怀疑是不是CSS被压缩或者浏览器缓存了旧版本，可以强制刷新或清除缓存。如果是个别组件样式失效，比如Element Plus组件样式丢失，很可能是没有完整引入组件库样式，在main.js中确认是否引入了element-plus/dist/index.css。还有一种常见场景是路由切换后页面布局错乱，这往往是因为使用了Vue的<keep-alive>缓存组件，导致组件状态没有正确更新，这时候可以在activated钩子里重新拉取数据。

6.4 接口联调中的跨域与鉴权问题

前后端分离开发时，报错最频繁的就是跨域。开发环境下，前端跑在localhost:5173，后端跑在localhost:8080，浏览器会拦截跨域请求。解决方案有两种：一是前端在Vite中配置server.proxy代理，把所有/api请求转发到后端，这是推荐方案；二是后端写一个CorsConfig，添加addCorsMappings允许跨域，开发时省事，但生产环境一般由Nginx代理解决。

接口报401或403，不是网络问题，而是鉴权逻辑出了问题。常见原因包括：前端没有把Token放进请求头、Token过期、角色权限不足、拦截器放行路径配置错误。排查时可以打开浏览器的“网络”面板，点击某个请求查看Request Headers里是否带上了Authorization；如果没有，去axios的请求拦截器里看一眼。

js复制service.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers['Authorization'] = 'Bearer ' + token
  }
  return config
})

数据库字段的status状态过滤也是一个高频问题，很多同学写商品列表查询SQL时只写了“状态为上架”，但管理员端审核列表、农户端自己的商品列表、采购商端前台列表共用了同一个接口，导致权限混乱、数据交错。最好的方式是按角色拆分接口，由后端保证每个接口返回的是当前角色应看到的数据。

6.5 答辩演示时的突发状况处理

最后说一个容易被忽略的环节：答辩现场演示。我见过不少项目平时跑得好好的，一到演示就掉链子，原因不是代码问题，而是现场环境问题。我的经验有几点：

• 提前把数据库服务启动好，不要在现场等MySQL启动。
• 浏览器提前登录好管理员账号和普通用户账号，不要现场输密码浪费时间。
• 准备好一份常用账号速查表，写着admin/密码、农户/密码、采购商/密码，万一现场需要重新登录也不慌。
• 如果现场不允许联网，确保依赖都打进了本地Maven仓库，前端已打包成dist文件，后端能离线启动。
• 演示前把端口、数据、演示流程至少走三遍，特别是“下单—支付—发货—收货—评价”这条链路，必须做到一次通过。

7. 论文写作与答辩准备要点

7.1 论文章节怎么组织

标题里带了“论文”，说明很多人买这套项目的最终目的是要交出一篇像样的毕业论文。论文结构上，学校的要求会有差异，但计算机类毕设论文的大体框架基本是固定的：摘要与关键词、绪论（背景意义、国内外现状、研究内容）、需求分析（可行性分析、功能需求、非功能需求）、系统设计（总体架构、功能模块、数据库设计）、系统实现（各模块核心代码与截图）、系统测试（功能测试、性能测试）、总结与展望、参考文献与致谢。

很多同学的论文写到最后变成了“贴代码大全”，这是大忌。写系统实现章节，应该先讲清楚这个模块要解决什么问题，然后给出核心代码片段（不要整段贴，控制在关键方法级别），最后放运行截图并解释这个页面实现了什么、解决了什么需求。代码只是论据，业务逻辑和设计思路才是得分点。

7.2 论文里必配的几张关键图表

论文质量很大程度上取决于图纸画得是否规范。以下几张图是计算机毕设论文的基础配置：

• 系统总体架构图：展示前端Vue、后端SpringBoot、数据库MySQL三层结构，以及它们之间的调用关系。
• 系统功能结构图：用树状图展示管理员端、农户端、采购商端三大模块下面各有哪些子功能。
• 业务流程图：重点画“发布商品-审核-下单-支付-发货-收货”的主流程。
• 数据库ER图：用PowerDesigner或draw.io画核心表之间的一对多关系。
• 订单状态图：可以用UML状态图展示订单状态之间的转换条件。

这些图不一定非常复杂，但一定要与你的实际实现对应。答辩评委经验丰富，如果论文里画的流程和现场演示对不上，就会被追问很久。

7.3 答辩高频问题与应答思路

我总结几个答辩时评委最喜欢问的问题，并给出建议思路：

• 为什么做这个题目：不要只说“助农是热点”，要把业务痛点讲出来，比如农产品销售信息不透明、采购商找货源难、农户缺乏线上渠道，你的系统能帮双方打通信息链路。
• SpringBoot的自动配置原理是什么：可以回答@SpringBootApplication由@EnableAutoConfiguration触发自动配置，框架通过META-INF/spring.factories加载大量AutoConfiguration类，根据条件注解决定是否生效。如果平时没吃透，就老实答原理加自己的理解，不要吹。
• JWT和Session有什么区别：核心答两点：JWT服务端不存储会话状态、天然适合前后端分离；Session需要服务端保存会话信息，配合Cookie完成状态维持。然后补充JWT的无状态扩展性好，但也有无法主动失效的问题。
• 订单如何防止超卖：答事务 + 乐观锁更新库存，关键SQL是UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?，通过受影响行数判断是否扣减成功。
• 如果用户量变大了怎么办：这种开放性问题，可以答SQL层面优化（索引、缓存）、引入Redis缓存热点商品、纵向/横向扩展服务、做读写分离。不用答到大厂那种分布式级别，但要让评委知道你理解性能优化的思路。

答辩时最重要的原则是：回答不出来不要硬编，承认自己这个部分考虑不够，然后再把话题往自己擅长的方向上引导，比如“这块我在实操中做得比较多的是订单流程的稳定性，所以重点做了事务控制”。

最后再分享一个实际心得：拿到任何一份源码，第一件事都别急着看代码，先看数据库脚本，把每张表的关系理清楚，然后在数据库客户端里把数据跑一遍；再去跑后端，打开Swagger（如果有）把所有接口过一遍；最后才是启动前端，把页面和接口对应起来。只有你完全掌握了自己项目的数据链路，答辩被问到任何角落才能接得住。如果上来就埋头看代码，做完项目你可能还是说不清“我从登录到下单，系统到底发生了什么”。这份耐心不亏，它会让你的毕设从“能跑”变成“能讲”，而后者才是真正拉开差距的地方。