SpringBoot农产品交易平台毕设实战：从需求拆解到订单溯源全流程-平芜编程栈

1. 项目概述与需求拆解

1.1 农产品交易平台到底解决了什么问题

做了这么多年Java后端，见过太多同学一上来就急着建表、写接口，结果做到一半发现业务逻辑捋不清，推倒重来。农产品交易平台这个题目之所以在毕业设计里长盛不衰，核心在于它的业务场景非常贴近真实电商系统，但又没有企业级商城那么庞大复杂，非常适合作为SpringBoot的练手项目。

先拆解一下“农产品交易平台”这个名词。表面上看是“卖菜网站”，但往深了想，它至少包含三个层面的业务诉求。

第一层是供需匹配。农户手里有蔬菜、水果、粮油，消费者想买新鲜、便宜的农产品，平台要解决的是“谁的东西卖给谁”的问题。这就涉及到商品发布、分类浏览、搜索筛选、购物车、下单支付这一整套交易链路。

第二层是信任背书。农产品和非标工业品不一样，消费者会关心“这菜打没打农药”“这米是哪个产地来的”。所以平台需要有农产品溯源、资质认证、评价体系这些功能，这也是区别于普通二手交易平台的关键点。

第三层是运营管理。平台方需要审核商家资质、管理商品上下架、处理订单退款纠纷、统计销售数据。这些需求对应后台管理端的订单管理、用户管理、商品审核、数据报表等模块。

如果只是简单做一个“商品增删改查”的CRUD系统，那这个项目在答辩的时候会被老师一句话问住：“你的平台和超市收银系统有什么区别？”所以我在设计这个项目的时候，把重心放在了“农业特色功能”的落地上面，溯源信息、产地展示、农产品分类这些都属于必做项。

1.2 目标用户与核心角色模型

这里先定一个结论：任何电商类的毕设项目，先把角色理清楚，后面的代码写起来才顺。农产品交易平台我把它拆成四种角色，分别对应不同的功能权限。

游客：只能浏览商品、查看公告，需要登录后才能下单操作。
注册用户（买家）：可以维护个人信息、浏览商品、加入购物车、提交订单、在线支付（模拟）、确认收货、发表评价、查看溯源信息。
商家用户：可以申请入驻、发布农产品、管理自家商品、处理订单发货、查看销售统计。
平台管理员：负责用户管理、商家入驻审核、商品审核上下架、分类管理、公告管理、订单监管、数据统计。

这个角色模型其实对应了RBAC（基于角色的访问控制）的设计思想。在SpringBoot里实现起来也不复杂，用一张用户表加一个角色字段，配合拦截器或Spring Security做接口权限控制就够了。不需要过度设计，搞一堆菜单权限表什么的，毕设阶段把角色和核心业务衔接清楚，就是加分项。

至于为什么要把“商家”和“买家”分开而不是搞一个“既是买家又是卖家”的复合角色——因为农产品交易平台里面农户和消费者是两种完全不同的使用心智，商家端关心的是商品上架、库存和订单处理，买家端关心的是逛、挑、买、评。把两种操作混在一起，不仅前端页面逻辑混乱，后端接口的权限校验也会变得很麻烦。

1.3 项目的核心功能清单

基于上面的角色模型，我在实际开发中把功能模块拆成了下面这张表，可以直接作为需求文档的骨架用：

模块	功能点	对应角色
用户模块	注册、登录、个人信息管理、密码加密存储	买家/商家/管理员
商家入驻模块	提交入驻申请、资质信息填写、管理员审核	商家/管理员
商品模块	商品发布、商品编辑、上下架、分类管理	商家/管理员/买家
交易模块	购物车、订单提交、订单状态流转、支付模拟	买家/商家
评价模块	订单完成后发表评价、查看商品评分	买家
溯源模块	农产品溯源信息录入与展示	商家/买家
公告模块	平台公告发布、前台公告展示	管理员/游客
数据统计模块	销售统计、用户统计、商品统计	管理员/商家

