Spring Boot农产品销售平台实战：从数据库设计到部署上线全解析

做了几年Java后端，Spring Boot这套东西早就刻进肌肉记忆了。但每次看到“农产品销售平台”这类选题，还是忍不住想多说两句——不是因为技术多难，而是它太典型了，几乎是Java Web入门阶段的“集大成训练场”。从需求分析到数据库设计，从接口开发到部署上线的完整链路，全都能在这个系统里过一遍。这次要聊的就是这样一个项目：Spring Boot农产品销售平台，带全套源码、数据库脚本、开发环境配置，还搭了一篇万字以上的论文文档。如果你正在找毕业设计参考，或者想找一个能把Spring Boot核心知识点串起来的实战项目，这篇文章值得花几分钟看完。

先说这个系统能干什么。它本质上是一个B2C模式的农产品电商平台，核心角色分三类：普通用户（买家）、商家（卖家）、管理员。用户这边能注册登录、浏览农产品、加购物车、下单支付（模拟）、查看订单状态、管理收货地址；商家端可以上架商品、修改库存、处理订单、查看销售统计；管理员则负责用户管理、商品审核、类目管理、系统公告这些后台事务。功能并不花哨，但麻雀虽小五脏俱全，电商领域最常见的几个核心场景——商品、购物车、订单、权限——全都覆盖了。对初学者来说，这个复杂度刚刚好：不至于一上来就被微服务和分布式架构砸晕，又不会简单到只是CRUD完事。

技术上，后端主体是Spring Boot 2.x，持久层用MyBatis Plus，数据库是MySQL 8.0，前端页面用Thymeleaf模板引擎加Bootstrap拼出来的，项目管理走的是Maven。整套组合是当前国内高校Java课程设计里出现频率最高的“标准套餐”，也基本贴合中小型项目的真实技术栈。下面我就把这套系统的设计思路、核心模块怎么拆、数据库表怎么定、开发调试时踩过的坑，一条一条掰开讲清楚。整个过程能复现、能落地，不是那种只放在PPT里的“纸上系统”。

1. 整体架构与功能模块拆解

1.1 为什么选单体架构而不是前后端分离

看到一个电商类的选题，有些同学第一反应是“现在不都前后端分离吗？Vue + Spring Boot才是标配吧”。话是没错，但得分场景。毕业设计也好，课程项目也好，评估的核心是“功能完整、逻辑清晰、能跑通”，而不是“技术栈追新”。前后端分离意味着你要同时维护两套工程，联调接口、处理跨域、管理Token，每一样都是额外的时间成本。而Thymeleaf这种服务端渲染方案，页面直接在Controller里返回，表单提交、路径跳转都走传统Web流程，整个系统的数据流是线性单向的，排错时一眼就能看到问题在哪。

我实际做完这个项目之后的体会是：单体 + 服务端渲染对于教学类项目是最优解，因为核心要学的是Spring Boot的业务组织方式，而不是前端工程化。当然，如果你打算拿这个项目去参加比赛或者进简历，那另说，可以后期再用Vue重写前端，接口层是不用动的——这就是把Controller层做好隔离的好处，后路得提前留好。

1.2 三种角色对应的功能矩阵

系统按角色拆分成三大功能域，这也是数据库设计和权限配置的基础。我直接列一张功能矩阵，后续写代码、写文档、画功能结构图时都可以对着这张表梳理：

这里有一个设计细节值得关注：用户和商家在真实平台里往往是两类独立的注册入口，但在这个系统里我采用的是“同一张用户表 + 角色字段”的做法，user表通过role字段区分普通用户和商家，管理员则单独用is_admin标记。这样做的直接好处是，登录逻辑只需写一遍，Spring Security的认证过滤器只认user表，大大减少了代码量。坏处是表结构不够“纯粹”，如果以后要做复杂的商家入驻审核流程，就得拆表。但就当前项目体量来说，单表 + 角色字段完全够用。

1.3 模块化的包结构设计

包结构是很多人容易忽略但又特别重要的部分。我见过不少项目写着写着，Controller、Service、Mapper全堆在同一个包下，6000行代码找一个小功能能翻半天。这个农产品销售平台的包结构是这么组织的：

com.market.agro ├── common // 通用返回结果、异常处理、常量定义 ├── config // 配置类（拦截器、跨域、数据源） ├── controller // 控制层，按业务域分：UserController、GoodsController、OrderController、AdminController ├── service // 业务层接口 + impl实现 ├── mapper // MyBatis Plus的Mapper接口 ├── entity // 数据库实体类 ├── vo // 视图对象，用于前后台数据传递

