企业官网建设流程全解析

1. 项目概览与选题价值

1.1 农产品交易平台到底是做什么的

农产品交易平台这类选题，这几年在计算机毕业设计里出现的频率相当高。它本质上就是一个垂直电商系统，业务主体是农产品，服务对象是买家、卖家、平台管理员这三类角色。买家在平台上浏览农产品、加购物车、下单付款，卖家负责发布商品、管理库存、处理订单，管理员在后台审核商品、管理用户、维护平台秩序。

整个系统覆盖的是一条完整的交易链路：商品发布 -> 平台审核 -> 上架展示 -> 用户下单 -> 支付模拟 -> 卖家发货 -> 买家确认收货。听起来和常见的电商系统很像，但因为业务对象变成了蔬菜、水果、粮油这类农产品，所以又比普通商品多了一些特殊性，比如需要展示产地信息、需要区分规格（一箱/一斤/一提）、需要对生鲜类商品做单独的上下架控制。

我见过不少学生选这个题目，最初的想法就是"电商项目好抄、网上模板多"。但真正做下来你会发现，一个能跑通、能演示、能扛住答辩老师追问的交易平台，远不是几个增删改查页面那么简单的。订单状态如何流转、商品审核通过前能不能被搜索到、买家取消订单后库存怎么恢复，这些问题才是区分及格和优秀的分界线。

1.2 为什么这类课题适合当毕业设计

选毕业设计题目，最怕的不是难，而是"不好讲"。农产品交易平台刚好踩中了一个很舒服的点：业务场景贴近生活，技术栈成熟稳定，功能模块边界清楚，展示效果又足够直观。

先说场景。农产品交易不需要你懂冷链物流、期货合约这些复杂概念，买菜卖粮是每个人从小就见过的场景，你解释需求的时候，导师不用费力去理解业务，你也不用花一半时间在科普上。这意味着你的精力可以集中在技术实现上，而不是业务模型上。

再说技术。这个项目用的是SpringBoot + Vue + MySQL这套组合，SpringBoot负责后端接口和业务逻辑，Vue负责前端页面交互，MySQL存业务数据。这套技术栈是所有Java方向学生的基本功，网上资料密度极高，遇到问题基本都能搜到解决方案，不会出现"卡住三天没人能帮"的绝境。

最关键的还是展示效果。答辩的时候打开页面，商品列表、购物车数字、订单状态的实时切换，一眼就能看出系统是活的。比起那种纯算法题或者论文型课题，这种"看得到、点得动、有反馈"的系统，在评分时天然占优势。我后来和不少带毕设的导师聊过，他们的普遍态度是：框架可以不新，但逻辑必须完整，功能必须闭环。

所以如果你正在纠结选题，农产品交易平台是一个性价比很高的选择。它不会让你做出什么惊艳业界的东西，但它能让你完整体验一个软件产品从零到一的过程，而这恰恰是毕业设计最想考察的东西。

2. 技术选型与总体架构

2.1 为什么偏偏是SpringBoot + MyBatis-Plus的组合

很多人一开始纠结框架选型：SpringBoot还是SpringCloud，MyBatis还是JPA，要不要上Redis，要不要加RabbitMQ。我的建议很直接：毕业设计不是公司生产项目，你的目标是用最少的时间做出最稳的系统，同时能在答辩时把每一个技术点讲清楚。

SpringBoot现在已经是Java后端开发的默认起点，它的核心价值是"自动配置"和"开箱即用"。你不需要像传统SSH那样写一大堆XML配置，只需要在pom.xml里引入依赖，再写一个application.yml，框架就能自己把数据源、Web容器、Bean管理这些东西搞定。这让你能把注意力放在业务代码上，而不是耗在环境配置里。

MyBatis-Plus是在MyBatis基础上的增强工具，它把单表的增删改查封装成了现成方法，比如selectById、insert、updateById，写代码的时候基本不用手写SQL。可能有人觉得"这不就是把SQL藏起来了吗，是不是偷懒"，其实不是。MyBatis-Plus解决的是80%的常规数据库操作，剩下20%的复杂查询、多表联查、统计报表，你还是可以手写SQL，用@Select注解或者XML文件来搞。灵活性和效率两头都占了。