功能清单整理完以后，你会发现整个项目的脉络一下就清楚了：买家登录进来逛商品，看到合适的加入购物车，下订单付钱，商家发货买家收货，最后评价；管理员在后台审核商家、管理商品、处理订单。这一套流程走通，业务闭环就成立了。

2. 技术架构与数据库模型设计

2.1 为什么选择SpringBoot作为核心框架

SpringBoot在毕业设计里的统治地位不是没有道理的。对于农产品交易平台这种典型业务系统，SpringBoot提供了极为成熟的生态支持，而且大幅降低了开发的繁琐程度。

我最早也纠结过要不要用SpringCloud那一套微服务方案，后来想明白了——毕设项目除了答辩展示，更重要的是可运行、可演示、代码结构可控。微服务拆八个服务，光是环境搭建就能让人崩溃。SpringBoot单体应用足够承载这个体量的业务，而且内嵌Tomcat的特性让项目部署非常简单，打一个jar包扔到服务器上就能跑起来。

具体的技术选型我的建议是：

核心框架：SpringBoot 2.x
ORM框架：MyBatis-Plus（省去大量XML编写，分页查询直接PageHelper或用Plus内置的分页插件）
数据库：MySQL 5.7+（8.0也可以，但要注意驱动依赖版本）
前端方案：Thymeleaf模板引擎或前后端分离（Vue + Axios）
权限控制：Spring Security或Sa-Token
工具库：Hutool、Lombok、Commons-Lang3

这里有个比较现实的考量：如果你更擅长写后端，前端用模板引擎Thymeleaf会省心很多，页面直接写在resources/templates下面，通过Controller跳转就行；如果你对Vue比较熟，那就前后端分离，前端用Vite或者Webpack起一个工程，后端只提供JSON接口。两种方案各有优劣，但从答辩效果来看，前后端分离的视觉效果更好，毕竟页面独立渲染，交互也更细腻。

我这次选的是前后端分离，后端按标准RESTful风格提供接口，用Swagger自动生成接口文档，答辩演示的时候直接打开Swagger页面给老师看接口设计，比对着无脑页面讲半天要专业得多。

2.2 数据库表结构设计的核心思路

数据库设计是整个项目的基石，表结构如果设计得合理，后面写业务代码会非常顺畅。农产品交易平台我最终设计出来的核心表大概有十一张左右：

用户表（user）：用户ID、用户名、密码、昵称、头像、手机号、角色类型、状态
商家信息表（merchant_info）：入驻申请ID、用户ID、店铺名称、联系人、联系电话、店铺简介、资质图片、审核状态
商品分类表（product_category）：分类ID、分类名称、父分类ID、图标、排序
商品表（product）：商品ID、商家ID、分类ID、商品名称、主图、描述、价格、库存、单位、产地、上架状态
溯源信息表（traceability_info）：溯源ID、商品ID、产地、播种日期、施肥记录、采摘日期、检测报告、录入时间
购物车表（cart_item）：购物车ID、用户ID、商品ID、数量、加入时间
订单表（order）：订单ID、订单编号、用户ID、商家ID、总金额、订单状态、收货信息、创建时间、支付时间、发货时间、完成时间
订单明细表（order_item）：明细ID、订单ID、商品ID、商品名称、购买单价、购买数量
评价表（review）：评价ID、订单ID、商品ID、用户ID、评分、评价内容、评价时间
公告表（notice）：公告ID、标题、内容、发布时间、发布人
管理员操作日志表（operation_log）：日志ID、操作用户ID、操作类型、操作描述、操作时间

核心关联关系说几个容易踩坑的点：

