农产品销售管理系统全栈开发实战：从设计到答辩-AI智能范式网

1. 为什么这类系统成了毕业设计里的“常青树”

每年带毕业设计都会遇到不少选题困难的同学，前几天一个学弟来找我，说自己想做个电商类项目，但又怕烂大街。聊到最后我们达成一个共识：电商确实多，但农产品销售管理系统这个方向，属于“看着普通、做着舒服、答辩有料”的典型代表。

为什么这么说？先看技术栈——Spring Boot + Vue这种前后端分离的组合，在Java就业市场上属于绝对的主流配置。企业里中小型管理系统十有八九是这个架构，你把这个项目做完写进简历里，HR看得到、面试官问得动，不像某些偏门框架聊起来双方都尴尬。

再看业务域。农产品销售不同于普通商品，它有自己的一套逻辑：农户供货、仓库入库、按批次管理、新鲜度控制、价格随行就市、订单可能要按斤按件拆分。这些业务规则一旦展开，足够支撑少则几张表几十个接口、多则十几张表上百个接口的完整系统设计。论文里的“需求分析”“数据库设计”“核心模块实现”这几章，素材完全够写，答辩评委也有东西可问。

还有一层更实际的意义：课程设计通常只让你写一个C/S端小程序，而毕业设计要求你具备“全栈闭环”的能力。从建表到写接口、从调接口到渲染页面、从本地跑通到部署上去，这一整条链路走完，你才算真正把学校教的东西串起来了。农产品销售管理系统恰到好处地覆盖了这些环节——它不难到让你放弃，但也绝不简单到让你划水。

这篇文章我就以实际做过的模拟项目X为例，把从环境准备、数据库设计、后端接口开发、前端页面联调、部署上线到论文写作的完整过程拆开讲。每一步都会说明为什么这么做、踩了什么坑、换成你会怎么避免。适合准备做这类系统的人，也适合已经开工但卡在某个环节的人，直接对着抄就行。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 开发前的设计决策：先想清楚再动手

2.1 技术选型不是越新越好

做毕业设计最容易犯的毛病是“技术兴奋”。听说了个新框架就忍不住往里塞，觉得不用的新技术就落伍。我见过有人非要在农产品销售系统里上微服务架构，还有人想用Python重写后端换换口味。我的建议是：毕业设计的技术选型，稳定大于新颖，熟悉大于唬人。

Spring Boot 2.x + Vue 2.x/3.x + MySQL 8 + MyBatis Plus，这一套组合在市面上积累了大量教程和踩坑记录，哪怕你遇到神奇报错，搜索引擎一搜就能找到同款问题。MyBatis Plus比起原生MyBatis少写大量XML配置，对新手非常友好；Vue配上Element UI，做管理后台简直是开了加速器。

如果你对版本有纠结，可以这样处理：Spring Boot用2.7.x（稳定、教程多），Vue用3.x配Element Plus（Vue 2已停止维护，新项目没必要再选）。MySQL用8.0以上，注意驱动坐标要带cj后缀。Redis这种非必需组件可以先不加，等核心功能全部跑通后再考虑用缓存优化一下热点数据。

2.2 两种常见架构模式的取舍

我见过很多同类系统的设计文档，大体可以分成两类：

第一类是前后端分离，后端只提供JSON接口，前端用Vue脚手架独立工程开发，部署时Nginx处理静态页面、反向代理后端。这种方式贴近企业实际开发流程，调试方便，也是当前的主流模式。

第二类是服务端渲染，用Thymeleaf模板引擎把页面直接嵌进Spring Boot工程里。优点是只有一个工程、部署简单，缺点是你前端的知识积累基本白费，写复杂交互非常痛苦，论文里也不太好展示“前后端分离架构”这种亮点。

如果你基础还不错，强烈建议选第一类。哪怕部署的时候多几步操作，交换回来的却是两个清晰独立的子系统——答辩的时候也可以明确地告诉评委“前端请求的是这些接口，后端返回的是这样格式的数据”，表达能力直接上一个档次。