这套组合还有一个实际好处：学习资料多到你根本看不完。无论是CSDN还是掘金，SpringBoot + MyBatis-Plus的教程都是海量的，踩坑案例也是现成的。对毕业设计来说，"遇到的问题能在网上找到答案"本身就是一项巨大的隐性优势。

2.2 前端、数据库和权限方案怎么配套

前端部分，我见过做得比较多的方案是Vue + Element UI。Vue负责页面的数据绑定和组件化开发，Element UI提供现成的表格、表单、弹窗、标签页组件，写出来的页面虽然谈不上惊艳，但胜在整齐、规范，演示的时候不丢面子。如果你对自己的前端能力没底，也可以直接用Thymeleaf服务端渲染，把HTML模板放在后端工程里统一管理，少一层前后端分离的联调成本，但页面交互会弱一些。

数据库这一层，MySQL依然是绝对的主流。设计表的数量不需要贪多，核心的表控制在7到9张就足够覆盖业务闭环了：用户表、商品表、订单表、订单明细表、购物车表、收货地址表、商品分类表，再加一张公告或轮播图表。表多了反而增加联查复杂度和答辩被追问的风险。

用户权限这块，我建议用JWT（JSON Web Token）来实现登录态和角色识别。流程也不复杂：用户登录成功后，后端签发一个包含用户ID和角色信息的token返回给前端，前端存下来，之后每次请求都放到请求头里带上，后端用一个拦截器校验token的有效性，再从中取出角色去做接口级别的权限控制。整个过程不依赖Session，前后端分离天然友好，而且答辩时讲起来也很有说头。

2.3 项目目录结构背后的分层思路

源码08055这个项目采用了经典的三层架构，目录划分基本是controller、service、mapper这三层。Controller层只负责接收请求、参数校验、返回结果，不写任何业务逻辑；Service层是核心，承载订单流转、库存扣减、商品审核这些业务规则；Mapper层对数据库做最基础的CRUD操作。

有人觉得分层麻烦，"明明一个方法能搞定的事，为什么要拆成三层"，但拆完之后你会发现，每一层都有自己的职责边界，出bug的时候定位极快。比如某个下单接口报错了，先看Controller参数有没有接收到，再看Service里状态判断有没有走对，最后看Mapper的SQL是不是写错了字段名，排查路径非常清晰。

另外我建议在这个工程里单独建一个common包或config包，用来放统一的返回结果类（比如Result对象，包含code、message、data三个字段）、统一的异常处理器、JWT拦截器和跨域配置。这些小工具类会在你写每一个接口的时候反复用到，提前搭好能省掉大量重复代码。

3. 核心业务与数据库设计

3.1 三类角色与权限边界怎么划

农产品交易平台的用户角色，最合理的划分是三种：买家、卖家、管理员。但这里有个很多学生容易忽略的点——一个人能不能既是买家又是卖家？答案是应该允许。一个用户可以注册为买家下单买东西，也可以申请成为卖家开店卖货，所以用户表里最好用一个用户类型字段（比如userType），取值是0、1、2，分别代表管理员、买家、卖家。如果一个普通买家后续想卖东西，可以走一个"申请成为卖家"的流程，管理员在后台审核通过后把它的用户类型改成2就行。

角色划分清楚之后，接口的权限控制就有的放矢了：

• 管理员：只能操作后台管理接口，比如商品审核、用户管理、数据统计，不能去前台下单。
• 买家：只能浏览商品、管理购物车、下单、查看自己的订单，不能去后台。
• 卖家：只能管理自己的商品和订单，不能看到别的卖家的数据。这里有个很关键的细节——卖家查询订单列表的时候，SQL里必须带上卖家ID作为条件，否则就会出现"卖家A看到了卖家B的订单"这种重大逻辑漏洞。

