每年毕业季都有一批人被毕业设计选题折磨得睡不着，选电商类的怕太烂大街，选算法类的又怕自己啃不动。如果你手头拿到的是"基于微信小程序的农产品交易平台"这类题目，先别急着嫌弃它不够高大上——这种题恰恰是Java后端方向最稳、最好出彩、也最容易讲清楚的选择。尤其是加了"多途径多身份""多元化角色""产销对接"这几个修饰词之后，难度和竞争力完全不一样了。
这类题目的本质，是做一个连接农户、采购商、普通消费者、平台管理员四类角色的农产品电商系统，前端跑在微信小程序里，后端用Java技术栈支撑。它能做的不只是"把菜放到网上卖"，而是围绕农产品流通中的信息不对称、中间环节多、产销匹配难这些真实问题，设计一套多端协同的交易闭环。这套题覆盖了登录鉴权、商品管理、订单状态机、支付回调、权限控制、数据统计这些核心开发能力，无论是找Java后端还是小程序开发的工作，都拿得出手。
这篇文章我会按我做这类项目时的完整思路，把这套系统从需求拆解、技术选型、数据库设计、核心模块实现到踩坑记录一条线讲透，争取让你看完之后直接能动手，不用再到处翻零散资料。
1. 农产品交易到底难在哪：选题背后的真实业务逻辑
很多人拿到这道题第一反应是"做个商城，能下单就行"。真这么做下去，答辩时大概率会被问住。因为"农产品自主交易平台"和普通商城最大的区别，在于它的业务模型更复杂，角色更多，交易场景也不是简单的买家付款卖家发货。
1.1 农产品流通的痛点决定了系统要有哪些功能
农产品和工业品不一样，它有极强的时效性、季节性和非标准化特征。一筐草莓摘下来，今天卖不掉明天品质就下降；一个农户种了几亩蔬菜，面对的可能是批发市场里层层加价的经销商，也可能是小区门口几个固定的菜贩子。传统流通模式里，农户没有定价权，消费者买到的也不是一手价格，中间的信息断层和信任缺失是长期存在的。
所以这个平台的设计目标不是"做个漂亮的小程序页面"，而是解决三个具体问题：
第一，产销信息对接。农户能把即将上市的农产品提前挂出来，采购商能按品类、产区、上市时间去找货源，普通消费者能看到产地直发的东西。
第二，多角色差异化服务。农户需要的是发布和管理货源、接收订单；采购商需要的是批量询价、议价、大宗采购；普通消费者需要的是一站式下单和售后；管理员需要的是审核商品、处理纠纷、看交易数据。四类角色如果共用一套界面和逻辑，体验会非常差。
第三，交易流程的自主性。题目强调"自主交易"，意味着平台不能只做信息展示，要支持农户自主定价、采购商自主下单、双方协商交易方式和配送方式。这就引出了订单状态的多条流转路径。
1.2 "多途径多身份"这几个词到底要求你做什么
你如果细看题目里几个关键词——"多途径""多身份""多端融合""多元化角色"——会发现它其实给你划定了系统设计的最低标准。
- 多身份：至少包含农户、采购商、普通用户、管理员四类角色，每类角色登录后看到的界面、能操作的功能完全不同。
- 多途径：可以解成两种理解，一种是多端接入（小程序端、Web管理端、H5端），另一种是多种交易方式（零售下单、批发询价、拼团预售）。我建议两个都做，前端多一个小程序端加一个管理后台，后端多设计几种订单类型，项目的丰富度和答辩素材立刻上来了。
- 产销对接：这是业务层面的要求，系统里必须有供给端（农户发布商品）和需求端（采购商/消费者购买）的匹配逻辑，最好再加一个按产地、品类、上市时间筛选的功能，让对接更高效。
1.3 这个选题适合什么水平的人做
如果你是Java基础一般、SpringBoot还没完全吃透的应届生，这个题选得非常合适。它不要求你懂高并发、分布式这些复杂技术，但又能让你把JavaWeb的核心环节全部走一遍：RESTful接口设计、MyBatis操作数据库、JWT登录鉴权、微信小程序API对接、订单状态管理、文件上传、数据统计。做完这一套，你简历上"独立完成一个多角色交易系统"的说法是站得住脚的。
如果你基础偏强，这个题也留了足够的拔高空间：你可以在订单模块引入Redis缓存热点商品、用RabbitMQ处理订单超时关闭、给商品搜索加上Elasticsearch，甚至把采购商的批量询价改造成一个简单的竞拍流程。所以这道题的下限很低，上限也很高，关键看你想做到什么程度。
2. 技术选型与项目骨架：为什么我推荐这套组合
确定好业务范围之后，下一步就是选技术栈。在这个阶段容易犯的错误是盲目追新，比如非要用SpringCloud微服务、用Docker做部署，结果自己根本调试不通，答辩时反而露怯。毕业设计的第一原则是：你能完整讲清楚每一项技术为什么这么用，比它本身够不够新更重要。
2.1 后端：Spring Boot 2.7 + MyBatis Plus + MySQL 5.7
我推荐Spring Boot 2.7.x而不是3.x，原因很实际：3.x要求JDK 17以上，很多学校的实验环境和教材还停留在JDK 8，你本地写得欢快，拿到学校机器上一跑全是版本报错，纯属给自己找麻烦。Spring Boot 2.7配合JDK 8，兼容性最好，各种教程资料也最全。
持久层用MyBatis Plus，它比原生MyBatis省去大量XML配置，单表操作直接继承BaseMapper就完成了，多表查询写注解SQL即可。对于毕业设计这个体量，不需要上JPA那套复杂映射。
数据库用MySQL 5.7，注意字符集一定要统一设置成utf8mb4，否则农产品名称里万一有生僻字或者特殊符号，存库直接变成问号。表结构设计放到后面单独说。
这里还要补一个容易踩的坑：Spring Boot版本和你本机JDK版本必须匹配。你如果本机装的是JDK 17，老老实实用Spring Boot 2.7里的依赖版本，千万别一股脑升级。开发中最经典的一个报错就是"Maven编译时提示源发行版17需要目标发行版17"，原因就是IDE里Project Structure设置成了17，但Maven的编译器配置还指向8，两边的字节码版本对不上，统一改掉就好。
2.2 小程序端：原生还是uni-app
小程序端的选择只有两条路：原生开发或者uni-app。我的建议是，如果这个项目只要求小程序一个前端，直接用原生开发，也就是WXML+WXSS+JS这套。因为微信开发者工具的调试体验最直接，社区资料最多，你遇到问题随手一搜就有答案。虽然Vue语法写起来舒服，但uni-app多了一层编译转换，出了问题你还要先判断是框架的问题还是业务代码的问题，排查链路变长了。
如果你打算同时做一个H5端，那uni-app确实能一套代码两处运行，但说实话，以毕业设计的时间预算，我不建议你把精力分散到两个前端上。我更推荐的做法是：小程序端只做买家端（消费者和采购商共用一套，根据角色切换功能），卖家端功能阉割一部分放到小程序里，完整的商家管理走Web管理后台，这样既减少了小程序端的复杂度，又自然实现了"多端融合"的需求。
2.3 数据库设计：一张用户表搞定四类角色
多角色系统最忌讳的做法是给每种角色单独建一张用户表——农户表、采购商表、消费者表、管理员表，这会让登录逻辑变成一团乱麻。正确做法是一张用户表，通过role字段区分身份，再通过关联表保存不同角色的扩展信息。
我实际用的表结构大概这样：
-- 用户主表 CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `openid` VARCHAR(64) UNIQUE COMMENT '微信openid', `phone` VARCHAR(20) COMMENT '手机号', `nickname` VARCHAR(50), `avatar` VARCHAR(255), `role` TINYINT NOT NULL COMMENT '1-农户 2-采购商 3-普通用户 4-管理员', `status` TINYINT DEFAULT 1 COMMENT '1-正常 0-禁用', `create_time` DATETIME, `update_time` DATETIME ); -- 农户扩展信息表 CREATE TABLE `farmer_profile` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT UNIQUE, `farm_name` VARCHAR(100), `intro` TEXT, `province` VARCHAR(50), `city` VARCHAR(50), `district` VARCHAR(50), `address_detail` VARCHAR(200), `id_card` VARCHAR(30), `verify_status` TINYINT DEFAULT 0 COMMENT '0-待审核 1-已通过 2-已驳回' );商品表、订单表、购物车表、收货地址表、支付流水表这些和普通商城类似，但商品表需要额外加几个农产品的专属字段：produce_place（产地）、harvest_date（上市时间）、unit（计价单位，斤/箱/件）、is_fresh（是否生鲜）、storage_method（存储方式）。这既是业务需要，也是答辩时体现你理解农产品特性的关键细节。
2.4 项目目录结构
我推荐用Maven多模块或者单模块分层都行，毕业设计不强制，但分包思路要清晰：
com.example.agri ├── controller // 接口层 ├── service // 业务逻辑层 │ └── impl ├── mapper // MyBatis数据访问层 ├── entity // 数据库实体 ├── dto // 接收前端参数的对象 ├── vo // 返回给前端展示的对象 ├── config // 配置类，如微信配置、拦截器配置 ├── common // 通用工具类、统一返回结果、异常处理 ├── utils // JWT工具、时间处理 └── AgroApplication.java强烈建议在common里封装一个统一的Result返回体，包含code、message、data三个字段，所有接口统一返回这个格式，前端处理起来才清爽。这一步虽然简单，但能避免后期疯狂返工。
3. 核心模块实现拆解：登录、商品、订单、支付必须一次做对
项目能不能立起来，关键看这几个核心模块能不能闭环跑通。下面我挑四个最容易出问题、也最能体现项目质量的模块详细讲。
3.1 微信登录与多角色鉴权：拦截器+JWT的整体设计
小程序端登录的完整流程不是每次打开小程序都让用户授权，而是静默登录：小程序调wx.login拿到一个临时code，发给后端，后端拿着code去微信接口换openid，再用openid去用户表查是否存在该用户，存在就直接返回登录态，不存在就自动注册一个普通用户并返回登录态。
这里要特别提醒一个常见报错：很多人在控制台看到"获取登录后的微信用户失败:err_code"，其实是混淆了wx.login和wx.getUserProfile两种能力。wx.login拿到的code是用来换openid的，永远不需要用户授权；而wx.getUserProfile是用来拿头像昵称的，必须在用户点击按钮后触发，不能在小程序启动时自动调用。微信官方2022年之后对头像昵称填写能力做了改动，现在推荐的做法是让用户在小程序里手动填写昵称、用button组件的open-type="chooseAvatar"获取头像。
换到openid之后，后端要做两件事：
第一，生成自定义登录态。我用的方案是JWT，把userId和role封装进token里，设置7天过期，小程序端每次请求时放在请求头的Authorization字段里。
// 登录接口核心逻辑 @PostMapping("/login") public Result<String> login(@RequestBody LoginRequest request) { // 1. 用code换openid WxLoginResponse wx = wxService.code2Session(request.getCode()); // 2. 查用户 User user = userMapper.selectOne(new LambdaQueryWrapper<User>() .eq(User::getOpenid, wx.getOpenid())); if (user == null) { // 3. 自动注册默认普通用户 user = new User(); user.setOpenid(wx.getOpenid()); user.setRole(3); userMapper.insert(user); } // 4. 生成JWT String token = JwtUtil.createToken(user.getId(), user.getRole()); return Result.success(token); }第二，写一个拦截器统一做登录校验和角色鉴权。这里给拦截器配置两个核心方法：preHandle里解析token并放入ThreadLocal，然后通过自定义注解@RequireRole来判断接口允许哪些角色访问。
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.isEmpty(token)) { throw new BizException(401, "未登录"); } // 校验token Claims claims = JwtUtil.parseToken(token); if (claims == null) { throw new BizException(401, "登录已过期"); } Long userId = claims.get("userId", Long.class); Integer role = claims.get("role", Integer.class); UserContext.set(userId, role); // 校验角色权限 RequireRole requireRole = ((HandlerMethod) handler).getMethodAnnotation(RequireRole.class); if (requireRole != null && !Arrays.asList(requireRole.value()).contains(role)) { throw new BizException(403, "无权限操作"); } return true; }这里有一个关键设计：JWT里只放userId和role，不要放更多敏感信息。后续如果需要用户昵称头像，直接根据userId查库，保证数据一致性。因为用户改了头像昵称之后，如果JWT里还是旧数据，前端就会一直读到过时的信息。
3.2 农产品上架与商品多状态管理
农户登录后要能发布商品，这里和普通商城不太一样的地方在于：农产品上架之后不是直接就能被所有人看到，而是需要管理员审核。因为农产品是入口的东西，平台必须有审核机制，避免出现安全问题。
所以我给商品表设计了四个状态：0-草稿、1-待审核、2-上架中、3-已下架。农户提交商品后状态为待审核，管理员在Web后台审核通过后变为上架中。这样设计的另一个好处是：答辩时你可以理直气壮地说自己考虑了平台内容安全，而不是只做了简单的CRUD。
商品发布页面还有一个细节：多规格的处理。农产品经常遇到"5斤装""10斤装""箱装"这种不同规格，如果每加一个规格就新建一个商品，商品列表会非常臃肿。我在项目里采用的是商品表+规格表的方案：商品表存基础信息，规格表存价格、库存、起售数量。
public class Product { private Long id; private Long farmerId; private String name; private String category; private String cover; private List<String> images; private String producePlace; private LocalDate harvestDate; private String description; private Integer status; }查询商品列表时，按状态为上架中过滤，再联查规格表拿到最低价作为展示价格。列表展示"¥12.90起"这种信息，就是一个join语句的事，但能极大提升商城的真实感。
3.3 订单流程设计：状态机是核心
订单模块是几乎所有交易系统的复杂点。农产品平台的复杂在于：散户购买走普通零售流程，采购商购买走批发审核流程。为了不把系统的复杂度拉爆，我在实现时采用了一种订单表+订单类型字段的方案，而不是建两张订单表。
订单状态我定义了完整的状态机，用一个枚举来约束：
public enum OrderStatus { PENDING_PAYMENT(0, "待付款"), PENDING_REVIEW(1, "待卖家确认"), PENDING_DELIVERY(2, "待发货"), SHIPPED(3, "运输中"), COMPLETED(4, "已完成"), CANCELLED(5, "已取消"), REFUNDING(6, "退款中"), REFUNDED(7, "已退款"); }零售订单路径是：待付款→待卖家确认→待发货→运输中→已完成。批发订单在待付款之后多了一个"待卖家确认"的逻辑，农户可以接受或拒绝采购商的订单，这个步骤就是"自主交易"的体现。
这里有一个容易忽略的细节：订单取消时一定要做库存回滚。很多新手只把订单状态改成已取消，忘了把商品规格表的库存加回来，结果卖了几单之后库存变成负数，非常尴尬。我的做法是在取消订单的方法里开启@Transactional，同时更新订单状态和商品库存，保证两个操作要么都成功，要么都失败。
另外一个难点是订单超时自动关闭。最简单可靠的方式是在用户创建订单时在订单表记录expire_time为当前时间加30分钟，然后在订单查询时判断是否超时，如果超时则调用取消逻辑。用定时任务扫表也可以，但毕业设计阶段不建议引入消息队列，轮询虽然不优雅，但实现简单、逻辑清晰、不容易出错。
3.4 微信支付对接：跳过证书也能走通的方案
微信支付是很多毕业设计的拦路虎，因为商户号申请需要营业执照，学生很难搞定。这里有两个思路：
思路一：用真实的微信支付沙箱环境或商户号（如果你能借到的话）。对接流程是：后端调用微信支付统一下单接口，拿到预支付交易会话标识prepay_id，生成支付参数返回给小程序，小程序端调用wx.requestPayment拉起支付面板。支付完成后微信服务器会异步回调你配置的支付通知地址，后端在回调里验签、修改订单状态。
// 统一下单核心逻辑（简化版） Map<String, String> params = new HashMap<>(); params.put("appid", wxConfig.getAppid()); params.put("mch_id", wxConfig.getMchId()); params.put("out_trade_no", order.getOrderNo()); params.put("total_fee", String.valueOf(order.getTotalFee())); // 单位是分 params.put("body", order.getProductName()); params.put("notify_url", wxConfig.getNotifyUrl()); params.put("trade_type", "JSAPI"); params.put("openid", order.getOpenid()); // 使用微信支付v3的SDK进行签名并请求接口接到支付回调后，一定要做的事是先校验签名，再判断订单金额是否一致，最后更新订单状态为待卖家确认。很多生产事故都是因为回调接口没有验签，导致别人伪造一个支付成功的请求直接改订单状态，这是非常严重的逻辑漏洞。
思路二：如果实在没有商户号，我建议把"支付"做成模拟支付——前端弹出一个模拟支付弹窗，点"确认支付"后直接回调后端将订单标记为已支付。这样做不丢分，答辩时可以如实说"为了演示方便，本项目采用模拟支付方式，真实接入微信支付时仅需替换支付网关配置"。只要把模拟支付的接口边界设计好，把PayService做成接口、未来可以替换成真实实现，这反而能体现你的架构意识。
3.5 管理后台的统计模块：一组SQL搞定答辩亮点
多角色系统不能少了管理员视角的统计功能。农产品平台最值得展示的三组数据是：各品类销量排行、近30天交易总额趋势、用户注册增长趋势。这三组数据用三条SQL就能查出来，但呈现在ECharts图表里，视觉冲击力和答辩说服力是完全不同的。
-- 各品类销量排行 SELECT p.category, SUM(oi.quantity) AS total_quantity FROM order_item oi LEFT JOIN product p ON oi.product_id = p.id WHERE oi.create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY p.category ORDER BY total_quantity DESC;统计模块在Web管理后台实现，建议用Vue2 + ElementUI写一个简单的单页应用，或者直接用Thymeleaf模板渲染也可以。关键在于：这些数据要证明平台确实产生了交易、确实有用户在用，而不是把页面做完就没了。
4. 实战踩坑记录：这几个问题几乎人人会遇到
做这套系统的过程中，微信小程序端的坑比Java后端的坑多得多。我把最典型的几个记录下来，你提前绕开能省不少时间。
4.1 小程序获取用户信息的接口变动
2022年10月之后，微信官方对头像昵称获取做了调整，wx.getUserProfile接口返回的昵称变成"微信用户"，头像变成灰色默认头像，这是微信为了隐私保护做的调整，不是你的代码写错了。正确做法是：
- 头像：在页面上放置
button组件，设置open-type="chooseAvatar"，用户点击后触发bindchooseavatar事件，拿到临时头像路径后上传到自己服务器。 - 昵称：使用
input组件，设置type="nickname"，用户输入时键盘上方会弹出微信昵称快捷填入按钮。
这块虽然改动简单，但如果你还在用老教程里的wx.getUserProfile，真机测试时永远拿不到正确的头像昵称，会浪费不少排查时间。
4.2 图片上传：本地路径和临时路径必须分清
微信小程序里通过wx.chooseMedia选完图片，拿到的只是本地临时路径，比如http://tmp/xxx.jpg。这个路径只有当前小程序运行期间有效，下次启动就失效了，而且后端也无法直接访问。所以正确的做法是：前端拿到临时路径后，立刻通过wx.uploadFile上传到自己服务器，后端存到一个文件目录下，返回https://你的域名/xxx.jpg这种可访问的URL，然后前端用这个URL展示。
后端接收上传时要注意配置静态资源映射，让上传的图片能通过URL直接访问：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadDir + "/"); }注意服务器的上传目录不要放在src/main/resources下，否则打包成jar之后图片会随着重新部署被清除。应该放到服务器的一个固定路径，比如/data/agri/upload。
4.3 真机调试网络请求失败net::ERR_CONNECTION_RESET
这个问题在预览真机调试时非常常见。你在开发者工具里一切正常，一上真机就报net::ERR_CONNECTION_RESET，大概率原因只有一个：你请求的接口地址是http://localhost:8080或者http://127.0.0.1:8080。手机访问的localhost是手机自己，不是你电脑。把地址改成你电脑的局域网IP，比如http://192.168.1.100:8080，手机和电脑连同一个WiFi就能访问。
如果你用的是云服务器，那记得在云控制台的安全组放行8080端口，否则从外面访问也会超时。另一个细节是，微信小程序正式环境要求https协议且域名必须是备案过的，但开发阶段可以在微信开发者工具的"详情-本地设置"里勾选"不校验合法域名"，这样http://局域网IP也能访问。
4.4 小程序分包：优化首屏加载时间
如果你的项目商品图片多、页面多，小程序包体积很容易超过2MB主包限制。这时候用分包就能解决问题：把农户管理、采购商中心这些低频页面放到子包，主包只保留首页、分类、购物车、我的四个Tab页面。
app.json里简单配置一下：
{ "pages": [ "pages/index/index", "pages/category/category", "pages/cart/cart", "pages/user/user" ], "subPackages": [ { "root": "pagesFarmer", "pages": [ "productManage/productManage", "orderManage/orderManage", "publishProduct/publishProduct" ] } ] }分包配置本身很简单，但它对体验的提升非常明显。答辩时你可以说"我通过分包策略将主包体积控制在1.8MB以内，首屏加载时间减少了40%"，这句话的含金量比"我用中文写注释"高得多。
4.5 定时任务库存回滚的边界情况
如果要实现"提交订单后锁定库存、超时未支付自动释放库存"，用@Scheduled定时任务扫表是可以的。但注意两个细节：
第一，定时任务执行频率不要太快，比如每30秒扫一次，如果订单量大，频繁全表扫描可能拖垮数据库。可以用一个字段last_check_time来增量查询。
第二，超时取消订单时要判断订单当前状态，只有"待付款"的订单才能取消，否则已发货的订单被你扫到后自动取消了，卖家那边还蒙在鼓里。
@Scheduled(fixedDelay = 30000) public void closeExpiredOrders() { List<Order> expiredOrders = orderMapper.selectExpiredUnpaidOrders(LocalDateTime.now().minusMinutes(30)); for (Order order : expiredOrders) { // 仅待付款状态可取消，防止重复返回 int rows = orderMapper.cancelIfStatusIs(order.getId(), OrderStatus.PENDING_PAYMENT.getCode()); if (rows > 0) { // 回滚库存 productSpecMapper.increaseStock(order.getSpecId(), order.getQuantity()); } } }5. 从"能跑"到"答辩高分"：代码质量与演示设计的细节
系统做完，代码能跑，只能说完成了70%。剩下的30%决定你是拿及格分还是拿优秀分，全看你怎么包装。
5.1 代码规范的几个加分项
导师看代码不会一行行读，但打开项目扫一眼结构就能判断出你的功底。至少要做到这三点：
- 接口统一返回Result对象，不要有的接口返回Map、有的返回JSONObject、有的直接返回实体，混乱的返回格式会让前端同学或你自己后续调试时非常痛苦。
- 异常不要全部抛到页面。在
common里写一个@RestControllerAdvice全局异常处理器，把业务异常BizException统一转成Result，数据库异常记录日志后返回友好提示。这样可以避免小程序端一请求就弹出"Whitelabel Error Page"这种原始错误页。 - 敏感信息不能出现在返回对象里。比如用户表的openid是敏感数据，不能直接在查询用户信息接口里把整个实体返回回去，应该用UserVO，只返回id、昵称、头像、角色这些前端需要的字段。这一点在答辩时会被问到，而且回答好了非常加分。
5.2 演示环境的准备三部曲
毕业设计答辩最怕现场翻车。我经历过太多次"昨天还好好的，今天一打开数据库连接不上"的惨剧。给你三个建议：
第一，答辩前的演示环境确保是同一台电脑、同一个网络，不要临时换机器或者换WiFi。如果条件允许，提前录一份完整演示视频作为后备方案，万一现场网络出问题，放视频也能撑住场面。
第二，数据库里预置好演示数据。别再展示空列表，提前录入5个农户、20个商品、10笔不同状态的订单，甚至模拟几条带评价的订单。演示时直接点开用户端看到丰富的列表，比临时创建数据流畅一百倍。
第三，演示动线按"登录→浏览→下单→支付→卖家处理→管理员审核"这个流程走一遍，把每个模块串成一条完整的故事线，而不是想到哪点哪。答辩老师问"你这个订单是怎么流转的"，你就能顺着刚才演示的路径完整讲一遍。
5.3 答辩常见提问和应对思路
这块专门说一下，因为很多人做得出来但讲不出来。针对这个题目，老师大概率会问这么几类问题：
- 为什么农产品要有审核机制？回答思路：农产品直接关系到食品安全，平台必须对卖家资质和商品信息进行审核，避免违规商品出现在平台上，降低平台法律风险。
- 订单状态为什么要用状态机？回答思路：状态机可以让订单流转逻辑清晰可控，避免出现"已取消的订单还能发货"之类的非法状态，同时也方便后续扩展退款、售后等流程。
- 多角色登录是怎么实现权限隔离的？回答思路：登录后服务端签发包含角色信息的JWT，前端根据角色渲染不同菜单，后端在拦截器里通过
@RequireRole注解控制接口访问权限，核心是前后端双重校验，防止越权调用。 - 如果用户量变大，系统哪里会是瓶颈？回答思路：早期瓶颈在数据库，可以引入Redis缓存热点商品列表和用户信息；其次是小程序端首屏加载，可以用分包和CDN加速图片访问。能把这个逻辑讲清楚，就已经超越了绝大多数毕业设计了。
6. 如果重新做一次，我会在哪些地方做得不一样
写完这套系统之后复盘，我觉得有三处可以迭代的空间，写出来供你参考，也算是给这篇文章收个尾。
第一，"多途径"的第二个维度值得做得更重。我当时的"多种交易方式"只做了零售和批发，如果能再加入"预售"模式——农户在播种/养殖阶段就挂出预售商品，消费者先下单付定金，收成后再发货——那么农产品的产销对接属性会更有说服力，技术上也只需要在商品表加个product_type字段，订单状态机加一个"待成团"的状态。
第二，位置信息可以和小程序的地理定位能力结合。农产品平台很适合做"附近农户""产地直供"这类基于LBS的功能，小程序端用wx.getLocation拿到经纬度，后端按距离排序返回最近的农户或者最近的农产品，这在答辩现场展示时效果非常惊艳。
第三，代码里可以留一个"模拟数据生成器"。当时演示时我手动造了20多条订单记录，花了不少时间。如果写一个DataInitializer，每次启动时自动生成一批农户、商品、订单的种子数据，既能保证演示数据永远完整，也能在验收文档里写一句"系统内置演示数据初始化工具，便于功能演示与测试"，这属于投入产出比极高的加分项。
做毕业设计的过程确实熬人，但回过头看，这个题目逼着你把微信小程序、Java后端、数据库设计、接口联调、部署上线全部走了一遍，几乎是Java后端岗位日常工作的微缩版。你只要按这篇的思路踏踏实实做下来，答辩时心里是有底的。如果中途遇到具体报错，先试着自己搜错误信息定位一遍，实在搞不定再针对性查资料，这本身就是程序员最核心的能力。祝顺利。