第一，订单和商家之间的关系。一个订单只能归属一个商家（前提是购物车结算时只结算同一商家的商品），所以订单表里直接存merchant_id没有问题。如果你想让用户跨店合并下单，那订单和订单明细之间的关系就要做成分层的和主从结。毕设阶段建议做成单商家订单，购物车结算的时候按商家维度拆单，逻辑会清爽很多。

第二，商品表和溯源信息表的关联。一块地的蔬菜可能是分批采摘的，同一商品在不同批次可以有不同溯源记录。所以溯源信息表不要和商品表一对一强绑，而是通过product_id关联，允许一个商品有多条溯源记录，展示的时候取最新一条或汇总展示。

第三，订单状态的设计。我用整数状态码表示订单流转状态：0待付款、1待发货、2待收货、3已完成、4已取消。状态流转顺序是：0 → 1 → 2 → 3，其中待付款状态可以变成4（超时或用户主动取消），待发货状态商家也可以取消。这套状态机很简单，但是在写控制层的时候一定要做状态校验，比如用户不能对“已完成”的订单发起“确认收货”操作。

2.3 MyBatis-Plus加速开发的实际用法

MyBatis-Plus确实能让开发效率提升一个档次。农产品交易平台里，用户、商品、订单这些实体类基本都是常规的增删改查，Plus的BaseMapper和IService接口直接帮你把这些都生成好了。

一个实际的使用示例是这样的：

// 实体类 @Data @TableName("product") public class Product { @TableId(type = IdType.AUTO) private Integer id; private Integer merchantId; private Integer categoryId; private String name; private String mainImage; private String description; private BigDecimal price; private Integer stock; private String unit; private String origin; private Integer status; // 1上架 0下架 } // Mapper接口 @Mapper public interface ProductMapper extends BaseMapper<Product> { // 这里可以写自定义SQL } // Service @Service public class ProductService extends ServiceImpl<ProductMapper, Product> { // 继承IService后，save、updateById、list等方法直接用 }

分页查询用Plus自带的分页插件也简洁：

Page<Product> page = new Page<>(current, size); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getStatus, 1) .eq(categoryId != null, Product::getCategoryId, categoryId) .like(keyword != null, Product::getName, keyword) .orderByDesc(Product::getCreateTime); Page<Product> result = productService.page(page, wrapper);

LambdaQueryWrapper用起来最大的好处是类型安全，字段名不会因为写错字符串而报运行时错误，编译期就能发现。这个对毕设项目的调试帮助非常大。

3. 核心功能模块的实现要点

3.1 用户认证与密码安全处理

用户认证这块我踩过一个印象很深刻的坑：一开始图省事，把用户密码明文存进数据库，想着反正是模拟项目，不会有人真的攻击。后来项目做到商家入驻和订单支付环节，我突然意识到，如果密码不加密，整个系统的登录态保护就是形同虚设——数据库一旦泄露，所有用户的密码全部裸奔。

正确的做法是使用加密算法处理密码，不能MD5加盐就完事了，最好是BCrypt。Spring Security里自带了BCryptPasswordEncoder，使用起来非常简单：

@Bean public BCryptPasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } // 注册时加密存储 String encodedPassword = passwordEncoder().encode(rawPassword); user.setPassword(encodedPassword); // 登录校验 boolean matches = passwordEncoder().matches(rawPassword, user.getPassword());

BCrypt是自适应哈希算法，它内部自动加盐，而且每次哈希结果都不一样。同一个密码加密两次得到的字符串不同，但matches方法都能校验通过。这样就算数据库被人脱库，攻击者也没法通过彩虹表反推出原始密码。

登录状态这块我采用的是Token机制。用户登录成功后生成一个UUID或直接用JWT作为token，存到Redis里设置过期时间，前端每次请求在Header里带上token，后端写一个拦截器校验token是否存在、是否过期。配合Redis的过期时间，可以实现用户7天内免登录的效果。