分层分包的好处不只是整洁，更重要的是它能帮你把业务逻辑与Web层解耦。比如service层只处理业务，不管HttpServletRequest那套东西；controller层只做参数接收和结果包装。这样后面做单元测试也好，换前端模板也好，改动都能控制在一个层里。

2. 核心模块与数据库设计实战

2.1 商品、订单、购物车三大核心表怎么定

数据库设计是这类系统的灵魂。我见过很多翻车的项目，问题不在代码，而在表结构设计得不合理，导致后期写SQL越写越痛苦。这个项目的核心表一共六张：user（用户表）、category（商品类目表）、goods（商品表）、cart（购物车表）、orders（订单表）、order_item（订单明细表）。其中最有讲究的是商品表和订单相关表的设计。

商品表的核心字段长这样：

CREATE TABLE `goods` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '商品ID', `seller_id` bigint(20) NOT NULL COMMENT '所属商家ID', `category_id` bigint(20) NOT NULL COMMENT '类目ID', `goods_name` varchar(100) NOT NULL COMMENT '商品名称', `subtitle` varchar(200) DEFAULT NULL COMMENT '副标题', `main_image` varchar(255) DEFAULT NULL COMMENT '主图URL', `price` decimal(10,2) NOT NULL COMMENT '销售价', `stock` int(11) NOT NULL DEFAULT 0 COMMENT '库存', `sales` int(11) NOT NULL DEFAULT 0 COMMENT '销量', `status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '状态：1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_seller_id` (`seller_id`), KEY `idx_category_id` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='农产品商品表';

注意到几个关键点没有：一是所有金额字段都用decimal(10,2)，绝对不用float或double——二进制浮点数在金额计算上存在精度误差，这块属于基本功了。二是价格和库存字段都加了非空约束和默认值，从数据库层面兜底非法数据。三是索引的建立讲究“查询驱动”：卖家查询自己的商品列表走seller_id，前台按类目浏览走category_id, 热门商品排序走sales字段，这才能在数据量上来之后保持查询性能。

订单表的设计比较打动人的一点是拆分了orders和order_item两张表。为什么一定要拆？因为一个订单可能包含多个商品（比如一单买了苹果和猕猴桃），如果把商品信息直接冗余在订单表里，就会出现一行塞多商品的畸形设计，后期统计、售后、对账全都无从下手。订单表记录一次交易的主体信息——订单号、用户ID、总金额、收货地址快照、支付状态；订单明细表则记录这次交易里每一个商品的单价、数量、小计金额。快照这个点很重要：收货地址、商品名称、价格在下单那一刻就必须固定下来，不能等商家改了商品信息后历史订单也跟着变。

2.2 购物车的“临时性”设计

购物车表其实非常有意思，因为它在业务上处于“用户还没决定购买”的阶段，设计目标就是轻量、易于删除重建。购物车不存冗余信息，不留状态机，一张表就够了：

CREATE TABLE `cart` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `goods_id` bigint(20) NOT NULL, `quantity` int(11) NOT NULL DEFAULT 1, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_goods` (`user_id`,`goods_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个细节很多人会忽略——为什么加唯一索引uk_user_goods？因为如果同一用户反复把同一件商品加进购物车，会出现两条记录，前端展示就要做合并处理，麻烦得很。加了唯一索引，再配合INSERT INTO ... ON DUPLICATE KEY UPDATE quantity = quantity + 1这种写法，重复加购就直接在原记录上累加数量，业务代码干干净净。购物车里不存商品实时价格也是刻意的：购物车阶段的价格仅供展示，可能在用户加购到下单之间商家调了价，因此真正的成交价必须以下单时查到的价格为准，这一步直接规避了“临门一脚涨价”引起的纠纷模拟场景。

2.3 订单编号生成方案

订单号的设计也算是一个小小的加分项。用数据库自增ID当订单号当然可以，但体验很差——订单号一长串只有数字，还容易暴露平台订单总量。我这里用的是“时间戳 + 用户ID后四位 + 随机三位数”的组合方案：

String orderNo = System.currentTimeMillis() + String.format("%04d", userId % 10000) + String.format("%03d", new Random().nextInt(1000));