2.3 数据库设计要从业务反推

很多人在建表阶段就开始痛苦，其实原因只有一个：没先想清楚业务场景。农产品销售系统里的核心角色可以先用一句话梳理：

农户/供应商：维护能供应什么农产品，什么价格。
管理员：审核农产品上架、管理库存、看销售数据。
普通用户（C端）：浏览农产品、下单、支付（模拟）、查看订单。
仓库/运营人员：处理出入库，记录损耗。

从这几句话就可以推出基础表结构：用户表、商品分类表、农产品表、库存表、订单表、订单详情表、供应商表、进货单表、公告表、购物车表。再细一点可以加轮播图表、收货地址表、操作日志表。

我见过不少人一上来就想把表设计得非常“完备”——字段加到三十个，外键到处飞。实际结果往往是字段冗余、关联混乱，写SQL时把自己绕晕。建议遵循一个原则：先画一张简单的ER草图，把表的主从关系理清，再逐步加字段。表之间的关系优先用逻辑外键（比如在订单详情表里存一个商品id），不要建物理外键，毕业设计阶段省去一堆级联删除的困扰。

提示：数据库设计的质量直接决定后面开发效率。答辩评委最喜欢问“你这张表为什么要有这个字段”，所以每个表都要能讲出设计理由。

2.4 接口风格与统一返回格式

前后端分离开发有个不成文的约定：接口返回结构必须统一。我最常用的是三段式JSON：

json复制{
  "code": 200,
  "message": "操作成功",
  "data": { }
}

后端可以定义一个Result类，所有Controller的返回类型都套用它。这样前端在axios响应拦截器里就能统一处理code，不用每个页面单独判断成功失败。这个习惯也是公司里代码评审的重点项——接口返回结构乱七糟八是典型的坏味道。

另外，接口路径命名建议遵守REST约定：/api/product列表、/api/product/{id}详情、/api/product新增或更新、/api/product/{id}删除。虽然没有必要100%严格REST化，但一致的风格让前端同学（哪怕是你自己）省心不少。

3. 环境准备与工程初始化：少走弯路的完整清单

3.1 本机环境版本对照

网上很多教程不讲版本，照抄之后疯狂报错。这里给出我实测下来比较稳的组合（以Windows系统为例）：

组件	版本	备注
JDK	1.8 或 11	Spring Boot 2.x都能跑，建议JDK 8
Maven	3.6.3+	配置阿里云镜像加速依赖下载
Node.js	14.x 或 16.x	Vue 3配Node 16比较稳
MySQL	8.0.x	安装时记住root密码，字符集选utf8mb4
Navicat	任意	可视化建表更方便
IDEA	2022+	装Lombok插件

有一个细节很多人忽略：MySQL 8的JDBC驱动坐标已经变了，不再用com.mysql.jdbc.Driver，而是com.mysql.cj.jdbc.Driver，并且要设置时区。连接串建议写成：

code复制jdbc:mysql://localhost:3306/agricultural_sales?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai

不写时区的话很容易在启动时遇到奇怪的时区报错，当时还以为是驱动问题，折腾了快两个小时才发现是时区闹的。

3.2 阿里云镜像与依赖下载

Maven第一次导入Spring Boot项目时，下载依赖慢到怀疑人生。解决方式是在~/.m2/settings.xml或IDEA的Maven配置里加入阿里云镜像：

xml复制<mirror>
  <id>aliyunmaven</id>
  <mirrorOf>central</mirrorOf>
  <name>阿里云公共仓库</name>
  <url>https://maven.aliyun.com/repository/public</url>
</mirror>

配完之后，IDEA里记得把Maven的Home Directory和Settings File指到正确位置。不要只在全局改，项目的pom.xml里也请统一检查。这一步做完，后面依赖秒下，体验完全不同。

3.3 创建Spring Boot后端工程

推荐直接用IDEA的Spring Initializr创建工程，Group填com.example，Artifact填agricultural-sales-server。依赖勾选：

Spring Web
MySQL Driver
MyBatis Framework
Lombok

