助农农商系统开发实战：SpringBoot+Vue前后端分离与订单闭环设计

做助农农商系统这个项目，说实话一开始我以为只是给普通电商平台换了个皮。等真正把需求盘了一遍才发现，它跟传统电商的差别非常大——目标用户是农户和农村消费者，使用习惯、网络环境、支付习惯都不一样。整个系统虽然是基于 SpringBoot + Vue 的标准前后端分离结构，但里边的用户角色设计、商品模型、订单流转逻辑，都得重新想。这篇文章围绕这套助农农商系统的源码、数据库和文档交付，把从需求拆解到技术选型、数据库设计、前后端核心实现，再到打包交付和踩坑经验完整梳理一遍。适合正在做 SpringBoot 毕设、Vue 项目实战，或者打算把这类电商项目落地成可交付作品的开发者参考。

1. 需求拆解：助农农商系统到底要解决谁的什么问题

1.1 三个核心角色的权责边界

很多人第一次拿到这种题目，第一反应是“做个商城嘛”。其实助农系统和普通商城最大的不同，在于它天然有三个角色：农户、消费者、平台管理员。传统电商通常是“卖家—买家”双边，但助农场景里平台往往还承担审核、推广、数据统计的职责，所以是一个典型的三端系统。

农户端要做的事情很直白：注册账号、维护店铺信息、上架农产品、处理订单、查看自己商品的销量和收入。这部分最核心的需求不是“功能多”，而是“流程简单”——很多农户不是专业电商运营者，如果上架商品需要配库存、配规格、配多级分类，他们大概率会直接放弃。所以我在设计农户端时，把商品上架简化成：填写名称、选分类、填价格、写库存、上传一两张图，完事。

消费者端就是常规的电商购物流程：浏览、搜索、加购物车、下单、支付、查看订单状态。唯一要考虑的特殊点是支付方式。助农场景存在大量线下交易和货到付款的需求，所以系统里除了模拟的在线支付，还要保留“货到付款”这个订单状态，否则系统在真实场景里根本跑不通。

平台管理员端负责的是全局管控：农户入驻审核、商品审核、订单监管、用户管理、数据统计。这部分是助农系统区别于普通商城的关键。不能只做增删改查，要把审核作为独立流程设计出来，否则“助农”就变成了“无人监管的摆摊现场”。

1.2 订单闭环：从下单到结算的状态流转

订单状态是整个系统最容易被做乱的地方。我在这个项目里把订单流程收敛成六个状态：待付款、待发货、待收货、已完成、已取消、售后中。

为什么单独提这一点？因为很多开发者做电商项目时，订单状态全靠一个数字字段随意流转，今天写 0 是待付款，明天写 1 是已支付，后天再看代码自己都懵。我在做这个项目时一开始也这么干，后来发现报表统计和前端页面渲染都变得极其痛苦。

正确的做法是定死状态机：下单时创建订单记录，状态为待付款；用户点击支付成功后状态改为待发货；农户在农户端点击发货后改待收货；用户确认收货或系统超时自动确认后改已完成。取消操作只允许出现在待付款阶段，售后申请则必须在已完成之后才能发起。

这套状态机的价值不只是代码清晰，更重要的是数据库里的订单记录任何时候都能还原出完整的业务事实。助农项目涉及农产品溯源、结算分成，如果订单状态乱，后续的对账统计根本没办法做。

1.3 MVP 优先级：先做核心闭环，再谈锦上添花

如果你是自己从零开发这套系统，我建议严格按下面的优先级来做：

• 第一梯队：用户注册登录、农产品分类浏览、商品详情、购物车、下单支付、订单管理。这是闭环，缺一个都跑不通。
• 第二梯队：农户入驻、商品上架、订单发货、平台审核、基本的数据统计。这是角色差异化，能让系统真正叫“助农”。
• 第三梯队：优惠券、秒杀、消息通知、分销裂变、物流跟踪对接。这些是加分项，但没有它们系统依然完整。

我见过不少同学一上来就研究优惠券规则、搞拼团，结果项目交付时核心购物流程还有 bug。做项目不是堆功能，是把一条主线做扎实。这套助农系统的主线就是“农产品从农户手里到消费者手里”的完整链路，所有功能都应该围绕这条链路展开。