好处是：不依赖额外的发号器或Redis，单机环境下并发也够用；订单号本身具备一定语义，日志里看到订单号基本能反查是哪个人在哪个时刻下的单。当然我清楚这个方案在分库分表场景下是有隐患的，但是单体项目里完全够用。和纯自增ID相比，这段拼装逻辑只有三行代码，却能给论文里的“订单号生成策略”一小节添砖加瓦。

3. 开发环境搭建与核心流程实现

3.1 从零起步的配置清单

环境这块我不建议你用最新版全家桶，原因很简单：版本越新，网上能找到的踩坑记录越少，遇到问题Google半天都没结果。这个项目的开发环境锁死在这套组合里，被我反复验证过是兼容的：

• JDK 1.8（不要用17，Spring Boot 2.x在高版本JDK下偶发兼容问题）
• Maven 3.6.x
• MySQL 8.0.x（5.7也行，注意驱动和连接串差异）
• Spring Boot 2.7.x
• MyBatis Plus 3.5.x
• IDEA 2022/2023 版本均可

数据库连接配置放在application.yml里，核心部分长这样：

spring: datasource: url: jdbc:mysql://localhost:3306/agro_market?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

配置里两个容易被忽视的细节：一是连接串必须带serverTimezone=Asia/Shanghai，否则数据库和JVM时区不一致，时间字段差8小时，排查起来心态容易崩；二是MyBatis Plus我开了map-underscore-to-camel-case，这样数据库的create_time字段才能自动映射到实体类的createTime属性，省掉写一堆@TableField注解的功夫。

注意：如果你的MySQL版本是5.7，驱动类名应是com.mysql.jdbc.Driver，8.0以后则必须用com.mysql.cj.jdbc.Driver，这里踩坑的人非常多。

3.2 订单流程：从购物车到支付成功的完整链路

订单提交是整个系统里最核心的业务流程。下面这段代码是业务层里的核心逻辑，我给它加了关键注释：