权限控制的技术实现上，最直接的办法是写一个自定义拦截器，在拦截器里解析JWT拿到当前用户的角色和ID，再判断当前请求的接口是否符合该角色的权限范围。接口层面可以用路径前缀做粗粒度区分，比如/admin/**只允许管理员访问，/seller/**只允许卖家访问，/buyer/**只允许买家访问，再用方法级的注解做细粒度校验。

3.2 核心业务流程拆解

这个系统的核心业务流，从上架到完结，一共要经历八个关键步骤。

第一步，卖家发布商品。填写商品名称、图片、价格、库存、产地、分类、描述等信息，提交后商品默认进入"待审核"状态，此时前台页面是搜不到这个商品的。这个设计很重要，它体现了平台的管理职能，也给你的系统增加了一个合理的功能模块。

第二步，管理员审核商品。管理员在后台看到一个待审核商品列表，点开详情确认信息合规后点击通过，商品状态变成"已上架"，前台立即可见。审核不通过的商品可以填写驳回理由，退回给卖家修改。这里我建议把审核状态和上架状态分成两个字段或一种状态机的多个枚举值来管理，避免后面改状态的时候逻辑混乱。

第三步，买家浏览商品、加入购物车。这一步比较常规，注意购物车表要冗余一份商品名称和价格快照，因为商品价格是会变的，购物车里的历史价格不应该跟着商品表直接变动，否则下单时会出纠纷。

第四步，买家提交订单。从购物车勾选或直接从商品详情页进入结算页，选择收货地址，生成订单。订单表里要记录下单时的商品名称、单价、数量、总价，也就是用快照数据，而不是下单之后再去关联查询商品表的实时价格。

第五步，买家支付。毕业设计系统基本不需要接真实的支付接口，一般做成一个"模拟支付"按钮，点击后订单状态从"待付款"变为"待发货"。如果你想让答辩更出彩，可以在支付环节加一个简易的订单超时未支付自动取消逻辑，用定时任务或延时校验的方式实现。

第六步，卖家发货。卖家在"我的订单"里看到待发货的订单，点击发货后填写物流单号（可以是模拟的），订单状态变为"待收货"。

第七步，买家确认收货。收到货物后买家点击确认收货，订单状态变为"已完成"，这笔交易闭环正式结束。

第八步，售后逻辑（可选）。订单完成后买家可以申请退货退款，卖家审核后系统原路退回金额。这个模块不是必须的，但加上去会让系统完整度明显上一个台阶。

3.3 关键数据表设计

数据库表设计是整个项目的基石，表结构一旦定下来，后面所有代码都要围绕它写。我直接说一下当时设计的核心表结构思路。

用户表（user）：id主键，username唯一，password存加密后的密文，phone，avatar，user_type区分角色，create_time注册时间。密码加密务必不要用明文存储，Spring Security里自带的BCryptPasswordEncoder，或者简单点的MD5加盐都行，答辩时这是考试点。

商品表（product）：id，seller_id（关联用户表），category_id（关联分类表），name，description，price，stock，origin产地，main_image主图，status（0待审核、1已上架、2已下架、3已驳回），create_time，update_time。

订单表（orders）：id，order_no（业务订单号，用时间戳加随机数生成），buyer_id，seller_id，total_amount，status（0待付款、1待发货、2待收货、3已完成、4已取消），receiver_name，receiver_phone，receiver_address，create_time，pay_time，ship_time，finish_time。

订单明细表（order_item）：id，order_id，product_id，product_name（快照），product_image（快照），price（快照），quantity，subtotal。

购物车表（cart）：id，buyer_id，product_id，quantity，create_time。

收货地址表（address）：id，user_id，receiver_name，receiver_phone，province，city，district，detail_address，is_default默认地址标记。

商品分类表（category）：id，name，sort。

公告表（notice，可选）：id，title，content，create_time，status。

这里要特别强调两件事。第一，订单表和订单明细表为什么要分开？因为一个订单可能包含多种商品，如果把商品直接塞到订单表里，同一个订单就会产生多条记录，没法表达"一笔订单"这个整体概念。拆成主表和明细表，就是经典的"订单头 + 订单行"模型。第二，订单明细里的product_name、price这些字段为什么要做冗余快照？因为商品可能会被删除、价格可能会调整，如果订单生成之后还去关联商品表取值，历史订单的数据就不可信了。做冗余的目的是保证订单历史数据的完整性，答辩老师问到这个你能答出来，印象分会加分。

4. 实操过程：从零搭建到核心模块落地

4.1 环境准备与项目初始化

我自己在实际搭建源码08055这个工程的时候，第一步是准备基础环境：JDK 1.8或11都可以，SpringBoot 2.3.x或2.5.x的稳定版本，Maven 3.6+，MySQL 5.7以上，前端工具用Node.js的npm装Vue CLI。这里有一个建议，SpringBoot版本别追最新，够用稳定就行，因为毕业设计用的第三方依赖未必适配了最新版，版本冲突会浪费大量时间。

创建一个SpringBoot项目最快的方式，是去Spring Initializr官网勾选需要的依赖生成一个基础压缩包，或者直接在IDE里新建项目。必选的依赖就三个：Spring Web、MyBatis-Plus（需要自己手动引入坐标）、MySQL Driver。其他像Lombok这种可以选上，能减少getter/setter的样板代码，但要注意让队友和导师环境也装上对应插件。

初始化完成之后，记得在application.yml里把数据源、端口、日志配置写好。下面的配置是我的常用模板：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/farm_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto

url里面那个serverTimezone=Asia/Shanghai是必加的参数，不然后端连接MySQL时会报时区错误。jackson的date-format配置解决前端拿到的日期格式是一串数字时间戳的问题，这是一个出现频率极高的坑。

4.2 用户登录与JWT鉴权实现

登录模块是整个系统的第一道门，技术方案是JWT。我拆成四步来写。

第一步，用户注册接口。前端传用户名、密码、手机号，后端先校验用户名是否已存在，然后对密码做加密处理，保存用户信息，默认角色是买家。

第二步，用户登录接口。根据用户名查出用户，用密码匹配器比对加密密码，比对成功则生成JWT返回前端。JWT的payload中我放三类信息：userId、userType、username。生成密钥时我用的是一个自定义的固定字符串，配合过期时间设为24小时。

第三步，JWT拦截器。写一个HandlerInterceptor，实现preHandle方法，从请求头Authorization字段里取出token，解析并验证，把解析出的用户信息放进ThreadLocal或HttpServletRequest的attribute里，方便后续Controller取用。

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); } Claims claims = JwtUtil.parseToken(token); if (claims == null) { response.setStatus(401); return false; } request.setAttribute("userId", claims.get("userId")); request.setAttribute("userType", claims.get("userType")); return true; } }

第四步，配置拦截器并处理放行路径。登录接口、注册接口、商品列表查询接口、商品详情接口这些是允许匿名访问的，需要单独放行，其余涉及下单、购物车、后台管理的接口全部走拦截器校验。注意，拦截器只负责"身份是否有效"，具体某个操作是不是该角色能干的事，还需要在具体的业务代码里再校验。

4.3 商品发布与订单流转的实现要点

商品发布模块的核心是状态机控制。卖家创建商品时status字段设置为0（待审核），此时要做一个"服务层校验"：当前登录用户的userType必须等于2（卖家），否则直接抛业务异常。

管理员审核商品的接口，接收两个参数：商品ID和审核结果（通过/驳回）。通过时把status改为1，驳回应同时保存驳回理由。前台查询商品列表时，SQL里要加硬条件：where status = 1 and stock > 0，确保待审核、已驳回、库存为0的商品不会出现在前台。

订单流转是整个项目中最复杂、最值得花时间梳理的部分。提交订单接口的核心逻辑是：从购物车或请求参数中拿到商品ID和数量，查到商品信息后校验库存是否充足，充足则先扣减库存，然后生成订单主记录和订单明细记录，最后清空对应的购物车记录。扣库存和生成订单必须放在同一个数据库事务里，可以用@Transactional注解标注这个Service方法，只要任何一个操作抛异常，整个事务回滚，库存就不会出现"扣了但没下单"或"下单了但没扣库存"的数据不一致问题。

支付、发货、收货这几个状态变更接口比较简单，本质就是更新订单状态字段，同时记录对应的时间节点。这里要注意的是不要允许状态跳变，比如待付款订单不能直接被改成已完成，必须按照状态机的方向一步步流转。实现办法是前置判断当前状态等于目标状态的前置状态，否则抛异常。

4.4 后台管理模块的快速实现

后台管理模块主要面向管理员，功能集中在三块：商品审核、用户管理、数据概览。

商品审核我在前面已经讲过，实际写的时候就是分页查询status=0的商品列表，加上一个审核操作的入口。用户管理模块是用户列表的分页展示、启用禁用操作，以及把普通用户设为卖家的审核操作。这里多说一句，禁用用户不能物理删除用户记录，用status字段标记0和1就行，因为用户关联了订单、商品等数据，硬删除会造成外键悬空，演示时一旦点了删除可能导致关联数据报错，场面会很狼狈。

数据概览是让后台首页显示几张统计卡片：商品总数、用户总数、今日新增订单数、总销售额。写统计接口的时候可以用MyBatis-Plus的selectCount方法或者@Select注解手写SQL。统计SQL要注意日期范围的处理，比如"今日新增订单数"要用MySQL的DATE_FORMAT函数比对create_time的日期部分。

后台管理的前端页面，用Vue + Element UI写的话就是几个el-table加el-dialog的事。商品审核页放一个"查看详情"按钮，点开弹窗展示商品原始信息，下面是两个按钮：通过、驳回。页面逻辑简单直接，重点是把接口对接正确。

5. 常见问题与排查技巧实录

5.1 跨域、时间格式、数据库连接问题

开发前后端分离项目时，跨域问题排在踩坑榜第一名。前端Vue跑在8081端口，后端SpringBoot跑在8080端口，浏览器会拦住不同源之间的请求。解决办法是在后端写一个CORS配置类，实现WebMvcConfigurer接口，配置allowedOriginPatterns为""，allowedMethods为GET、POST、PUT、DELETE，allowedHeaders为""，同时设置allowCredentials为true。这里有一个小坑，allowCredentials为true时allowedOrigins不可以用"*"，必须用allowedOriginPatterns来代替，否则配置不生效。

时间格式问题也非常典型。SpringBoot默认返回的日期是UTC格式的ISO字符串，而前端期望的是"yyyy-MM-dd HH:mm:ss"。解决办法有两个层面：后端在application.yml中配置jackson的date-format；或者让前端用dayjs或moment在渲染时格式化。强烈建议后端统一处理，一劳永逸。

数据库连接另一个高发问题是时区。MySQL 8.x的驱动对时区很敏感，忘了加serverTimezone=Asia/Shanghai的话，启动就会报"Server returns invalid timezone"或者"Unknown time zone"的错。这个错误信息很吓人，但解决办法就一个——url里加上时区参数。

5.2 逻辑层的高频Bug与修复

业务逻辑层的Bug比较隐蔽，通常不是编译报错，而是运行结果不符合预期。我印象最深的有三个。

第一个是卖家看到别人的订单。查询订单列表时，Service层只接收了分页参数，忘了从当前登录信息里取sellerId作为查询条件。结果一个卖家登录后台，查出来的订单列表包含了所有卖家的订单。修复方法就是在查询条件对象里强制设置当前登录用户的ID，并且后端不能信任前端传过来的sellerId，因为前端传参是完全可以伪造的。

第二个是库存变成负数。两个买家同时下单购买同一件只剩1件库存的商品，如果代码是"先查库存，再更新库存"，两步之间存在时间差，并发场景下就可能把库存扣到负数。解决办法是在更新库存的SQL里加上库存充足的条件判断——update product set stock = stock - #{quantity} where id = #{id} and stock >= #{quantity}，受影响行数为0时说明并发冲突了，抛出库存不足的异常。

第三个是订单金额被篡改。前端把商品单价传过来，后端直接接收并算总价。懂一点网络知识的人都知道，前端传过来的值是可以随便改的，所以后端的下单逻辑必须自己去商品表查价格，不能信任任何前端传来的金额字段。

5.3 答辩前的自检清单

临近演示和答辩的时候，有几个地方一定要提前检查，很多翻车现场都是栽在这些细节上。

• 数据库里的测试数据要足够多、足够真实。商品列表至少15到20条，覆盖多个分类，图片不能是空白占位。买家、卖家账号各准备两个，密码统一设为好输入的值。
• 购物车有数据，订单有不同状态的样例，这样演示的时候不用现场从零开始走流程，可以直接展示"待付款、待发货、待收货、已完成"四种状态。
• 演示顺序要彩排至少两遍：注册登录、逛商品、加购物车、下单支付、卖家发货、买家收货、后台审核商品。中途不要因为代码报错导致页面白屏。
• 特别注意刷新页面之后登录态是否还在。如果JWT存在localStorage里，刷新是不会丢的；如果存在Vuex里而没有做持久化，刷新就变成未登录状态了。

6. 答辩核心考点与扩展方向

6.1 答辩老师最爱问的几个问题

答辩本质上是你和导师之间的技术对谈，导师不关心你的系统好不好看，只关心你到底懂不懂自己在做什么。根据我参与和观察多场答辩的经验，农产品交易平台热门追问点集中在下面几个方向。

第一个问题通常是："你的订单状态是怎么设计流转的？"这是一个开放式问题。你需要能够清晰地画出状态流转路径：待付款 -> 待发货 -> 待收货 -> 已完成，中间可以插入待付款取消、待发货退款等分支。同时能说出每个状态变更接口都做了前置状态校验，防止跳过中间状态直接到达终态。能讲清状态机的设计，这个项目的基本盘就稳了。

第二个问题是："你的登录为什么用JWT？"这个问题考察你对无状态认证的理解。回答要点是：传统Session方案需要服务端保存会话信息，分布式部署时会有Session共享问题，JWT是把用户信息加密后保存在客户端，服务端只负责签名验证，天然适合前后端分离和水平扩展。

第三个问题是："并发抢购场景下怎么防止超卖？"这问题不一定问，但一旦问出来就是拉开差距的关键题。回答方向是：用数据库行锁（乐观锁或条件更新的SQL）保证扣减库存的原子性，在update语句中带上前置条件，不依赖先查询再更新的两条指令。

第四个问题是："核心表之间是怎么关联的？"你要准备好画表关系图，讲清楚订单和订单明细的主从关系，讲清楚为什么订单明细要冗余商品快照。

6.2 进阶优化方向

如果做完基础版本还有余力，我建议在以下方向里挑一个去做扩展。不要做多，做一个做深就很有说头。

支付模块可以做得更完整。虽然不要求真实对接第三方支付，但可以模拟一个支付回调的流程：下单后生成支付单号，模拟支付接口在延迟2到3秒后回调后端，后端收到回调才把订单状态改为待发货。这模仿了真实支付系统的异步通知机制，复杂度不高，但答辩含金量立刻提升。

秒杀活动也是一个加分项。针对某款热门农产品做一个秒杀专场，用Redis做预扣库存。虽然引入Redis会增加学习成本，但效果很直观——启动时把库存加载到Redis，下单时用Redis的原子操作扣减库存，异步同步回MySQL。这一块讲深了，甚至连生产环境的高并发解决方案都能带上。

定时任务也是一个性价比不错的优化点。比如每天零点自动下线活动过期商品，或者定时扫描超过30分钟未支付的订单自动取消并恢复库存。用SpringBoot自带的@Scheduled注解就能实现，代码量不大，但体现了系统的完整性。

6.3 部署与演示环境搭建建议

答辩演示系统的部署，我踩过不少坑，这里直接给结论：尽量不要在答辩现场折腾环境。

最稳妥的方案是本地运行。笔记本上启动后端（IDE里直接启动）、启动前端（npm run serve）、确保MySQL服务已启动且数据已导入。这个方案的问题是笔记本性能一般，建议答辩前把所有环境变量、IDE配置、启动顺序都写成备忘录，彩排时按备忘录一步步执行，确保零失误。

备选方案是部署到云服务器。如果导师要求远程访问，可以把前后端打包部署到一台云主机上，MySQL也部署在同等环境。后端的包用mvn package打jar包，前端用npm run build打出静态文件，让Nginx把静态页面和反向代理到后端接口一起处理。注意云服务器的安全组要放行对应端口，MySQL的jdbc url里的host要改成云主机内网或公网地址。这个方案我实际跑下来非常稳定，缺点是需要懂一点Linux基础命令，物有所值。

这里还分享一个小技巧：演示时准备一份"开机即用手顺"，内容包含四要素——启动顺序、每个服务的启动命令、访问地址、测试账号。别嫌繁琐，答辩当天一紧张，照着文档走能省掉一大半低级事故。

我个人在实际操作中的体会是：毕业设计做得好不好，不在于用了多少花哨的新技术，而在于你对自己的系统能讲得多清楚。农产品交易平台这套题目，麻雀虽小五脏俱全，把订单状态、权限控制、库存一致性这几个核心问题彻底吃透，你就已经在及格线以上了。最后再做一遍全流程测试，把演示路径走顺，别在答辩现场点出尴尬的报错页，这个项目就稳了。