创建完工程后在pom.xml里加上MyBatis Plus和Hutool等常规库。MyBatis Plus建议用老版本3.5.x的mybatis-plus-boot-starter，注意它跟Spring Boot 3不兼容，所以别把Boot的版本升到3.x。这一点一定记住了——Spring Boot 3要求JDK 17，又换了一整套Javax到Jakarta的包，你跟着老教程写代码会大面积报错。

3.4 创建Vue前端工程

用Vue CLI创建前端工程：

bash复制vue create agricultural-sales-web

选Manually select features，勾选Router和Vuex（或Pinia），CSS预处理器选Less/Sass都行。创建完成后，安装Element Plus和axios：

bash复制npm install element-plus axios

如果你Uniapp或前端基础一般，建议不要一开始就研究各种工程配置，老老实实地把App.vue改成布局页、router/index.js里配置路由、api目录下封装axios请求，这样一个最小可运行骨架就是后面所有页面的容器。

注意：跨域问题先别慌。开发阶段可以在Vue工程的vue.config.js里配置devServer代理，把/api开头请求转发到localhost:8080后端；生产部署阶段则用Nginx反向代理。两种方式都会在后文演示。

4. 数据库表设计与核心SQL：一张表都不多余的建模思路

4.1 农产品电商的“三表核心”

农产品销售系统表不少，但真正的核心是这三张：

product（农产品表）：存基础信息，如名称、图片、分类、单价、单位、产地、上架状态。
stock（库存表）：存库存数量和批次信息，这里有个重要字段是batch_no，同一批进货的农产品要能追溯。
orders（订单表） + order_item（订单明细表）：一对多的关系，订单主表存总金额、状态，明细表逐行记录每种商品、单价、数量。

以product和stock的关系为例，有两个设计方向：一个产品一条库存记录，或一个产品多批次库存记录。实际做下来，带批次的方案在写“库存变动记录”和“保质期预警”时很灵活，展示出来的功能点也让评委眼前一亮。

4.2 一张可以直接用的建表SQL

我用一个简化的示例说明核心建表思路，你可以直接复制改改：

sql复制CREATE TABLE `product` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL COMMENT '农产品名称',
  `category_id` bigint DEFAULT NULL COMMENT '分类id',
  `price` decimal(10,2) NOT NULL COMMENT '销售单价',
  `unit` varchar(10) DEFAULT '斤' COMMENT '计价单位',
  `origin` varchar(64) DEFAULT NULL COMMENT '产地',
  `image` varchar(255) DEFAULT NULL COMMENT '主图地址',
  `status` tinyint DEFAULT '1' COMMENT '1上架 0下架',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='农产品表';

sql复制CREATE TABLE `stock` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `product_id` bigint NOT NULL,
  `batch_no` varchar(32) DEFAULT NULL COMMENT '批次号',
  `quantity` decimal(10,2) NOT NULL COMMENT '剩余数量',
  `unit` varchar(10) DEFAULT '斤',
  `purchase_price` decimal(10,2) DEFAULT NULL COMMENT '进货单价',
  `purchase_time` date DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存表';

订单表设计时要注意一点：金额字段不要用float或double，必须用decimal，金额计算才精确。数量也建议用decimal(10,2)，因为农产品可能按“1.5斤”售卖，用整数会非常尴尬。

4.3 用MyBatis Plus还是手写SQL

很多刚接触的人搞不清到底该用MyBatis Plus的BaseMapper接口直接CRUD，还是手写复杂的XML SQL。我的经验是：基础CRUD全部用MyBatis Plus的内置方法，涉及多表关联、统计报表、条件分页的，再写自定义SQL。

举个例子，“后台管理首页的销售统计”这种需求，一般涉及sum、group by、between，如果全用QueryWrapper写，可读性极差。直接写XML里的自定义结果映射更清晰：

java复制@Select("SELECT DATE(create_time) AS day, SUM(total_amount) AS amount " +
        "FROM orders " +
        "WHERE create_time BETWEEN #{start} AND #{end} " +
        "GROUP BY DATE(create_time) " +
        "ORDER BY day")
