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.xORM框架MyBatis-Plus省去大量XML编写分页查询直接PageHelper或用Plus内置的分页插件数据库MySQL 5.78.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 BaseMapperProduct { // 这里可以写自定义SQL } // Service Service public class ProductService extends ServiceImplProductMapper, Product { // 继承IService后save、updateById、list等方法直接用 }分页查询用Plus自带的分页插件也简洁PageProduct page new Page(current, size); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, 1) .eq(categoryId ! null, Product::getCategoryId, categoryId) .like(keyword ! null, Product::getName, keyword) .orderByDesc(Product::getCreateTime); PageProduct 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实现就是LambdaQueryWrapperProduct 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的方法。如果数据库字段是decimalMyBatis-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层的关键方法上写注释说明业务意图这些习惯在你自己调试和答辩讲解的时候都会救你一命。别觉得注释是浪费时间三个月后的你回过头看自己的代码会感谢当时的你写了两句人话。最后再分享一个可以利用的小技巧——演示前一定要准备一套“完整演示剧本”。先用买家账号逛商品加购物车下单支付切到商家账号发货再切回买家确认收货评价最后切管理员账号审核一个商家入驻申请把审核、上架、交易、评价的完整闭环展示一遍。这套剧本流畅走完基本就已经稳了。农产品交易平台这类项目比拼的不是哪个功能炫酷而是整个业务流程是否闭环、落落大方。预祝你的毕设顺利通过。