这里有个小技巧：拦截器里写一个UserContext工具类，用ThreadLocal存储当前登录用户的信息，后续的业务代码直接通过UserContext.getUserId()获取用户ID，不用再反复从token里解析了。注意请求结束之后要调用remove()清理ThreadLocal，防止内存泄漏。

3.2 商品管理模块的设计与实现

商品模块是核心中的核心。从商家发布商品，到管理员审核上架，再到用户浏览购买，每个环节都要做信息流的流转。

商品发布流程我的建议是：商家提交商品信息时，状态默认设置为0（待审核）。管理员在后台看到待审核列表，点击审核通过后状态变为1（已上架）；如果审核不通过，商家需要修改后重新提交。这套审核机制是农产品交易平台区别于普通C2C商城的重要特点——因为农产品涉及食品安全，平台必须承担监管责任。

商品属性这里有一个容易被忽略的点：农产品跟普通商品最大的区别在于有“产地”和“单位”的概念。页面上一斤西红柿和一份精品水果礼盒，价格和计重方式完全不同，所以“产地（origin）”和“单位（unit）”这两个字段建议和价格字段一起放在商品主表里，不要丢到扩展属性表去。

商品列表页的性能优化也是值得在答辩时提的点。农产品图片相对比较大，如果每次查询商品列表都把大图字段传回前端，加载会很慢。我的做法是在数据库查询时排除掉description这种大字段，只返回列表展示需要的数据，详情页再查全字段。用MyBatis-Plus实现就是：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.select(Product.class, i -> !i.getColumn().equals("description")) .eq(Product::getStatus, 1);

3.3 购物车与订单交易链路

购物车的实现相对简单，每个用户持有一条条购物车记录，记录着商品ID、数量、加入时间。用户每次加入购物车时需要判断：如果购物车里已经有这个商品了，那就数量增加，不用重复插入一条新记录。

订单这块是整个系统的业务核心，也是最容易出现BUG的地方。我在实际开发中遇到的第一个问题就是订单编号的生成方案。一开始用时间戳加随机数，结果并发场景下偶尔会撞号。后来改成了经典方案：日期+随机数，前面加上订单类型标识符：

String orderNo = "ORD" + DateTimeFormatter.ofPattern("yyyyMMddHHmmss").format(LocalDateTime.now()) + String.format("%04d", ThreadLocalRandom.current().nextInt(1000));

下单的流程要区分几个关键步骤。首先从购物车中取出选中的商品，以商家维度拆单，计算总金额；然后创建订单主记录，状态为待付款；再批量插入订单明细分录。一个重要的细节是：下单时要把商品的价格和名称快照到订单明细里，而不能只存商品ID。因为商品价格会变动、商品可能会被下架删除，如果不下架快照，以后查看历史订单就会看到错误的金额。

下单过程中要处理库存扣减的问题。生产级的方案应该是先扣库存再创建订单，如果库存不足就抛出业务异常。为了防并发超卖，我在扣库存的时候用了带条件的更新语句：

boolean success = productService.lambdaUpdate() .setSql("stock = stock - " + quantity) .eq(Product::getId, productId) .ge(Product::getStock, quantity) .update(); if (!success) { throw new BusinessException("库存不足"); }

这条SQL的核心思路是：先判断库存是否充足，同时扣除库存，两步合并为一步，避免了并发场景下两个请求同时读到相同库存量的问题。这属于乐观锁的一种简单实现。

支付模块我用的是模拟支付：用户点击“立即支付”按钮，系统生成一个假的支付流水号，直接把订单状态从待付款改为待发货。在答辩现场用支付宝沙箱或微信支付沙箱也可以，但模拟支付不会因为网络原因掉链子，演示起来更稳定。

3.4 农产品溯源模块的独特价值

溯源模块是农产品交易平台区别于普通电商平台的特色功能。这个模块经常被同学忽略，但它恰恰是选题里最能在答辩时讲出亮点的部分。