List<DailySaleVO> selectDailySale(@Param("start") String start, @Param("end") String end);

这么写不仅在代码里一眼能看懂业务逻辑，SQL还能直接拿到数据库客户端跑一遍验证结果。

4.4 初始化数据要一次到位

写完建表语句后别急着写代码，先准备几条基础数据。农产品销售系统一定要有一份像样的测试数据，否则前端页面开发时会极度痛苦——列表空荡荡，看不出效果，自己也验证不了分页。

推荐准备：10个分类、40个商品、3个供应商、2个管理员账号、1个普通用户账号、6条不同状态的订单（待付款、已支付、已发货、已完成、已取消分别来一条）。每次改完表结构后，用统一的SQL脚本重新初始化，后续反复开发时能省不少事。

5. 后端核心模块开发：从登录鉴权到订单状态流转

5.1 登录与JWT鉴权的坑

用户登录是几乎所有管理系统的入口。最稳妥的方式是用户名密码校验后签发JWT令牌，前端把令牌放进请求头Authorization: Bearer xxx，后端用拦截器统一校验。

Spring Boot里我建议直接用jjwt库，版本要选0.9.1或者较新的0.11.x，因为0.9.1依赖的javax.xml.bind在JDK 11以上需要额外引入。如果你用的JDK 8，问题不大；用JDK 11，反而建议直接上0.11.x。

拦截器里只做两件事：排除登录和验证码接口，其余接口解析Token并存入ThreadLocal。别把用户id放Redis里再查一遍，性能没必要，直接用Token里的claim携带用户id就行。把用户对象每次从数据库里查出来塞到request上下文里，写完代码你会发现控制器里取用户简直不要太爽。

5.2 商品模块的分页与条件查询

商品列表是高频接口，往往集合了分页、关键词搜索、分类过滤、价格排序等多种条件。MyBatis Plus的Page对象可以这样用：

java复制public Page<ProductVO> getProductPage(int page, int size, String keyword, Long categoryId) {
    Page<Product> p = new Page<>(page, size);
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    wrapper.like(StrUtil.isNotBlank(keyword), Product::getName, keyword)
           .eq(categoryId != null, Product::getCategoryId, categoryId)
           .orderByDesc(Product::getCreateTime);
    return productMapper.selectPage(p, wrapper);
}

这里需要引入一个VO层：不要把实体类直接返回给前端。实体类里是敏感字段（如purchasePrice）或多余字段（如createTime），VO可以只选择需要的属性。第一次做项目的人往往觉得实体直接返回省事，到后面发现问题时再重构成本就高了。

5.3 下单与库存扣减的顺序绝不能乱

农产品系统的订单流程比较典型：用户确认订单 → 校验库存 → 扣减库存 → 生成订单 → 返回支付信息。其中“校验库存”和“扣减库存”必须放在同一个事务里，否则会出现超卖或者库存负数。

用Spring的@Transactional注解来保证原子性即可：

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(OrderCreateDTO dto, Long userId) {
    // 1. 校验商品是否上架
    // 2. 遍历订单明细，校验并锁定库存
    // 3. 计算订单总金额
    // 4. 插入订单主表
    // 5. 插入订单明细表
    // 6. 返回订单数据，跳转模拟支付
}

这里有个细节：扣减库存的SQL要带上条件quantity >= #{need}，而不是先查出来再在JVM里算好再更新。面向并发安全的写法是：

sql复制UPDATE stock 
SET quantity = quantity - #{need} 
WHERE product_id = #{productId} AND quantity >= #{need}

如果影响行数为0，说明库存不足，直接在事务里抛出业务异常。这也是实际项目里防超卖的最低成本方案，答辩时说出来非常加分。

注意：事务里不能捕获所有异常后吞掉，一定要rollbackFor = Exception.class，并且只在Service层做事务边界。Controller层的事务无用且危险。

5.4 订单状态机：一处判断，处处省心

订单有很多状态，我建议用枚举而不是魔法数字：