2. 技术选型复盘：为什么偏偏是 SpringBoot + Vue

2.1 后端框架：没有悬念的选择，但要纠结版本

后端用 SpringBoot 几乎是没有悬念的选择。我们对比过几个方案：SSH（Struts + Spring + Hibernate）太老，配置繁琐，社区活跃度低；SSM（Spring + SpringMVC + MyBatis）能用，但 XML 配置和维护成本高，开发效率明显低；SpringBoot 直接解决了“约定大于配置”的问题，内嵌 Tomcat，JAR 包一键启动，配合 MyBatis Plus 连 SQL 都不用手写基础 CRUD。

真正需要纠结的是版本。SpringBoot 2.x 和 3.x 的差别不是小版本升级那么简单。3.x 基于 Jakarta EE，javax 包要全部改成 jakarta，部分第三方组件的兼容性是个大坑。如果你用的是 MyBatis Plus、某些旧版连接池，升级到 3.x 分分钟一堆报错。

我在这套助农农商系统里用的是 SpringBoot 2.7.x。原因有四个：一是稳定，社区资料多，遇到问题基本都能搜到解决方案；二是和 MyBatis Plus 的兼容性最好；三是 JWT 相关的 jjwt 库在 2.x 下工作正常；四是大部分生产服务器的 JDK 还是 1.8，SpringBoot 3.x 要求 JDK 17，迁移成本太高。

2.2 前端框架：Vue 2 还是 Vue 3，数据管理选什么

前端用 Vue 也是顺理成章的选择。这个项目涉及大量列表页、表单页和状态联动，Vue 的响应式数据绑定比原生 JS 省太多事。但这引出一个实际问题：Vue 2 和 Vue 3 到底用哪个？

如果只看学习成本，Vue 2 的选项式 API 更直观，Element UI 组件库也成熟；Vue 3 的 Composition API 更灵活，配套的 Element Plus 也是目前的主流。这套助农系统我选了 Vue 3 + Element Plus，理由是项目交付后使用者大概率会基于这套代码继续扩展，Vue 3 是趋势，没必要在一个新项目里抱着 Vue 2 不放。

状态管理方面，如果你的 Vue 版本是 3.2+，我建议直接用 Pinia，别用 Vuex。Pinia 的设计更简洁，去掉 mutations 这个概念，store 写起来就是一个普通的 setup 函数，心智负担小得多。我用 Pinia 来管理购物车数量、用户信息和登录状态，实测下来比 Vuex 顺手。

2.3 前后端分离的工程结构

既然是前后端分离，工程结构必须从一开始就定清楚，否则交付时源代码一团乱麻。

produce-aid-system/ ├── backend/ # SpringBoot 后端 │ ├── src/main/java │ ├── src/main/resources │ └── pom.xml ├── frontend/ # Vue 前端 │ ├── src/ │ ├── package.json │ └── vite.config.js ├── database/ # SQL 脚本 │ ├── init.sql │ └── data.sql └── docs/ # 项目文档

这种结构的价值在于分工明确。后端只看 backend，前端只看 frontend，数据库脚本单独放在 database 目录，拿到项目的人不用猜哪里是哪里。尤其是你要交付给别人使用，这种目录规范是专业度的直接体现。

3. 数据库设计：从用户三端到订单闭环的数据建模

3.1 用户表与角色：一张表还是三张表

用户建模是这类项目的一个分歧点。有人倾向建三张表：农户表、用户表、管理员表。我不推荐这种做法。理由很简单：三类用户的公共字段太多，账号、密码、手机号、昵称、头像、创建时间，如果拆成三张表，登录逻辑就要分三套，公共字段的维护也要写三遍。

我的方案是一张sys_user表，通过role字段区分角色。这个字段用数字表示：1 代表普通消费者，2 代表农户，3 代表平台管理员。农户特有的信息，比如店铺名称、店铺简介、审核状态，单独放一张farmer_info表，通过user_id关联。

这样设计的好处是登录接口只写一次，通过 role 判断跳转到不同页面即可。而且后续如果要加“运营人员”这类新角色，只需要加一个数字枚举，不影响表结构。

3.2 农产品表：字段设计要贴近真实售卖场景