我的实现思路是这样的：商家在发布每个商品时，可以在商品详情页填写溯源信息，包括种植地、采摘日期、质检报告图片等。这些数据录入到溯源表中，前台商品详情页展示一个“查看溯源”的入口，点击进去能看到这块农产品的产地、播种日期、施肥记录和检测报告等信息。

溯源数据的录入没有做成强制流程，因为如果做成必填项，商家录入成本太高，易产生抵触情绪。我的做法是在商品详情页做“补充溯源信息”的提示入口，商家能填多少填多少。对于关键字段如产地，则要求必填。这个折中方案既保证了基本体验，又保留了溯源功能的完整性。

在数据库层面，溯源信息表我设计成和商品表是一对多的关系。原因是同一农产品的不同批次，生长信息是独立的。比如一批西红柿是3月播种、5月采摘，另一批是5月播种、7月采摘，溯源信息应该按批次区分，而不是简单覆盖。

3.5 后台管理端与数据统计

管理端我用的是独立的页面模块。管理员登录后能看到仪表盘、用户管理、商品审核、订单管理、分类管理、公告管理等入口。

仪表盘的数据统计用ECharts展示效果很好，支持折线图、柱状图和环形图。举几个适合展示的统计口径：

近7天订单数量趋势（折线图）
商品分类销量占比（环形图）
各商家销售额排行（柱状图）
用户注册量趋势（折线图）

这些统计SQL都很简单，比如计算分类销量的SQL大致是：

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

需要注意的坑是：订单明细里的商品名称虽然我做了快照，但分类信息没有快照。如果分类被删除或改名，历史统计数据会变得不准。毕设阶段可以接受，但如果要严谨，应该给订单明细也冗余一个category_name字段。

3.6 前端页面与部署演示策略

前端部分我选用的Vue 3加Element Plus，页面包括首页、商品列表、商品详情、购物车、订单确认、个人中心、商家后台、管理后台。这套组合生态成熟，组件好看，开发速度快。

这里给动手能力弱一点的同学一个诚实的建议：如果前端端架子和CSS对你来说实在费劲，可以先用模板引擎Thymeleaf把完整的业务跑通，再逐步用Vue替换其中核心的几个页面。毕设答辩的核心还是后端业务逻辑的完整性和技术深度的体现，前端只要整齐美观、流程闭环，就已经达标了。

部署演示这一块，我的终版方案是:一台轻量应用服务器（2核4G完全够用），装好JDK 8和MySQL,然后把项目打包成jar包，通过systemd配置成守护进程运行。演示时打开浏览器访问域名，把商品信息、登录演示、下单流程完整过一遍，流畅度会比本地跑还好。

顺便说说部署的坑：JDK版本和打包环境要保持一致，本地是JDK8那服务器也装JDK8，避免出现Class版本冲突。数据库连接串记得把useSSL设成false，避免SSL握手阶段卡住。这些不起眼的细节，往往就是演示现场翻车的罪魁祸首。

4. 关键问题排查与排错实录

4.1 购物车商品重复插入问题

这个问题出现的频率极高。用户快速点击“加入购物车”按钮两次，前端发出了两个并发请求，后端没有做重复判断，结果购物车里出现了一模一样的商品记录，数量各为一。

排错思路很简单：后端在处理加入购物车的逻辑里，先根据userId和productId查一下购物车表，如果已存在该记录，就做数量更新而不是新增插入。为了彻底解决并发场景下的重复插入，我在购物车表上加了唯一索引（user_id, product_id），作为兜底防线。再加上前端对按钮做防重复提交处理，三管齐下才把这个隐患彻底排除。

4.2 订单金额精度问题

系统刚跑起来的时候，我自己测试了一单，订单总金额算出来是59.60000000000001。这种浮点精度问题是Java开发里典型的坑，直接原因是把商品价格和数量用double类型做了乘法运算。

