每年到毕业季总有人问我同一个问题Java方向的毕设到底选什么题比较稳我通常都会推荐类似“基于SpringBoot Vue的贫困山区农产品供销服务系统”这种题目。这个题目表面看业务范围很宽实际上拆开就是一套标准的前后端分离“供需撮合电商交易”平台既能覆盖Spring Boot、Vue、MyBatis这些主流技术又能把权限控制、订单流转、数据可视化这些亮点串起来对后面写论文、做答辩、甚至找工作都很有帮助。这个系统能做什么一句话讲清楚把偏远山区的农户、采购商、平台管理员放到同一个系统里农户发布农产品信息采购商或消费者在线浏览、下单管理员负责审核商品、维护数据、看运营统计。它解决的核心痛点是信息不对称——山区的好东西找不到销路外地的采购商找不到稳定货源中间环节多、信息不透明。对做毕设的同学来说它解决的则是“选题怎么定、功能怎么做、论文怎么写、演示怎么录、答辩怎么过”这一整条链路。下面我就按项目主线把整套东西捋一遍从需求拆解、技术选型到数据库设计、核心功能实现再到前后端联调、打包部署最后把论文写作、演示视频和答辩高频问题的经验也一并写完把我实际动手过程中的细节和坑都放进去方便你直接照着做。1. 项目设计与技术选型为什么SpringBootVue是这个题目的最优解1.1 先理清业务供销系统到底在解决什么问题做系统最忌讳一上来就写代码先把业务闭环想明白后面所有功能都顺了。这个项目的核心业务是“帮山区的农产品找到买家”涉及的实际场景有三个农户/合作社手上有货没渠道、没议价能力需要一个可以展示自己产品的窗口。采购商/消费者想买产地直供的农产品但对源头信息不了解需要一个可信、可追踪的信息平台。平台管理员负责审核上架的农产品是否真实、价格是否合理同时通过订单数据和销售统计掌握平台的运营情况。所以系统功能上就要分成三条线农户端的产品管理和订单处理采购端的浏览、下单和支付一般做模拟支付管理端的审核、用户管理和数据看板。这正好对应了三类角色、三套菜单、三组接口也在答辩时形成了一个非常清晰的“三角结构”需求分析讲业务、系统设计讲模块、系统实现讲代码每一层都有东西可讲。1.2 技术选型逻辑从前端到后端到数据库的通盘考虑这个项目的技术栈现在基本已经固定成了“标准答案”我列一下每个选择的理由后端用SpringBoot内置Tomcat省掉大量XML配置开发效率高。更重要的是SpringBoot在毕业设计里几乎成了“默认选项”网上资料多、遇到报错好搜对时间紧的同学非常友好。前端用Vue Element UI或者Element PlusVue上手学习曲线比较缓组件化开发适合做管理后台。配合Element的表单、表格、弹窗组件可以快速拼出完整的管理界面这样的前端界面在演示视频里视觉效果好。持久层用MyBatis或MyBatis Plus直接用SQL控制查询逻辑调优方便MyBatis Plus更是连单表CRUD都帮你封装好了写代码可以集中精力在业务逻辑上。数据库用MySQL免费、稳定、资料多配合Navicat或DataGrip建库导数据都方便。鉴权用JWT无状态、前后端分离友好比Session更适合配套Vue使用。这里我想多说一句为什么不建议继续用JSP Servlet那种老一套因为现在答辩老师对技术栈的“新鲜度”是有预期的。前后端分离本身就是论文里的一个独立亮点可以单独写一节“前后端分离架构的优势”这也是工作量的一部分。如果你时间充裕还可以加Redis缓存热点商品数据但这个不是必须做不好反而增加风险。1.3 模块划分与工作量评估按我的经验这个题目建议把系统拆成几个模块去开发方便掌控进度模块主要功能涉及角色用户模块注册、登录、个人信息、密码修改农户、采购商、管理员商品模块发布商品、商品列表、商品详情、审核上下架农户、管理员、采购商交易模块购物车、订单创建、订单支付、发货、确认收货农户、采购商供销管理模块供应信息、采购信息、供需匹配农户、采购商、管理员数据看板模块销售统计、订单趋势、商品分类占比管理员公告模块平台公告发布与查看管理员、所有用户你拿着这个表去估算时间用户模块和公告模块基本是模板代码商品模块是核心工作量交易模块是最需要细心的地方数据看板模块主要是接口和图表配置。这样拆完你就知道哪些地方可以快、哪些地方必须慢。2. 核心功能模块拆解从商品发布到订单完成的完整链路2.1 用户角色与权限设计权限设计是这个题目里必写、必讲、也必考的点。我自己习惯的做法是在用户表里用一个role字段区分角色登录接口返回用户的角色信息前端根据角色渲染不同的菜单后端接口再用拦截器或Spring Security做校验。功能/角色农户采购商管理员注册登录支持支持不支持注册内置账号商品发布支持不支持不支持商品审核不支持不支持支持下单购买不支持支持支持模拟订单发货支持不支持不支持数据看板查看自己查看自己查看全平台用户管理不支持不支持支持权限这块有个细节很容易忽略即使前端隐藏了菜单后端接口也必须做权限校验。你可以用一个简单的注解也可以用拦截器判断请求路径和角色。我在项目里给每个接口都挂了RequireRole(ADMIN)这类注解或者在Controller层统一用拦截器按路径匹配。这样做不是为了炫技而是答辩时如果老师问“前端限制有什么用别人直接调接口怎么办”你能答得出来这就是区分度。2.2 商品发布与审核机制商品模块是用户看得见摸得着的核心功能。农户端“发布商品”的表单至少需要以下字段商品名称、商品分类、单价、单位斤/箱/件、库存数量、产地、图片、描述。其中图片上传往往是最容易出问题的地方我后面会专门讲。这里我想强调一个很多人忽略的设计点商品一定要有“审核状态”。不要一发布就上架而是先进入“待审核”状态管理员审核通过后才在前台展示。为什么一方面是从平台运营角度需要防止虚假信息另一方面是给系统增加一个完整的状态机论文里的“系统设计”章节就有了丰富内容——待审核、上架、驳回、下架、售罄这些状态可以画一张状态图答辩时能讲的东西立刻多了一倍。商品列表查询还需要支持关键词搜索、分类筛选、价格排序。前台用分页加载数据后端用MyBatis Plus的Page对象或者手写SQL都行。做这块的时候建议把查询条件封装成一个查询对象不要直接在Controller里接收一堆零散参数后面维护起来会舒服很多。2.3 订单交易与库存联动交易模块是整个系统的核心难点也是答辩老师比较喜欢追问的地方。我推荐的流程是采购商把商品加入购物车 → 购物车结算生成订单 → 模拟支付 → 农户发货 → 采购商确认收货 → 订单完成。这里面的关键设计有两个第一个是订单状态流转。我常用tinyint类型存状态码0待付款、1待发货、2待收货、3已完成、4已取消。每个状态之间的流转必须在代码里做校验比如只有“待付款”状态才能调到“已取消”“待发货”才能调到“待收货”不能让用户随便跨状态跳。第二个是库存扣减。我建议在用户提交订单的那一刻就锁定库存而不是等到支付成功才扣。代码上就是把“创建订单”和“扣减库存”放在同一个事务里只要有一个环节失败就全部回滚。这一点非常重要你可以写进论文的“系统实现”里答辩时直接讲“我用Transactional保证数据一致性”老师一听就知道你不是只抄了代码。2.4 数据看板让系统有“智慧”的亮点模块数据看板是这个项目性价比很高的一块因为用ECharts就能实现但视觉冲击力很强演示视频里加分比较多。管理员看板可以放这些图近7天订单量折线图、商品分类销售占比饼图、各产地销量柱状图、待处理事项列表。农户看板则聚焦自己的商品发布量、订单量、累计销售额。后端只需要提供几个统计接口比如按日期分组统计订单数按商品分类统计销量前端用ECharts渲染成图形。写SQL的时候注意用GROUP BY配合DATE_FORMAT处理日期分组按月份统计就DATE_FORMAT(create_time, %Y-%m)按天统计就是%Y-%m-%d。这个模块不算难但能直接提升项目的完整度和演示效果。3. 数据库设计核心表结构与字段规划实战3.1 数据表全景与关联关系数据库表设计决定整个项目的“底子”。我强烈建议先画E-R图再建表把实体、属性、关系都理清楚后面写论文直接截图用。这个项目至少需要这几张核心表表名用途关键外键user用户表无category商品分类表无product商品表farmer_id → user.idcategory_id → category.idcart购物车表user_id → user.idproduct_id → product.idorders订单表buyer_id → user.idseller_id → user.idorder_item订单明细表order_id → orders.idproduct_id → product.idnotice公告表无address收货地址表user_id → user.id关联关系就是典型的“用户-商品-订单”三件套一个农户可以发布多个商品一个商品属于一个分类一个订单属于一个采购商包含多个订单明细一个订单明细对应一个商品。这些关系在论文的系统设计部分用E-R图表示一张图就能讲完整个核心逻辑。3.2 核心表字段设计user、product、orders、order_item我直接把我常用的建表SQL写出来你根据实际情况改字段名即可。用户表CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录账号, password varchar(100) NOT NULL COMMENT 密码加密存储, nickname varchar(50) DEFAULT NULL COMMENT 昵称, role varchar(20) NOT NULL DEFAULT BUYER COMMENT 角色FARMER/BUYER/ADMIN, phone varchar(20) DEFAULT NULL COMMENT 手机号, avatar varchar(255) DEFAULT NULL 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), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;商品表CREATE TABLE product ( id bigint(20) NOT NULL AUTO_INCREMENT, farmer_id bigint(20) NOT NULL COMMENT 农户用户ID, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, name varchar(100) NOT NULL COMMENT 商品名称, price decimal(10,2) NOT NULL COMMENT 单价, stock int(11) NOT NULL DEFAULT 0 COMMENT 库存, unit varchar(20) DEFAULT 斤 COMMENT 单位, origin varchar(100) DEFAULT NULL COMMENT 产地, image varchar(255) DEFAULT NULL COMMENT 商品图片地址, description text COMMENT 商品描述, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0待审核 1已上架 2已驳回 3已下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_farmer_id (farmer_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;订单表和订单明细表CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号业务唯一, buyer_id bigint(20) NOT NULL COMMENT 采购商ID, seller_id bigint(20) NOT NULL COMMENT 农户ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0待付款 1待发货 2待收货 3已完成 4已取消, remark varchar(255) DEFAULT NULL COMMENT 订单备注, pay_time datetime DEFAULT NULL COMMENT 支付时间, ship_time datetime DEFAULT NULL COMMENT 发货时间, finish_time datetime DEFAULT NULL COMMENT 完成时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_buyer_id (buyer_id), KEY idx_seller_id (seller_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表; CREATE TABLE order_item ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) NOT NULL COMMENT 订单ID, product_id bigint(20) NOT NULL COMMENT 商品ID, product_name varchar(100) NOT NULL COMMENT 商品名称快照, product_image varchar(255) DEFAULT NULL COMMENT 商品图片快照, price decimal(10,2) NOT NULL COMMENT 成交单价, quantity int(11) NOT NULL COMMENT 购买数量, amount decimal(10,2) NOT NULL COMMENT 小计金额, PRIMARY KEY (id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;这里有三个设计细节我特别说一下订单表里一定要有order_no唯一业务编号不要直接用自增主键去和用户沟通。生成方式可以是时间戳随机数或者“日期自增序列”论文里可以说“采用业务单号保证可追溯性”。金额字段必须用decimal(10,2)不要用float或double浮点数会产生精度误差这是做电商系统的基本功。order_item里的product_name、product_image、price是“快照字段”。商品名称和价格以后可能会改但订单历史记录必须保留下单那一刻的信息这也是答辩时可以主动讲出来的亮点。3.3 建表SQL与存储引擎规范上面建表SQL我统一用了InnoDB和utf8mb4这俩是必选项。utf8mb4支持完整Unicode字符能存emoji和生僻字InnoDB支持事务和外键约束订单操作跨表时必须依赖事务。另外养成习惯所有表都有create_time和update_time查问题、写论文、做数据统计都用得上这个习惯我建议你从一开始就建立起来。4. 关键功能实现与前后端联调从登录到下单的代码实战4.1 登录鉴权JWT 拦截器 路由守卫登录是整个系统第一个要写的功能也是最容易在答辩时被追问“安全性怎么保证”的地方。我用JWT的实现思路如下用户提交账号密码 → 后端校验通过 → 生成Token返回前端 → 前端把Token存在localStorage → 每次请求在请求头带上Authorization: Bearer token→ 后端拦截器校验Token。后端先生成Tokenpublic class JwtUtils { private static final String SECRET your-secret-key; private static final long EXPIRE 7 * 24 * 60 * 60 * 1000L; public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }再写一个拦截器统一校验除登录、注册之外的接口。前端的配合也很重要axios请求拦截器加Token响应拦截器遇到401状态码就跳回登录页。我在做前端路由守卫时习惯在router.beforeEach里判断目标页面是否需要登录需要但没有Token就直接跳转登录页这样刷新页面也不会丢失登录状态。这一步属于“看起来简单但细节多”的环节。你写完这套之后论文的“系统安全设计”章节就有东西可以写了——Token过期时间、密码加密存储BCrypt、接口权限校验都是安全性的具体体现。4.2 商品图片上传与静态资源映射图片上传是这个项目里比较容易踩坑的地方。最稳妥的方案是把图片保存到服务器本地的一个外部目录然后通过Spring Boot的静态资源映射把该目录暴露成URL访问。我常用的配置如下spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB web: resources: static-locations: file:D:/upload/,classpath:/static/上传代码用MultipartFile接收文件文件名用UUID重新生成防止重名覆盖String originalName file.getOriginalFilename(); String ext originalName.substring(originalName.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; file.transferTo(new File(uploadDir, fileName));这里有个教训分享给你不要直接把图片传到项目的src/main/resources/static下面。毕设项目经常要重新打包而mvn clean package会把resources目录清掉再重新生成你传的图片就全没了。把文件放在项目外的目录再通过静态资源映射访问一条路径就能同时解决“文件被清”“URL访问”两个问题。另外上传接口注意限制文件类型和大小答辩时老师对这块的严谨度有预期。4.3 下单扣库存事务与状态流转的核心代码订单创建是整个系统复杂度最高的地方核心逻辑分四步查商品 → 校验库存 → 扣库存 → 生成订单。这段代码必须加事务我用Transactional实现Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 查询商品判断状态是否上架 Product product productMapper.selectById(dto.getProductId()); if (product null || product.getStatus() ! 1) { throw new BusinessException(商品不可购买); } // 2. 判断库存是否充足 if (product.getStock() dto.getQuantity()) { throw new BusinessException(库存不足); } // 3. 扣减库存乐观锁或直接update int rows productMapper.deductStock(dto.getProductId(), dto.getQuantity()); if (rows 0) { throw new BusinessException(库存扣减失败); } // 4. 生成订单号和订单明细 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setBuyerId(dto.getBuyerId()); order.setSellerId(product.getFarmerId()); order.setTotalAmount(product.getPrice().multiply(new BigDecimal(dto.getQuantity()))); order.setStatus(0); orderMapper.insert(order); // 后续插入order_item省略 return orderVO; }这里我特别说一下扣库存的写法不要先select出来在内存里减再update回去那样并发时会出问题。正确做法是写一条带条件的UPDATE语句UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}受影响行数为0说明库存不够直接抛异常。这个写法在答辩时讲出来非常加分因为它体现了对并发场景的基本认知。订单状态的流转方法按顺序写好用户支付、农户发货、采购商确认收货。每个方法先查订单状态再判断能不能进行下一步操作不符合规则就抛异常。这套逻辑不复杂但要把每个状态的前置条件写清楚。4.4 跨域配置与接口联调避坑前端工程默认跑在8081端口后端跑在8080不同端口就产生了跨域问题。解决方式是在后端加一个全局跨域配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }联调时最常见的问题有三类后端接口地址写错、请求方式不对POST写成了GET、参数名对不上。我的建议是先用Swagger或在线接口文档工具把后端接口全部列出来再对照着写前端请求。如果前端报404先看后端控制台有没有收到请求如果报400十有八九是参数类型或字段名不匹配比如后端用orderNo前端传order_no。排查顺序对了问题解决速度就上去了。5. 毕设四件套论文LW、演示视频、部署与打包全流程5.1 论文框架与图表画法标题里提到的LW我理解就是毕业论文/设计文档。很多同学代码跑通了论文却不知道怎么凑字数。按我的经验这个项目的论文按这个框架写最省力章节写什么工作量参考摘要系统背景、技术栈、核心功能、意义300~500字绪论/背景山区农产品销售现状、系统开发意义、国内外类似平台分析800~1000字需求分析角色分析、功能性需求、非功能性需求、可行性分析1000~1500字系统设计架构图、功能模块图、E-R图、数据库表结构、接口设计1500~2000字系统实现每个模块截图 核心代码 实现说明2000~2500字系统测试功能测试用例表、测试结论500~800字总结展望项目收获、不足、改进方向300~500字论文里图表是“工作量可视化”的关键。你需要准备这几类图系统架构图前端Vue → 后端Controller → Service → Mapper → MySQL、功能模块图、用户用例图、数据库E-R图、订单状态流转图、核心功能时序图。不需要画得多专业用画图工具或在线绘图工具画清楚就行重点是图和代码、表结构能对上。每年答辩现场被老师抓出“图和实现不一致”的案例挺多的一定要自查。5.2 演示视频录制要点演示视频的目的不是展示所有功能而是让看视频的人快速了解“这个系统是完整的、能跑的”。我建议按角色脚本录制先管理员登录审核一条商品再农户登录发布商品、处理订单最后采购商登录搜索商品、加入购物车、下单、确认收货。整个过程控制在8到12分钟按模块分段录方便后期剪辑。录屏的几个小技巧提前把要演示的数据准备好商品图片、用户账号、测试数据屏幕分辨率调成横向比较舒服的尺寸旁白讲“我在做什么”而不是“我在点什么”出现弹窗报错时不要慌直接说明这个异常是演示数据导致的。我自己录过很多次项目视频最深的体会是“演示路径要提前走两遍”第一遍按正常流程走第二遍检查有没有点错、有没有数据没准备好。5.3 本地部署与打包发布从开发环境到效果展示部署说明要写得让导师或者评审老师照着能做出来。按步骤写就清楚了安装JDK 1.8、MySQL 5.7、Node.js 14、Maven 3.6。在MySQL中新建数据库导入项目提供的farm_supply.sql脚本。修改后端application.yml中的数据库账号密码、文件上传目录。在项目根目录执行mvn clean package打出来的jar包放到一个目录执行java -jar xxx.jar启动后端。前端在源码目录执行npm install安装依赖然后npm run build打包出dist目录本地调试就直接npm run serve。访问前端地址默认管理员账号登录完成功能验证。我的习惯是把后端默认端口设为8080前端开发服务器设为8081并在Vue的vue.config.js里配置代理把/api开头的请求转发到后端。这样前端代码里直接写相对路径等上线时再让后端把dist目录放到static下或者用Nginx做反向代理整个过程比较平滑。部署完记得把后端启动日志里明显报错的部分清理掉再截图演示效果会好很多。6. 常见问题排查与答辩准备踩坑实录和高频问答6.1 环境与部署问题排查这个项目的运行环境问题基本集中在这几个地方我整理了一份排查表对应现象和解决办法都列出来问题现象常见原因解决办法启动报端口占用后端口被其他程序占用netstat -ano查占用进程换端口或结束进程数据库连接失败账号密码错误、数据库没建、时区问题检查application.yml连接串加serverTimezoneAsia/ShanghaiMaven依赖下载超时默认源慢换成阿里云镜像仓库重新mvn clean install前端依赖安装失败Node版本过高或网络问题用Node 14/16版本删除node_modules后重装图片无法访问上传目录不对、静态资源映射没生效确认目录存在检查映射配置这里提醒一下时区问题特别常见MySQL 8.0默认时区是UTC不改的话插入时间会差8小时。连接串里带上serverTimezoneAsia/Shanghai一次解决。6.2 前后端联调问题排查联调阶段最考验耐心。我的排查思路是先看前端Network面板请求有没有发出、返回什么状态码再看后端控制台日志异常有没有打印最后检查两端字段名和类型是否一致。如果接口报401大概率是Token没带上或已过期先清浏览器缓存重新登录如果报404先确认后端接口路径和前端请求路径完全一致如果数据能返回但前端不显示多半是字段名对不上createTime和create_time。把前后端联调通之后建议把关键接口的请求和响应各截图几张后面论文的“系统实现”章节直接能用演示视频里也可以放一两个接口调试画面显得项目真实、有深度。6.3 答辩高频问题与应对思路答辩环节是整个毕设的临门一脚。我根据这个题目总结几个出现频率比较高的提问以及对应的回答思路老师可能会问思路和准备方向为什么选择这个课题从山区农产品信息不对称的实际痛点切入说明系统有真实应用价值前后端分离的好处开发效率、并行开发、职责分离、接口复用登录安全怎么做的用户密码BCrypt加密存储、JWT设置有效期、后端拦截器统一校验、管理端接口单独限制角色订单和库存的一致性怎么保证创建订单和扣减库存放在同一事务中扣库存使用stock quantity条件更新保证并发安全核心表有哪些关系是什么用户-商品-订单-订单明细讲清晰一对多关系强调订单明细里的快照字段系统测试做了哪些功能测试用例表、角色操作流程测试、兼容性和异常场景说明如果用户投诉商品质量怎么办可以扩展售后流程、用户评价体系、原因说明体现你对系统演进有思考我建议你在答辩前自己照着这些问题过两遍重点不是背答案而是真正理解每一行代码背后的逻辑。老师喜欢问“为什么这样设计”而不是“这段代码怎么写的”所以你在做项目时每做一个决定都要问自己一句“为什么”这本身就是最好的答辩准备。最后再分享一个个人经验我在经手很多个毕设项目后发现源码能不能跑通只是起点真正拉开差距的是“你能不能把这个系统讲清楚”。像库存一致性、订单状态机、审核流程、Token过期策略这些点你只要自己亲手敲过一遍、调过一遍答辩被问到的时候根本不用背顺口就能说清楚。项目做完之后我建议你再花半天时间把表结构、接口清单、核心业务流程整理成一页纸答辩前对着这页纸过两遍基本就稳了。后面如果想继续扩展App端适配、对接真实支付、接入物流查询这些都还有很大的空间但核心链路打通了扩展就都是加分项。