农产品表和普通商品表的差别在于，它必须考虑农产品的特殊性。比如“产地”字段不可少，这是助农项目的基本盘；还有“单位”，农产品经常按斤、按箱、按棵售卖，不能默认都是“件”。

核心字段大致如下：

注意status字段，我用的是“0 下架、1 上架、2 待审核”三段式。为什么商品要有待审核？因为这是助农平台，农户上架的商品需要管理员审核，确保不是违禁品、价格没有异常离谱。这个审核字段单独拎出来，前端才能根据状态显示不同的按钮和提示。

3.3 订单相关表：订单主表和订单明细表分开

订单设计遵循电商的经典做法：订单主表（order）和订单明细表（order_item）分离。

订单主表存一次交易的整体信息：订单号、用户 ID、总金额、状态、收货地址、下单时间、支付时间、发货时间。订单明细表存每个商品条目：订单 ID、商品 ID、商品名称（快照）、单价（快照）、数量、小计金额。

为什么要做快照？这是很多新手容易忽略的点。商品价格和名称是可能变的，农户今天把西红柿从 3 块涨到 4 块，之前的订单记录如果不做快照，历史订单显示的价格就会跟着变，对账就乱套了。所以在明细表里，商品名称、单价必须冗余存储一份，下单时写进去，之后就再也不动。

3.4 购物车、收货地址、结算流水

购物车表相对简单：用户 ID、商品 ID、数量、加入时间。这里要注意唯一约束，同一个用户对同一个商品只能有一条购物车记录，否则用户反复点击加入购物车会产生一堆重复数据。前端在处理时一般是“已存在则数量加一”，后端同样要做这一层保护。

收货地址表设计时，我建议除了省市区详细地址之外，加一个is_default字段标记默认地址。下单页需要它来预填，省得用户每次都要重新选择。

结算流水表（payment_record）对应订单支付信息：订单号、支付方式、支付金额、交易流水号、支付时间。这个表在助农项目里有特殊用途——平台需要知道每笔订单的金额去向，涉及农户结算。有了这张表，所有资金的来龙去脉都清清楚楚。

4. 后端实现：核心功能模块的开发路线

4.1 从登录鉴权开始：JWT 的接入细节

后端开发我建议先把登录注册做通，因为后面所有接口都依赖登录态。采用 JWT（JSON Web Token）方案：用户登录成功后，后端生成 Token 返回给前端，前端存在本地，之后每次请求都带上这个 Token，后端通过拦截器校验。

JWT 的实现有几个细节值得注意：

第一，Token 过期时间的设置。助农系统面向的是低活跃度用户，农户可能几天才登一次，如果 Token 过期时间设得太短（比如 2 小时），体验会很差。我设的是 24 小时，并且在前端封装请求时做了 401 拦截，过期后自动跳转登录页重新登录。

第二，拦截器要排除登录接口。/api/auth/login、/api/auth/register这些接口必须放行，否则用户还没登录就被拦截了。还有一种做法是给一个匿名 Token，但没必要，自己给自己找麻烦。

第三，密码加密。不要用 MD5，不要存明文，用 BCrypt。Spring Security 里自带的BCryptPasswordEncoder就能用，加密后的密文即使数据库泄露，密码也无法被还原。

4.2 商品模块：图片上传与分页查询

商品模块是所有业务模块里改动最频繁的地方。前端要展示商品列表、商品详情，农户要上传商品、修改商品，管理员要审核商品。后端的 Controller 设计上直接按角色拆成三个接口组：

• 消费者端：分页查询上架商品、按分类筛选、按关键字搜索、查看商品详情。
• 农户端：新增商品、修改商品、上下架操作、查询自己的商品列表。
• 管理端：查询所有待审核商品、审核通过/驳回。

图片上传这块是天然的坑点。农产品图片往往体积不小，如果直接传到后端本地磁盘，打 JAR 包部署后图片路径很容易出问题。我在这个项目里用的是本地存储方案——将上传的图片存到服务器指定目录，数据库里只存图片的相对路径，前端通过静态资源映射访问。

如果需要更专业的方案，可以考虑把图片存到 MinIO。之前我在另一个项目里把 MinIO 集成进 SpringBoot，只需要引入minio依赖，配置好 endpoint、accessKey、secretKey 和 bucket，上传时调用MinioClient.putObject即可。也是基于这个项目，我认识到通用上传模块一定要抽出来做一个单独的FileService，方便后续替换存储策略。