解决的方案也很经典：金额一律用BigDecimal，构造时用字符串而不是double，加减乘除都走BigDecimal的方法。如果数据库字段是decimal，MyBatis-Plus自动映射成BigDecimal，那就不会有精度损失。

BigDecimal totalAmount = BigDecimal.ZERO; for (CartItem item : cartItems) { totalAmount = totalAmount.add( new BigDecimal(item.getProductPrice().toString()) .multiply(new BigDecimal(item.getQuantity())) ); } order.setTotalAmount(totalAmount);

另外还要注意一个细节：前端展示金额的时候，如果BigDecimal的位数过长，页面会显示得很丑。上送数据库前统一调用setScale(2, RoundingMode.HALF_UP)保留两位小数。

4.3 订单状态卡死无法流转

这个问题是我在联调订单流程时发现的：用户支付成功后订单状态确实更新成了待发货，但商家发货之后订单状态却始终没有变成待收货状态。查看日志发现，商家点击发货时后端直接报了一个空指针异常。

排查过程是这样的：先看发货接口的入参，商家传的是订单ID，后端根据订单ID去查订单，按道理不会查不到。再往下看，发货的时候我要往快递单号字段里写值，该字段在数据库中允许为空，但实体类里用的是基本数据类型String，结构上没问题。继续看，发现问题出在一个不该加的逻辑：发货时顺手去查询了商家信息，然后对商家联系人做非空判断，结果这家测试商家的联系人字段是空的，就掀了桌子。

解决方法很简单：把不确定是否有值的字段都做空值判断，或者用Optional来包装。发货逻辑本身不依赖商家联系人字段，就把那段多余的校验直接删掉。有时候代码里写着写着就写进去了一些“防御性”逻辑，反而平添风险。

4.4 商品图片无法显示的问题

本地开发时图片正常显示，部署到服务器之后就裂了。排查后确定路径是：前端页面的图片地址写的是本地路径，而上传时图片存在了本机磁盘的某个目录，部署后自然找不到。

处理方案是统一使用相对路径加虚拟目录映射的方式。SpringBoot里可以通过配置把本地磁盘目录映射成URL访问路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

同时在前端把所有图片地址拼接成统一前缀，不要在数据库里存全路径，只存相对路径，比如/upload/20240601/xxx.jpg。这样一来，环境和域名怎么换，只要拼接前缀不变，图片就能正常展示。

4.5 管理后台菜单权限绕过漏洞

这个漏洞是我在做安全自测时自己发现的。普通用户修改浏览器URL，直接跳到管理后台的页面地址，虽然页面加载了但没有数据，不过某些GET请求接口可以直接用URL访问后返回JSON数据，等于接口层面没有做权限校验。

排查下来就是Controller层的接口漏加了权限注解。最后我用拦截器统一处理：判断请求的URL是否以/admin开头，是则校验当前用户的角色和管理员角色是否匹配。这比逐个接口加注解更安全，只要路径规范，基本不会漏。

测试的时候我建议把“普通用户访问管理接口返回什么”当成一个必测用例来查，因为线上系统很多安全漏洞都是这样被翻出来的：能打开页面不算什么，能拿着普通用户的token调用管理接口才危险。

5. 项目扩展方向与答辩亮点参考

5.1 技术层面的加分改进

如果时间和精力允许，有几个方向可以让项目再上一个台阶，在答辩时明显加分。

引入Redis缓存。商品列表页是访问频率最高的页面，把热点商品缓存到Redis里，查询的时候走缓存，可以明显降低数据库压力。这个点在答辩时拿出来讲“缓存穿透、击穿、雪崩”的概念，面试官或答辩老师会很感兴趣，因为这是企业级开发里非常核心的议题。

定时任务做订单关闭。用Spring的@Scheduled注解或者Quartz做一个定时任务，每两分钟扫描一次待付款订单，超过30分钟未支付的自动改成已取消，同时回补库存。这个需求点在真实电商场景里极其常见，实现成本不高，但业务完整性会强很多。