@Transactional(rollbackFor = Exception.class) public OrderVO submitOrder(OrderSubmitDTO dto, Long userId) { // 1. 从购物车中查询选中的商品项 List<Cart> cartList = cartMapper.selectList(...); if (cartList.isEmpty()) { throw new BizException("购物车为空，无法下单"); } // 2. 遍历购物车项，校验库存并计算总金额 BigDecimal totalAmount = new BigDecimal("0"); List<OrderItem> itemList = new ArrayList<>(); for (Cart cart : cartList) { Goods goods = goodsMapper.selectById(cart.getGoodsId()); if (goods == null || goods.getStatus() != 1) { throw new BizException("商品已下架: " + cart.getGoodsId()); } if (goods.getStock() < cart.getQuantity()) { throw new BizException("库存不足: " + goods.getGoodsName()); } // 计算小计金额 BigDecimal itemAmount = goods.getPrice() .multiply(new BigDecimal(cart.getQuantity())); totalAmount = totalAmount.add(itemAmount); // 组装明细 OrderItem item = new OrderItem(); item.setGoodsId(goods.getId()); item.setGoodsName(goods.getGoodsName()); item.setPrice(goods.getPrice()); item.setQuantity(cart.getQuantity()); itemList.add(item); } // 3. 生成订单号并保存订单主表 String orderNo = generateOrderNo(); Orders order = new Orders(); order.setOrderNo(orderNo); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setStatus(0); // 0待支付 orderMapper.insert(order); // 4. 批量保存订单明细 for (OrderItem item : itemList) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } // 5. 扣减库存 for (Cart cart : cartList) { goodsMapper.deductStock(cart.getGoodsId(), cart.getQuantity()); } // 6. 清空购物车中对应项 cartMapper.deleteBatchIds(cartIds); return convertToVO(order); }

@Transactional(rollbackFor = Exception.class)这个注解值得多说两句。它是保证数据一致性的关键：从校验库存到扣库存，中间任何一步抛异常，整个事务回滚，不会出现“订单建了但库存没扣”或者“库存扣了但购物车没清”的Bug。我见过很多课程项目最多给Service方法加个@Transactional就完事，但默认情况下它只对运行时异常回滚，如果业务代码里手动 catch 了异常再抛出Exception，事务是不会回滚的。所以这里必须显式指定rollbackFor = Exception.class，保险。

支付这一步，真实项目会接入第三方支付，但课程设计里一般做“模拟支付”。我的做法是提供一个支付宝风格的支付页面，点击“确认支付”后直接调用一个/order/pay/{orderNo}接口，把订单状态从0改为1（已支付）。如果你想体现一点工程思维，可以在支付回调里加个幂等校验——同一个订单重复请求支付接口，第二次直接返回“已支付”，不重复改状态。这个小细节写在论文里就是加分项。

3.3 文件上传与图片存储方案

农产品平台绕不开商品图片。商品主图、详情图都是用户（商家）上传的，所以系统里必然有一个文件上传接口。当时我没有引入OSS这种对象存储服务，而是直接把图片保存在本地磁盘，路径规则是resources/static/upload/日期/时间戳.jpg。上传接口接收MultipartFile，保存后返回一个可访问的相对路径，前端img标签直接拼静态资源地址就能显示。

这个方案的局限性很明显——本地磁盘空间有限，服务器重启后文件可能丢失。但对于单机部署的课设项目，简单易用就是最大的优点。我把文件路径存在数据库的main_image字段里，前端模板直接用了Thymeleaf的URL表达式解析，没有额外的代理配置。如果你的部署环境不允许写本地磁盘，可以换OSS，但这会引入Bucket、Endpoint、AccessKey等一系列配置，对课设来说徒增复杂度。先本地，以后有需要再迁移，是性价比最高的做法。

4. 开发调试中的血泪笔记与常见问题排查

4.1 数据库连接失败的几种典型症状

几乎每个第一次跑Spring Boot + MySQL项目的同学都会在数据库连接上卡住。我在这套系统调试阶段总结出三类高频报错，直接对照排查：

其中allowPublicKeyRetrieval这个参数最坑。MySQL 8.0 用户密码传输默认要求先取服务器公钥，但客户端驱动出于安全考虑默认不允许这个过程，于是连数据库直接抛异常。这个报错本身没有歧义，难的是很多同学根本搜不到准确关键词，因为这个参数太冷门了。

4.2 表格字段映射错误：驼峰命名翻车现场

用MyBatis Plus有一类错误极其隐蔽：数据库字段名是下划线风格（create_time），实体类属性是驼峰风格（createTime），正常情况下配置了map-underscore-to-camel-case: true就能自动映射。但如果你在某个实体类上手动加了@TableField注解并写错了字段名，比如把数据库的goods_name拼成了goodsNamee，MyBatis Plus会直接报“字段 goodsNamee 不存在”，而且这个错误只会在运行到对应查询时出现，启动阶段根本不会暴露。所以初始化项目后建议第一时间写一个简单的接口测试每个表的Mapper，把所有表都查一遍，提前排雷。

另外还有一个高频场景：实体类里添加了数据库不存在的新字段，MyBatis Plus默认查询是把实体类所有字段带进SQL里的，新增字段会导致SQL报错“Unknown column”。解决办法是在这个字段上标注@TableField(exist = false)，告诉MyBatis Plus这是一个非数据库字段，不参与SQL拼接。这个坑你自己踩一次就会记住，不信你试试。

4.3 登录会话与拦截器的组合实践

用户登录状态管理，这个系统采用的是最简单的Session方案：用户登录成功之后，把User对象放进Session，然后写一个拦截器LoginInterceptor，拦截需要登录态的路径。拦截器的配置我放在WebMvcConfigurer实现类里，核心逻辑如下：

public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/user/**", "/cart/**", "/order/**") .excludePathPatterns("/", "/goods/**", "/category/**", "/user/login", "/user/register"); }

这个拦截器的编写思路很直接：addPathPatterns声明要保护的路径，excludePathPatterns放行不需要登录就能访问的页面。这里有一个开发中常见到让人抓狂的现象：前端页面跳转时，请求路径明明在前缀列表里，但拦截器就是不生效。原因大概率是前缀写错——比如访问路径是/userInfo/index，而拦截器配的是/user/**就不会匹配，因为userInfo和user不是同一个前缀。所以写拦截路径时一定要前后端对齐，建议所有需要登录的页面统一放到相同的前缀目录下，从根上减少这类问题。

Session方案在并发量大时不太可靠，但课设和内部系统完全没问题。如果后续想升级成JWT或Spring Security，拦截器模式的登录校验也能平滑过渡，因为校验逻辑都集中在拦截器里，改动范围可控。

4.4 前端页面经典Bug：相对路径引用静态资源

用Thymeleaf做服务端渲染，静态资源的引用方式是有讲究的。最容易犯的错是页面里直接写src="/upload/1.jpg"这种绝对路径，一旦当前请求被转发到子路径下（比如/user/index），浏览器会把路径解析成http://localhost:8080/user/upload/1.jpg，图片就挂了。正确的写法应该用Thymeleaf的URL表达式：

<img th:src="@{/upload/${goods.mainImage}}" alt="商品图">

th:src="@{...}"会自动拼接应用的ContextPath，不管当前请求在哪一层，都能正确解析到http://localhost:8080/upload/xxx.jpg。这个细节在Bootstrap模板里尤其常见，因为原模板往往写死了资源路径，换到Spring Boot项目里就会失灵。所有样式表、脚本、图片的引用统一改用th:href、th:src或者@{}表达式，能省掉非常多的“路径找不到”问题。

5. 部署上线：从本地IDE到生产环境的最后一公里

5.1 Maven打包与启动

项目开发完，最终的交付形式是mvn clean package打出来的可执行Jar包。打包前有两点必须确认：一是本地测试用的application.yml和数据源配置不能带入生产包——我一般会单独维护一份生产环境的配置文件，打包时通过spring.profiles.active切换；二是检查静态资源有没有遗漏，尤其是上传目录和初始图片，有些同学打完包发现图片404，就是没把src/main/resources/static/upload里的文件一起打包进去。

打好的Jar包启动非常简单：

java -jar agro-market-0.0.1-SNAPSHOT.jar --server.port=8080

如果你想部署到服务器上，建议配合nohup做后台运行，并让日志输出到文件：

nohup java -jar agro-market-0.0.1-SNAPSHOT.jar > server.log 2>&1 &

这样部署的好处是服务器重启后，Jar包还能通过一条命令自动拉起来，配合系统的初始化脚本，就算不会Docker也能把项目跑得稳稳当当。当然，如果你对容器化感兴趣，可以再把 JRE 塞进一个镜像里，做成Docker容器部署，那就是进阶话题了。

5.2 数据库脚本的初始化与迁移

项目自带的SQL脚本不只包含建表语句，还预置了初始化数据：默认管理员账号、几个测试商家、若干农产品分类和一些演示商品。为了让评委或者导师打开系统就能看到内容，这些种子数据非常重要。如果你拿到的项目SQL脚本里没有这些，一定要自己手动补上。我通常会在脚本末尾加一段：

INSERT INTO `user` (username, password, role, nickname) VALUES ('admin', MD5('123456'), 2, '系统管理员'), ('seller001', MD5('123456'), 1, '测试商家'), ('buyer001', MD5('123456'), 0, '测试用户');

这里用MD5加密只是因为课设方便演示，生产环境绝对不能用MD5存储密码，但作为默认测试账号插入脚本，问题不大。要注意的是，不同环境的数据库编码必须统一成utf8mb4，尤其是插入的商品名称含中文时，如果库表字符集不对会出现乱码，这在电商平台项目里是极其难看的事故。

5.3 演示环境里的性能优化小技巧

最后一个实用技巧是——如果你要现场演示系统，一定要提前做好性能准备。本地IDE跑的时候，第一次冷启动会比较慢，因为Spring Boot要初始化一堆Bean；但演示时打开页面的速度也尽量不要超过2秒。我实测下来有两个方法效果最明显：一是数据库表里数据量控制在合理范围，不要为了测试灌几十万条垃圾数据，除非你做了分页查询和索引优化；二是把页面里高频使用的图片压缩到100KB以内。农产品图片本来就是大色块、自然光线下拍摄的多，同样尺寸的JPG压缩到80%质量和原图肉眼几乎看不出区别，但加载速度能快一大截。

如果你手头正好在做这个项目，建议跑完一遍完整流程再动手改代码——从用户注册开始，到商家上架商品、用户下单、商家发货、用户确认收货，把整个业务闭环走通，你会对这套系统的设计逻辑有更透明的理解。等到你真正把它改造成自己想要的样子时，这份积累才不会白费。

最后分享一个我做项目的习惯：永远在代码里留几个“有意思的设计点”给论文当素材。比如订单号生成策略、事务回滚机制、购物车唯一索引、图片上传方案，每一个都是可以在论文里单独写成一个小节的细节。这些东西不需要多高端，但它们能向读者和答辩导师证明，你是真的在写一个能用的系统，而不是在“画页面”。项目源码、数据库脚本、环境配置都已经打包好了，如果你正在做类似的课题，按这篇文章的思路去复盘一遍自己的代码，应该能避开不少坑。祝调试顺利。