分页查询使用 MyBatis Plus 的Page对象非常方便。一个简单的分页查询是这样：

Page<Product> page = new Page<>(current, size); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getStatus, 1) .like(StringUtils.hasText(keyword), Product::getName, keyword) .orderByDesc(Product::getCreateTime); productService.page(page, wrapper); return page;

4.3 订单模块：状态流转和并发控制

订单模块的后端实现是整个项目里最考验代码功力的一环。首先是创建订单的接口，需要考虑并发问题。一个典型的场景：消费者在抢购一批限量农产品，如果库存只有 20 份，但有 30 个人同时下单，后端的库存扣减必须保证不会把库存扣成负数。

最简单的做法是在 SQL 层面做原子扣减，而不是先在代码里查库存再算好减掉：

UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0

这条 SQL 的威力在于：WHERE stock > 0条件判断和库存扣减是原子操作，数据库的行锁会保证同一时间只有一个请求能成功执行。如果影响行数为 0，说明库存已经不足，后端直接返回“库存不足”即可。

订单状态流转我在前面说了状态机的设计，落到代码里就是一个枚举类：

public enum OrderStatus { PENDING_PAYMENT(0, "待付款"), PENDING_SHIPMENT(1, "待发货"), PENDING_RECEIPT(2, "待收货"), COMPLETED(3, "已完成"), CANCELLED(4, "已取消"), AFTER_SALE(5, "售后中"); }

状态变更的操作都封装在 Service 层，并加上日志记录，这样出现问题可以通过日志还原完整的操作链路。

4.4 数据统计模块：管理端报表实现

助农系统面向平台管理者，数据统计是必须的核心模块。统计内容包括：平台总交易额、总订单数、注册用户数、农户数、各商品类目销量排行、各农户销售额排行。

统计功能不需要太复杂的算法，主要是 SQL 聚合查询。例如查询各分类的销量：

SELECT c.name, SUM(oi.quantity) AS total_sales FROM order_item oi LEFT JOIN product p ON oi.product_id = p.id LEFT JOIN category c ON p.category_id = c.id GROUP BY c.id ORDER BY total_sales DESC

这部分的后端实现逻辑很清晰，一个最稳妥的方式是单独建一个StatisticsController，里面写好聚合查询的 SQL，返回给前端 Line 图和 Bar 图的数据结构。前端用 ECharts 渲染，配置项网上都有现成的，重点是把数据格式对齐，别让后端返回{name, value}，前端却按{label, data}来接，这种前后端字段不一致的低级错误在联调时最耗时间。

5. 前端实现：Vue 页面和接口对接的关键细节

5.1 项目初始化和依赖安装的那些“版本坑”

前端开发的第一步是初始化项目。用 Vite 创建 Vue 3 项目是当前的主流方式：

npm create vite@latest frontend -- --template vue npm install npm run dev

这里我特别想多说一句“springboot 版本太高”和“vue 依赖安装”这两个热门搜索词背后的问题。Vue 项目的依赖安装简直是重灾区，最常见的问题是npm install报错，原因几乎都是版本不兼容：你的 Node.js 版本太低或太高、某个依赖的 peer dependency 冲突、npm 源访问太慢。

我的经验是：如果npm install遇到ERESOLVE unable to resolve dependency tree这种错误，优先检查 Node 版本，建议用 Node 16.x 或 18.x LTS 版本；如果还不行，可以试一下清理缓存再装：

npm cache clean --force rm -rf node_modules package-lock.json npm install

还有一个容易被忽略的点：如果安装 Element Plus，注意和 Vue 的版本匹配。Element Plus 只支持 Vue 3，如果你用 Vue 2 硬装 Element Plus，启动时直接就白屏，控制台报错还不一定看得明白。

5.2 axios 封装与跨域处理

前后端分离项目的一个必踩坑点就是跨域。开发环境下，前端跑在localhost:5173，后端跑在localhost:8080，两个端口不同，浏览器的同源策略会拦截所有请求。

跨域问题的解决有两个层面。首先是后端，在 SpringBoot 的配置类里加上 CORS 配置：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

其次是前端，axios 请求封装时统一设置baseURL。我在项目里是这样封装的：