状态值	含义	可进行的操作
0	待付款	取消、支付
1	待发货	管理员发货
2	待收货	用户确认收货
3	已完成	无
4	已取消	无
5	退款中	管理员处理退款

在设计时，不要在每个Service方法里散落“if status == 1”这样的判断。可以在Order类里维护一个status字段，并在状态变更处统一检查“前置状态是否合法”。我习惯写一个OrderStatusHandler或者直接在Service里搞一个私有方法：

java复制private void checkStatus(Order order, Integer expect) {
    if (!Objects.equals(order.getStatus(), expect)) {
        throw new BizException("当前订单状态不允许该操作");
    }
}

这样每一次状态流转都是“显式校验 + 更新”，逻辑清晰，出了问题也好排查。答辩时如果评委追问“重复提交怎么防”，你就可以说“订单状态机保证了每次操作都只能从前置状态进入后置状态”，这个问题就直接过了。

5.5 文件上传与图片访问

农产品肯定要有图片。本地开发阶段最简单的是用本地磁盘存储，然后通过静态资源配置访问。Spring Boot里配置：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 5MB
      max-request-size: 20MB
app:
  upload-path: D:/agricultural-sales/upload/

提供一个通用上传接口，把文件保存为UUID文件名，返回可访问的相对地址/files/uuid.jpg。再写一个WebMvcConfigurer把/files/**映射到本地目录：

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

需要注意：从Vue页面里直接访问localhost:8080/files/xxx.jpg是可以的，但如果你用了前端代理，图片地址不要带/api前缀，否则会被代理规则转发到后端接口而404。

5.6 模拟支付与回调

不要接真实支付SDK，毕业设计阶段用“模拟支付”完全够。点击支付后，前端向后端发送一个“确认支付”的请求，后端直接把订单状态从待付款改成待发货，同时在支付表里插入一条支付记录。

如果想做得更像一点，可以加一个模拟回调接口：前端生成一个随机流水号，后端以流水号作为幂等键，相同的流水号重复请求只处理一次。这个幂等思路写进论文是一大亮点，因为在真实电商系统里支付回调就会有重复通知的问题。

6. 前端页面实战：Vue + Element Plus搭建管理后台

6.1 布局与路由权限

管理后台的经典布局是左侧菜单+右侧内容区。Element Plus里用el-container搭骨架：

el-aside：放菜单，根据用户角色动态渲染。
el-header：放用户信息和退出按钮。
el-main：放router-view。

路由权限可以在全局前置守卫里做：

js复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (!token && to.path !== '/login') {
    next('/login')
  } else {
    next()
  }
})

这里不用做太精细的权限控制。管理员和普通用户共用一套页面，必要时用v-if="role === 'ADMIN'"隐藏部分按钮，既能满足需求，也不会把自己搞得太复杂。

6.2 登录页与表单校验

登录页是前端开发的“第一块试金石”。写登录页时，我建议一次性把表单校验做完整，包括用户名非空、密码长度、验证码刷新逻辑。Element Plus的el-form提供了rules属性，非常方便：

js复制rules: {
  username: [{ required: true, message: '请输入用户名', trigger: 'blur' }],
  password: [{ required: true, message: '请输入密码', trigger: 'blur' },
             { min: 6, max: 20, message: '密码长度6-20位', trigger: 'blur' }]
}

登录成功之后，把token和用户信息存进localStorage，顺便跳转到首页。注意不要用sessionStorage，否则用户关闭浏览器就掉线，很影响演示效果。

6.3 商品管理页里的“增删改查”套路

商品管理页堪称所有后台页面的模板。它需要：搜索区（关键词、分类）、表格区（商品列表）、分页区、弹窗表单（新增/编辑）、图片上传控件、启用/停用开关。

我重点提一下表格列的渲染：价格显示要两位小数，状态列用el-tag显示不同颜色，图片列用el-image的preview-src-list支持点击预览。这些细节看着小，实际评审演示时观感差别巨大。

html复制<el-table-column label="状态" width="100">
  <template #default="scope">
    <el-tag :type="scope.row.status === 1 ? 'success' : 'info'">
      {{ scope.row.status === 1 ? '上架' : '下架' }}
    </el-tag>
  </template>
</el-table-column>

页面的数据加载函数：

js复制const loadData = async () => {
  const res = await listProduct({ page: page.value, size: size.value, keyword: keyword.value })
  if (res.code === 200) {
    tableData.value = res.data.records
    total.value = res.data.total
  }
}

回到实际，几乎每个列表页都是这套逻辑。把商品管理页吃透了，后面供应商管理、订单管理、公告管理全是复制粘贴改字段。

6.4 订单管理页与状态操作

订单管理页前端要处理的是“状态驱动操作”。比如当前订单状态是待发货，右侧操作按钮才显示“发货”；待收货才显示“确认收货”。这是后端状态机在前端的影子。

做的时候就一个原则：按钮的显示条件跟订单状态一一对应。

html复制<el-button v-if="scope.row.status === 1" type="primary" @click="handleShip(scope.row)">发货</el-button>
<el-button v-if="scope.row.status === 2" type="success" @click="handleConfirm(scope.row)">确认收货</el-button>

前端不需要发散地去做很多判断，后端会拦一次，前端只是让界面更友好。这种“二次拦截”的思路也是真实项目里的惯例。

6.5 axios封装与统一错误提醒

所有请求都建议走统一的axios实例：

js复制import axios from 'axios'

const service = axios.create({
  baseURL: '/api',
  timeout: 10000
})

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

service.interceptors.response.use(
  response => {
    if (response.data.code === 401) {
      localStorage.removeItem('token')
      window.location.href = '/login'
    }
    return response.data
  },
  error => {
    ElMessage.error(error.message)
    return Promise.reject(error)
  }
)

这里要特别注意：后端业务异常时，HTTP状态码可能还是200，只是业务code不为200。这个设计很多新手不理解，其实要看你怎么约定。代码里让code=200代表成功，其余code在响应拦截器里统一ElMessage.error(message)即可。这样每个页面都不用再写try-catch的弹错逻辑，清爽很多。

7. 从本机联调跑到服务器部署：那些教程没写明白的环节

7.1 跨域问题到底是怎么来的

开发阶段你会在Vue工程里配代理。常见配置如下：

js复制// vue.config.js
module.exports = {
  devServer: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

这样配置之后，前端地址http://localhost:3000/api/product会被转发到http://localhost:8080/api/product。浏览器里根本不存在跨域，因为请求是同源的（都来自3000端口的页面发出去的）。

生产部署时如果不做代理，直接让浏览器请求后端接口就会遇到CORS。于是很多人会去后端加@CrossOrigin或者全局CORS配置。我的意见是：能用Nginx代理解决就不要开后端CORS，因为代理方式更符合真实部署规范。只有前后端域名确实不同的时候，才需要后端开启跨域支持。

7.2 打包过程的几个坑

后端打包：

bash复制mvn clean package -DskipTests

注意IDEA里如果你用Lombok，且Maven编译报找不到getter/setter方法，多半是Lombok插件没装或版本不匹配。另一个常见坑是application.yml里写的数据库密码含有特殊字符，在yaml里要加引号。

前端打包：

bash复制npm run build

打包会生成dist目录。里面是静态文件，直接扔给Nginx即可。如果你的Vue项目用的是history模式路由，还需要在Nginx配置里加：

nginx复制location / {
  try_files $uri $uri/ /index.html;
}

不然刷新非首页路由时直接404，这个坑我见过太多次了。

7.3 Nginx部署完整示例

一个典型的Spring Boot + Vue部署场景是：

后端jar包运行在8080端口。
Nginx监听80端口，拦截/请求返回前端静态文件。
Nginx把/api/请求代理到http://localhost:8080。

Nginx配置核心片段：

nginx复制server {
    listen       80;
    server_name  localhost;

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

    location /api/ {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /files/ {
        proxy_pass http://localhost:8080;
    }
}

启动前端服务只需要一行命令：

bash复制npm run build && docker cp dist nginx容器  # 或者直接拷贝到服务器目录

如果你没有服务器，完全可以使用虚拟机或者云服务平台的白嫖试用资源来演示部署流程。答辩现场能打开一个公网可访问的网址，就是很大的加分项。

7.4 如果只在本机演示，怎么准备才算稳

很多同学的毕业设计演示就是本机跑起来给评委看。这里有一个细节：启动前把数据库脚本重新执行一遍，保证数据新鲜。尤其是时间字段，如果用的是CURRENT_TIMESTAMP，系统在三个月前录入的订单时间会把评委逗笑——凌晨两点买五斤土豆，这数据既尴尬又显得不专业。

演示前检查这几项：

前后端服务都能正常启动，端口不冲突。
数据库服务已启动，账号能连上。
测试账号能在网页正常登录。
商品图片能被正常访问，不是空白图。
下单流程能跑通，库存扣减和订单状态没问题。
换一台电脑或浏览器刷新不报404（这就要检查路由配置和代理）。

有同学喜欢现场演示一些“翻车抢救”的片段，我不太建议，毕业设计演示的核心是流畅稳定，不是展示调试能力。

8. 论文写作与答辩准备的思路：让项目效果最大化

8.1 论文结构怎么搭

如果学校没有强制指定模板，可以参考下面这种顺序：

绪论（背景、意义、国内外现状、主要工作）
相关技术（Spring Boot、Vue、MyBatis Plus、MySQL、JWT）
系统分析（可行性分析、需求分析、角色分析、用例图、数据流图）
系统设计（总体架构、功能模块设计、数据库设计、接口设计）
系统实现（关键模块的实现思路、核心代码、效果截图）
系统测试（测试用例、功能测试、性能测试简述、测试结论）
总结与展望

写的时候一定注意：第二章相关技术别写成教科书搬运，应该结合本系统说明选型理由，比如“MyBatis Plus简化了本项目大量单表CRUD操作”。第五章系统实现要放核心代码，但不要整页贴长代码，选关键方法片段并解释逻辑即可。

8.2 用流程图和ER图把逻辑讲透

论文中的图非常关键。不要用Mermaid画在线图，最好用绘图工具把ER图、业务流程图、用例图画清楚，图片质量直接决定论文的“专业感”。

这里说一个容易翻车的细节：论文里的架构图应该体现出“前后端分离”的特征。浏览器、Nginx、Spring Boot、MySQL、文件存储这几个部分用不同颜色分层画清楚，再配合文字说明每个组件之间的请求流向。评审老师扫一眼这张图就知道你的项目不是“玩具”，而是有工程化设计思路的完整系统。

8.3 答辩常见的六个问题及回答思路

根据往年经验，农产品销售系统答辩时评委最爱问这些问题：

问题1：库存和订单之间的数据一致性怎么保证？
回答思路：下单使用@Transactional事务，先校验再扣减库存，SQL扣减时带quantity >= #{need}条件防止超卖，扣减失败则回滚。

问题2：JWT和传统Session有什么区别？为什么选JWT？
回答思路：JWT无状态、适合前后端分离和水平扩展；Session需要服务端存储，跨域不便。要点出JWT的组成（Header、Payload、Signature）。

问题3：密码是怎么存储的？
回答思路：使用BCrypt加密，不是明文。Spring Security里的BCryptPasswordEncoder可以直接用，单独用spring-security-crypto依赖就行。

问题4：如果用户支付后没有回调怎么办？
回答思路：使用订单的支付超时状态 + 定时任务扫描未支付订单（如果做了的话）。做毕业设计不要求完全实现，但答出思路即可。

问题5：前端为什么用Vue而不用JQuery？
回答思路：Vue组件化开发复用性高、响应式数据绑定减少DOM操作、生态成熟、前后端分离便于联调维护。

问题6：你的系统有哪些可以改进的地方？
回答思路：不要说自己系统没缺点。可以说目前支付是模拟的，后续可以接入真实支付；未做分布式部署，后续可以考虑Redis缓存热点数据和消息队列处理订单；可以增加数据可视化大屏。

8.4 论文查重与代码量的平衡

论文查重是很多人头疼的事情。技术描述部分尽量用自己的话重写，不要大段复制教程。实现部分的代码片段通常不计入查重，但标题和章节名不能直接照搬网上模板。

另外，项目代码量也是一个会被关注的点。后端3000~6000行、前端2000~4000行左右是比较正常的区间。如果感觉代码量少，可以补充一些“锦上添花”的小功能，比如数据统计报表、操作日志、公告管理、轮播图管理、个人中心订单列表。这些功能逻辑简单，却能让系统完整度更高。

9. 我踩过的那些坑，提前帮你们填平

9.1 前端刷新404：路由模式与服务器配置

用Vue Router的history模式时，刷新任意子路由页面会请求服务器对应的路径，而Nginx上并没有这个文件，于是404。如果你不想改Nginx，可以直接用hash模式，路由上多个#，但观感稍差。最规范的还是上文提到的Nginx try_files配置，效果是把所有未匹配的请求都转到index.html，由前端路由接管。

9.2 时间字段差8小时：时区与存储格式波动

Spring Boot默认的Jackson序列化时间可能会带时区偏差。配置统一格式可以这样：

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

MySQL连接串里的serverTimezone=Asia/Shanghai也要加上。双保险，一般不会再出现时间错乱的问题。

9.3 后端返回给前端的时间格式对不上

明明数据库里的时间是2024-05-20 10:00:00，前端却显示成2024-05-20T10:00:00。这是因为Jackson默认序列化LocalDateTime时使用ISO格式。解决办法是给实体字段加注解，或者全局配置。

我习惯在字段上直接加：

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime createTime;

简单直接，谁看了都明白。全局配置更省事，但有些库的序列化行为可能不受控，不如加注解稳。

9.4 上传图片后前端无法回显

如果你把图片存到了本地磁盘，但前端页面地址是http://localhost:8080/files/xxx.jpg，通常需要确认后端是否放行了静态资源映射。Spring Security如果也加进来了，还会拦截静态资源，必须在拦截器配置里放行/files/**。另一个常见坑是addResourceHandlers只配置了/files/**，但文件上传后返回的前缀拼错了。

9.5 数据库密码带特殊字符导致启动失败

如果你的MySQL密码里有@、#、%、&这类字符，在application.yml里要加引号：

yaml复制spring:
  datasource:
    password: "a#B@123"

否则yaml解析会出现不可预料的错误。这个问题排查起来特别隐蔽，因为报错信息可能只说是连接超时，不看配置很难想到字符转义。

9.6 模拟支付后库存没扣

忘了加@Transactional是最常见原因。还有种情况是你在Service内部调自己类的另一个方法，比如this.createOrder()，Spring事务代理不会生效。必须从外部注入调用，或者把事务方法拆分到单独的服务类里。这种隐蔽问题面试时也会被问到，提前明白原理。

10. 一个小技巧让答辩演示更出彩

如果系统功能做完还有余力，我强烈建议加一个“数据可视化大屏”页面。用ECharts展示今日销售额、订单量、热销农产品排行、库存预警列表。这些数据从后端接口实时拉取，页面效果非常炫。

具体做法也不难。后端提供一个统计接口，返回近七天的销售数据、分类销量占比、库存不足的商品列表，前端页面用ECharts的折线图、饼图、横向柱状图展示。

开始演示时先打开这个可视化页面，再进管理后台操作，评委的第一印象就完全不同——“这个学生做的不是纯CRUD，还是有业务思考的”。而且这部分写进论文“系统实现”里，配三张图，文字都不用多写，工作量直接提升一个层次。

最后提醒一句：做这套系统，最大的收获不是代码，而是把“需求 → 设计 → 编码 → 测试 → 部署 → 写作”这一整条链路亲手走完。这个过程里踩过的每一个坑，都会成为你未来工作里的免疫力。

农产品销售管理系统全栈开发实战：从设计到答辩