接入WebSocket做消息通知。买家下单后，商家端页面实时弹出一条“新订单”的通知。WebSocket的实时性效果在答辩演示的时候非常惊艳，代码量也不算大。

5.2 业务层面的差异化设计

更建议在业务逻辑层面做一些差异化的思考。举例说，农产品交易平台可以做“时令农产品推荐”功能，根据当前季节自动展示应季商品；或者做“农产品拼团”玩法，凑满三人享折扣；或者做“助农专区”，平台对特定农户商品减免佣金并优先推广。这些小的业务亮点并不需要很高的技术难度，但能让评委感受到你对农业领域业务逻辑的理解深度，而不是只会做增删改查。

“时令推荐”的实现逻辑并不复杂：农产品的季节属性体现在分类上，比如“春季野菜”“夏季西瓜”“秋季大闸蟹”“冬季柑橘”,在商品表里加一个season字段，写个定时任务在季节交替时切换推荐位商品即可。这种小功能讲出来很有场景感，老师的印象分一下子就会上来。

5.3 论文与答辩中容易被问到的问题

论文和答辩是毕设的重头戏，提前准备几个高频问题是必要的。导师大概率会问这些：

一是“你这个项目的核心难点在哪里”。不要回答说“前端页面很多”“SQL写了好几百行”，这不能体现水平。可以说：为了保证订单并发场景下数据的一致性，在库存扣减环节使用了乐观锁的更新策略，通过影响行数来确认库存更新是否成功，从而避免超卖问题。这就讲出了核心设计考量。

二是“你为什么选这个框架/为什么这样设计数据库”。回答的思路一定要落脚在“业务驱动技术选型”而不是“看着教程选的”。比如选用SpringBoot的理由是它对快速构建单体业务系统有天然优势，内嵌Tomcat为项目部署降低了复杂度；数据库表拆分则依据业务模块的领域边界，让订单、商品、用户三个核心域解耦，便于后续扩展。

三是“如果让你继续做下去，你会怎么改”。不要含糊说“加个功能就行”，要把方向和具体的实现路径讲出来。比如我想把单商家订单改成多商家合并支付，订单结构需要调整为订单主表加子订单表的方式，同时引入分布式事务保证拆单和支付的一致性。这展示了你对业务演进和技术方案演进的全链路思考能力。

6. 个人实操体会与推荐建议

整个项目做下来的最大感受是：农产品交易平台这个选题其实很适合作为SpringBoot入门到进阶的集成训练。它的业务链路完整，角色划分清晰，数据模型复杂度适中，前端交互也足够丰富。一个能跑通的完整系统，比十个半成品带来的成就感要强烈得多。

说两个比较实在的建议。

第一，先动脑再动手。动手写代码前，花两周时间把需求文档、数据库设计、接口清单全部列出来，画清楚订单状态机和角色权限矩阵。我最早就是因为图快直接上手敲代码，结果中后期改表结构改了不下五次，每次都牵一发动全身。后来按“先设计后开发”的流程走了第二版，效率反而高了不少。

第二，日志和注释要写成给人看的。不管是用SLF4J打印关键业务日志，还是在Controller和Service层的关键方法上写注释说明业务意图，这些习惯在你自己调试和答辩讲解的时候都会救你一命。别觉得注释是浪费时间，三个月后的你回过头看自己的代码，会感谢当时的你写了两句人话。

最后再分享一个可以利用的小技巧——演示前一定要准备一套“完整演示剧本”。先用买家账号逛商品加购物车，下单支付；切到商家账号发货；再切回买家确认收货评价；最后切管理员账号审核一个商家入驻申请，把审核、上架、交易、评价的完整闭环展示一遍。这套剧本流畅走完，基本就已经稳了。农产品交易平台这类项目，比拼的不是哪个功能炫酷，而是整个业务流程是否闭环、落落大方。预祝你的毕设顺利通过。