import axios from 'axios' import { ElMessage } from 'element-plus' import { useUserStore } from '@/stores/user' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 15000 }) request.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers.Authorization = `Bearer ${userStore.token}` } return config }) request.interceptors.response.use( response => response.data, error => { if (error.response?.status === 401) { ElMessage.error('登录已过期，请重新登录') router.push('/login') } return Promise.reject(error) } ) export default request

这段封装里有三个要点：第一，请求头统一携带 Token；第二，响应统一取出response.data，业务层不用再嵌套一层处理；第三，401 状态统一拦截，跳转登录页并给用户提示。这三条能省掉大量重复代码。

5.3 路由设计：动态菜单和权限控制

路由这块，助农系统的三端角色需要走不同的首页和侧边栏。我的做法是：路由表分为公共路由和需要登录的路由，登录后根据角色渲染不同的侧边栏菜单。

Vue Router 的导航守卫里做一个简单的角色判断：

router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.path === '/login' || to.path === '/register') { next() return } if (!userStore.token) { next('/login') return } if (to.meta.roles && !to.meta.roles.includes(userStore.role)) { next('/403') return } next() })

关于动态路由，我建议这一版先用静态路由加菜单过滤，不要急着做前后端联动的动态路由生成。为什么？动态路由虽然看起来很高级，但涉及刷新后路由恢复的问题，需要在 Pinia 里持久化用户路由信息，复杂度成倍上升。对于助农这种中期项目，角色数量只有三个，静态路由配合v-if控制菜单显示完全够用。

5.4 移动端适配与核心页面拆解

助农系统的终端用户很多会用手机访问，所以前端页面尽量做响应式适配。Element Plus 的栅格布局（el-row/el-col）在 PC 端和移动端都能有还算不错的表现，只需要注意商品列表的列数在移动端降为一列或两列。

页面拆解上，我按业务流程分成几个大页面组：

• 首页：轮播图、分类入口、推荐商品列表。
• 商品列表页：分类筛选、关键字搜索、价格排序。
• 商品详情页：商品图、价格、库存、数量选择、加入购物车、立即购买。
• 购物车页：勾选、改数量、删除、结算。
• 确认订单页：收货地址选择、配送方式、订单金额明细、提交订单。
• 订单列表页：按状态 Tab 切换、取消、确认收货、申请售后。
• 个人中心页：个人信息、我的收藏、地址管理、我的店铺入口。
• 农户后台页：商品管理、订单管理、店铺信息。

每个页面组件保持纯粹的展示逻辑，接口调用都写在对应的 API 模块里。这样代码的可读性和可维护性都会好很多。

6. 交付规范：源码、数据库和文档怎么整理才专业

6.1 源码目录整理和代码注释规范

项目交付时，“源码”不是把代码压缩包扔给对方就完事。一个专业的源码交付，必须做到三件事：

第一，README 要写清楚。README 里必须包含：项目简介、技术栈、如何初始化、如何启动后端、如何启动前端、默认账号密码、目录结构说明。这看起来简单，但大部分项目恰恰输在这里——对方拿到源码不知道从哪一步开始，一条一条问你要操作步骤，比重新开发一遍还累。

第二，关键代码要有注释。不是每行都注释，那叫噪音。而是要注释“为什么”层面的东西，比如订单状态为什么要加一个“售后中”，商品审核状态为什么要区分“待审核”和“下架”。这类业务逻辑的注释对接收方理解系统价值极大。

第三，屏蔽不必要的本地文件。本地的application.yml里数据库密码、上传路径，这些不要直接写死在交付包里，用配置项占位，比如spring.datasource.password: ${DB_PASSWORD}，交付文档里再提示使用者自己配置。

6.2 数据库脚本的三种形态

数据库交付不能只丢一个.sql文件。我在交付助农系统时，数据库脚本按用途拆分：

• init.sql：表结构初始化脚本，包含建库、建表、索引设置。
• data.sql：基础数据脚本，包含管理员账号、默认分类、测试商品、演示用户。
• update.sql：迭代更新脚本，记录每次版本改动。

为什么这么拆？因为使用者直接用你的完整数据库会带着你测试时的脏数据，而前后端联调又不能没有基础数据。拆开之后，使用者可以先执行init.sql建出干净的结构，再按需执行data.sql导入演示数据。

6.3 项目文档应该覆盖的内容

最后是文档。这套助农农商系统的文档我建议至少包含四部分：

• 需求说明文档：梳理用户角色、功能模块、业务流程，让使用者知道系统“为什么长这样”。
• 接口文档：所有后端接口的路径、请求参数、响应结构、错误码。我建议直接把 Swagger 集成进项目，启动后用 Swagger UI 页面就能看，省得单独维护一份 Word 文档。不过要注意生产环境关闭 Swagger，写个@Profile("dev")环境开关就行。
• 部署文档：从服务器环境配置、JDK 安装、MySQL 初始化、前后端打包、Nginx 配置到 HTTPS，每一步都得写清楚。
• 操作手册：给实际使用者看的，比如农户怎么入驻、怎么上架商品、管理员怎么审核。这部分很多人忽略，但助农系统的最终运营者不一定懂技术，操作手册才是他们最需要的。

7. 实测踩坑记录：这些问题我花了整个周末才解决

7.1 SpringBoot 打包后静态资源路径失效

本地开发时图片访问一切正常，打成 JAR 包部署到服务器后，商品图片全部 404。排查链路：先看服务器磁盘，图片文件确实已经上传成功，目录也创建了；再看 SpringBoot 的日志，也没有报错；最后发现是配置文件里的文件上传路径写的是本地相对路径，打包后 JAR 运行时的工作目录跟开发时不一样，相对路径定位错了。

解决办法很简单：把存储路径改成配置项，部署时在application.yml里配置绝对路径，或者宿主机挂载目录。这个坑提醒我，所有涉及文件路径的地方，绝对不要用相对路径。

7.2 MyBatis Plus 的分页查询明明配置了却不管用

用 MyBatis Plus 做分页，发现Page对象返回的records总是查出来全表数据，分页失效了。查了半天才发现缺少分页插件配置。MyBatis Plus 从 3.x 开始分页必须手动注册PaginationInnerInterceptor，不是引入依赖就自动有的。

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

这个配置漏掉的不止我一个，网上搜 “MyBatis Plus 分页失效” 一堆帖子都是这个原因。所以拿到新项目，先把配置类里的拦截器都看一眼再动手。

7.3 前后端字段命名风格不统一

后端习惯用下划线命名create_time，前端 JavaScript 习惯用驼峰createTime。如果不做统一处理，JSON 序列化时就会出现前端取的字段名对不上后端返回的字段名。

解决方案是全局配置 SpringBoot 的 Jackson，让它把下划线命名转换成驼峰：

spring: jackson: property-naming-strategy: SNAKE_CASE

或者反过来，后端所有实体类直接用驼峰命名，数据库字段也用下划线，让 MyBatis Plus 开启map-underscore-to-camel-case: true自动映射。我建议后者，这样代码、数据库、JSON 三层命名统一，联调时省掉大量“这个字段叫啥来着”的沟通成本。

7.4 数据库时区问题导致的 “时间差 8 小时”

后端写入数据库的时间比本地时间少了 8 个小时。这个问题排查到最后，是 MySQL 连接串里没指定时区。我的 MySQL 服务器默认时区是 UTC，而本地是中国标准时间 UTC+8，不显式指定时区数据库会按服务器默认时区存储。

解决办法，先在连接串里加上：

spring.datasource.url: jdbc:mysql://localhost:3306/proud_aid?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

其次检查 MySQL 全局时区配置，如果搞不清楚直接刷新连接后看数据。这类环境问题网上都有标准答案，但第一次遇到时确实容易怀疑人生，所以放在这里给后来人打个预防针。

关于这套助农农商系统，我最后想说的体会是：技术栈本身并不复杂，SpringBoot 和 Vue 都是非常成熟的框架，真正的价值在业务逻辑的设计和对交付规范的把握。把农户、消费者、管理员三个角色的权限边界理清楚，把订单状态机定死，把数据库表之间的关联关系画明白，这个项目就成功了大半。剩下的编码工作，基本就是在填一个已经设计好的图纸。如果你正在做类似的电商类项目，建议先把需求、角色、状态、交付清单四件事列在白板上，确认清楚再动手，遍地都是雷的从来不是框架，而是你自己没想清楚的业务逻辑。