1. 这个项目到底在解决什么问题毕设选题与需求拆解先说个好多人容易忽略的点毕设选题决定了你后面大半年是舒服还是折磨。我见过太多人选了那种智能推荐系统基于深度学习的什么什么检测一听很高端结果数据凑不齐、模型跑不动、导师一问原理就答不上来最后开题时吹的牛全变成答辩时的坑。供应商管理系统这个选题好在哪里它是典型的企业管理类Web系统需求清晰、边界明确、功能可量化而且覆盖了Java Web毕设该有的所有核心考点CRUD、关联表设计、分页查询、文件上传、权限控制、报表统计、多条件筛选。这种项目不需要玄学算法撑场面只要功能完整、流程顺畅、接口规范就能拿一个体面的分数。那供应商管理系统到底是管什么的用大白话说一个企业要采购原材料或者服务不可能满世界随便找供应商总要有个系统来登记谁有资质、谁报价低、谁交付及时、谁的合同快到期了。这个系统围绕供应商的全生命周期来做功能准入时登记基础信息合作中记录报价和订单事后做绩效评价最后形成一条完整的管理闭环。我拿到需求后第一件事不是写代码而是把角色和模块拆清楚。这套系统的用户分三类管理员负责供应商准入审核、用户管理、系统配置、数据统计。采购员检索供应商、发起询价、创建采购订单、提交收货记录。供应商如果做成多端的话维护自己的资料、上传资质、查看订单状态。不过很多毕设版本会把供应商侧简化成纯数据被动录入由管理员或采购员代为维护这个取舍跟你的项目周期直接相关。我建议第一次做这个题目的人功能列表控制在以下范围就够了供应商档案管理增删改查、多条件搜索、状态流转资质证照管理上传文件、有效期预警产品与报价管理每种供应商能供什么货、最新报价是多少采购订单管理从订单生成到收货完成的流程跟踪供应商评价管理按交付质量、价格、服务打分系统管理用户、角色、菜单权限数据仪表盘供应商数量统计、品类分布、订单趋势这个范围既撑得起平台两个字又不会让开发量失控。后面写代码时你会感谢自己当初没有再加什么供应商协同工作流引擎智能价格预测那种需求属于给自己加戏。2. 技术选型背后的真实考虑为什么是SpringBootVue这个题的标题已经把技术栈钉死了但作为过来人我还是想聊聊为什么这套组合适合毕设以及你在开题报告和答辩PPT里怎么把选型动机讲得有理有据。这比代码本身更能让导师觉得你思路清楚。2.1 后端选SpringBoot的真实理由SpringBoot不是因为大家都在用所以我也用它的核心优势对毕设这种短周期项目来说几乎是量身定制的。首先是起步成本低。传统SSH或者SSM那套光配置文件就能劝退一批人Spring自动配置机制把这些东西全兜住了。你创建一个SpringBoot项目引入spring-boot-starter-web写个RestController就能跑起一个Web服务前后不超过十分钟。这对毕设这种从零到演示往往只有两三个月的冲刺时间的场景极其重要。其次是生态整合省心。连接MySQL用spring-boot-starter-jdbc或者MyBatis做权限用Spring Security或者Sa-Token文件上传就是MultipartFile导出Excel有EasyExcel几乎每个需求都能找到现成的starter不用自己去造轮子。我的经验是毕设阶段千万不要自己封装底层框架时间耗不起而且答辩时容易被问住。第三是自带容器、部署方便。SpringBoot内置Tomcat打包成可执行的Jarjava -jar就完了不需要单独去装配置Tomcat这对最后演示环境搭建来说是巨大的减压。后面我会讲部署细节现在你记住这个结论就行。2.2 前端选Vue的理由和版本差异Vue在国内Java Web毕设圈的地位不用多说关键是你得选对版本。现在网上很多老教程还在讲Vue 2你用Vue 2也能做但我想认真给你一个建议如果是从零开始做毕设用Vue 2还是Vue 3要看你的水平和时间。如果你之前只在学校学过Vue 2网上项目源码也大多是Vue 2的那就别纠结直接撸Vue 2 Element UI。为什么因为毕设最重要的是在规定时间跑通不是秀你的技术前瞻性。如果你已经有Vue 3的基础或者愿意花两天时间看文档那Vue 3 Vite Element Plus是更现代的选择打包速度、组合式API的代码组织方式都很舒服。我这个项目用的版本是Vue 2 Element UI原因特别现实网上的免费后台管理模板、现成组件示例、各种答疑帖子最多的是这个组合碰到问题搜起来效率最高。你要是选了Vue 3遇到一个冷门报错搜遍全网都找不到解法那种痛苦比版本老一点难受多了。前端这块后台管理系统的页面其实高度模式化左侧菜单、顶部面包屑、中间内容区放表格和表单。Vue的组件化开发正好把这种模式拆得很干净后面我会具体讲页面结构怎么搭。这里先记住一句话选型不是比参数是比我能不能在有限时间内交付一个能稳定演示的程序。3. 数据库表结构设计供应商管理系统的核心实体关系数据库设计是整个项目的地基地基歪了后面写什么代码都别扭。我在做这个项目时表结构前后调了三版第一版按供应商-产品-订单三张表硬啃结果发现资质证照、评价记录这些数据无处安放第二版才把实体关系理顺。给大家看看最终版本的设计思路这是源码里SQL脚本的核心。3.1 核心表清单与设计意图我先列一张总表让你对整体有个概念然后再拆重点表说明。表名作用关键字段关联关系sys_user系统用户id, username, password, real_name, role_id关联角色表sys_role角色id, role_name, role_key被用户表引用supplier供应商主表id, supplier_code, name, credit_code, status被多张业务表引用supplier_contact供应商联系人id, supplier_id, name, phone多对一供应商supplier_qualification资质证照id, supplier_id, cert_name, cert_no, expire_date多对一供应商product_category产品品类id, category_name, parent_id自关联树形product产品id, product_name, category_id, spec关联品类supplier_product供应商供应产品id, supplier_id, product_id, price多对多中间表purchase_order采购订单主表id, order_no, supplier_id, total_amount, status关联供应商purchase_order_item订单明细id, order_id, product_id, quantity, unit_price一对多订单supplier_evaluation供应商评价id, supplier_id, score, eval_content, eval_time多对一供应商3.2 供应商主表的设计细节supplier表是整个系统的数据中枢我见过很多人把联系人、电话、地址全堆在这一张表里结果一个供应商有多个联系人时就傻眼了。正确的做法是主表只存供应商不可变的身份信息变化的、多值的信息拆到子表。CREATE TABLE supplier ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, supplier_code varchar(32) NOT NULL COMMENT 供应商编码, name varchar(128) NOT NULL COMMENT 供应商名称, credit_code varchar(64) DEFAULT NULL COMMENT 统一社会信用代码, legal_person varchar(64) DEFAULT NULL COMMENT 法人代表, address varchar(255) DEFAULT NULL COMMENT 注册地址, category_id bigint(20) DEFAULT NULL COMMENT 主营品类, status tinyint(4) DEFAULT 0 COMMENT 状态0待审核 1合作中 2已停用, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_supplier_code (supplier_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT供应商主表;这里有两个容易踩坑的点supplier_code必须唯一且手动生成不要用自动递增充当代码因为代码会有业务含义比如用日期加序号生成而且后续导入导出时唯一标识不会乱。状态字段用tinyint而不是varchar0待审核、1合作中、2已停用、3已黑名单这个在代码里用枚举去对应。为什么不用字符串因为数据库里存字符串容易大小写不一致、空格混入查问题查到头皮发麻用数字虽然语义不够直观但配合代码注释和文档反而是最稳的。3.3 资质证照表和有效期预警的设计供应商的资质证照是审核的关键依据这张表设计的亮点在于过期提醒功能。表里有expire_date字段业务层每次查询时对比当前日期把已过期和30天内到期的记录标记出来前端列表里做醒目的红色和黄色标签。这个功能看起来小但在答辩演示时效果极好——导师会直观感受到这个系统在主动替用户着想而不只是数据堆积。CREATE TABLE supplier_qualification ( id bigint(20) NOT NULL AUTO_INCREMENT, supplier_id bigint(20) NOT NULL COMMENT 供应商ID, cert_name varchar(128) NOT NULL COMMENT 证书名称, cert_no varchar(128) DEFAULT NULL COMMENT 证书编号, expire_date date DEFAULT NULL COMMENT 有效期至, file_url varchar(255) DEFAULT NULL COMMENT 证照文件路径, remark varchar(255) DEFAULT NULL, PRIMARY KEY (id), KEY idx_supplier (supplier_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT供应商资质证照表;file_url字段直接存文件访问路径文件本身上传到本地磁盘目录有条件的可以接MinIO对象存储后面我会讲这个可扩展点。毕设阶段不建议搞分布式存储本地目录挂一个虚拟路径映射就够了这点在第6部分部署时会细说。3.4 多对多关系的中间表设计供应商和产品之间是多对多关系一个供应商可以供应多种产品一个产品也可能有多个供应商供货。所以必须有supplier_product中间表而且这张表上还要带价格字段因为某供应商对某产品的报价是业务上要记录的关键数据。这就在多对多基础上扩展出了业务属性是数据建模里很经典的用法。同样采购订单主表purchase_order和订单明细purchase_order_item是一对多的父子结构。为什么订单要拆两张表因为一张订单里可能有多个产品每行明细有各自的数量和单价如果只做一张表那同一个订单号要重复很多行主表的订单金额就不知道放哪里好了。拆开之后主表存订单号、供应商、总金额、状态明细表存每一行的货物明细主表和明细通过order_id关联逻辑清爽、统计方便。这个表的拆分逻辑建议在论文的数据库设计章节大幅写一下很容易展现实力。4. 后端接口设计与实现从Controller到业务层的完整落地后端的实现质量直接决定系统稳不稳。这个项目的后端我建议按经典的分层结构来Controller接收请求、Service处理业务、Mapper操作数据库。下面把接口设计规范和核心业务链路拆开讲。4.1 统一接口规范返回体与异常处理先定一个统一返回体这是项目里所有接口的外壳{ code: 200, message: 操作成功, data: { } }code200表示成功其他值表示业务异常message携带具体提示data是业务数据。Java后端对应一个泛型类ResultT所有Controller方法都返回它。这样做的好处是前端Axios拦截器一套统一处理逻辑不需要每个接口单独判断。异常处理也是一个必须写好的点。数据校验失败、供应商不存在、订单状态不能变更这些都属于业务异常。项目里我定义了一个BizException在Service层遇到问题就throw new BizException(xxx)再配一个RestControllerAdvice全局异常处理器统一捕获。这样做代码里就没有一堆try-catch嵌套了逻辑读起来干净很多。4.2 核心模块的接口设计清单我把主要接口列成一张表你对照着看就知道一个完整的供应商管理系统需要覆盖哪些端点。这张表同时也是你写接口文档时的目录骨架。功能模块请求方法路径说明登录认证POST/api/auth/login登录返回Token供应商管理GET/api/suppliers分页多条件查询供应商管理POST/api/suppliers新增供应商供应商管理PUT/api/suppliers/{id}修改供应商供应商管理PUT/api/suppliers/{id}/status变更状态审核/停用资质证照POST/api/suppliers/{id}/qualifications添加资质资质证照GET/api/suppliers/{id}/qualifications查看资质列表产品报价POST/api/supplier-products配置某供应商供应产品及报价产品报价GET/api/suppliers/{id}/products查询某供应商的产品列表订单管理POST/api/orders创建采购订单订单管理GET/api/orders分页查询订单订单管理PUT/api/orders/{id}/receive确认收货供应商评价POST/api/evaluations新增评价供应商评价GET/api/evaluations/supplier/{id}查询某供应商的评价记录数据统计GET/api/dashboard/summary供应商数量、订单趋势等统计文件上传POST/api/upload上传资质证照文件用户管理GET/POST/PUT/api/users系统用户的增删改查说一个很多毕设源码里常见的偷懒写法把多个操作揉进一个接口里。比如供应商状态审核功能有人就直接用PUT /api/suppliers传个对象把状态字段一起改了这样看起来节省了接口数量但审计追溯很麻烦。正规做法是单独的路径加status参数并且把操作日志记录下来。项目里我把状态变更加了专门的接口旁边还加了一行记录是否审批通过、审批人是谁这部分细节答辩时很加分。4.3 供应商分页查询的后端实现逻辑供应商列表是系统里用得最多的功能没有之一。它需要支持按供应商名称模糊搜索、按状态筛选、按品类筛选、分页展示。这个接口看起来简单但背后有几点值得展开Controller层用参数对象接收查询条件GetMapping(/suppliers) public ResultPageResultSupplierVO page(SupplierQuery query) { return Result.success(supplierService.pageSuppliers(query)); }SupplierQuery里包含pageNum、pageSize、keyword、status、categoryId这几个字段。Service层拿到参数后构造MyBatis的QueryWrapper或者XML里的动态SQL核心是动态条件拼接不能用字符串拼SQL防止SQL注入。这个是MyBatis-Plus的写法条件构造器会自动忽略null值条件LambdaQueryWrapperSupplier wrapper Wrappers.lambdaQuery(); wrapper.like(StringUtils.isNotBlank(query.getKeyword()), Supplier::getName, query.getKeyword()); wrapper.eq(query.getStatus() ! null, Supplier::getStatus, query.getStatus());分页用MyBatis-Plus的PageSupplier配合selectPage一步到位。然后把查出的实体列表转成VO返回给前端VO里把categoryId翻译成品类名称、把status翻译成中文状态这些翻译动作放在Service层做不要让前端来猜。4.4 采购订单状态流转的实现订单状态是整个系统里最有业务感的逻辑它有一个明确的状态机草稿(0) - 已下单(1) - 已收货(2) - 已完成(3) - 已取消(4)。创建订单时状态为草稿然后确认下单后变为已下单供应商发货后手动确认收货变为已收货全部流程走完进入已完成。这里最容易出的逻辑漏洞是乱序流转比如直接把已取消的订单改成已完成。在Service层写状态流转时必须做前置校验// 状态流转校验 OrderStatus current order.getStatus(); if (current OrderStatus.CANCELLED) { throw new BizException(已取消的订单不能继续流转); }这是状态机设计里很关键的处理方式代码量不大但能挡住80%的非法操作。答辩时如果被问到多个用户同时操作同一个订单怎么办你可以说把状态更新写成SQL条件更新WHERE id? AND status?这样即使两个请求同时进来也只有一个能更新成功。这个回答的含金量非常高因为它是真正在分布式并发场景下思考过的体现。4.5 文件上传与静态资源映射资质证照文件上传SpringBoot的MultipartFile接住后写到一个本地目录比如/data/upload然后返回访问路径/uploads/xxx.pdf。为了让前端能访问到这个目录需要配置虚拟路径映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 将 /uploads/** 映射到磁盘 /data/upload/ 目录 registry.addResourceHandler(/uploads/**) .addResourceLocations(file:/data/upload/); } }这个配置是毕设里必考的细节很多人的文件上传功能本地能用、部署到服务器就404十有八九就是忘了配置资源映射器。我在部署章节会再提一次。扩展点说一下如果你觉得本地存储太low想给系统加分可以接MinIO对象存储。minio加入到springboot也是最近很多人搜的关键词。MinIO是一个兼容S3协议的开源对象存储服务SpringBoot里引入依赖配置endpoint、accessKey、secretKey、bucketName调用MinioClient.putObject就能把文件传到对象存储。这也是我很推荐的一个加分点因为它在答辩时可以讲文件存储与业务解耦支持后续水平扩展。5. 前端页面与数据联调Vue后台管理的工程化细节后端接口完成后前端就是一个把接口数据填充进页面的过程但工程化之后还是有大量细节。前端代码组织我建议按页面-路由-组件-API四个层次来拆。5.1 前端项目结构的模块划分一个典型的Vue后台管理前端目录结构src/ ├── api/ # 接口调用封装 │ ├── login.js │ ├── supplier.js │ └── order.js ├── assets/ # 静态资源 ├── components/ # 公共组件 │ ├── Pagination.vue │ └── UploadFile.vue ├── router/ # 路由配置 ├── store/ # 状态管理Vuex ├── views/ # 页面 │ ├── login/ │ ├── supplier/ │ ├── order/ │ ├── evaluation/ │ └── dashboard/ └── utils/ # 工具函数 ├── request.js # Axios封装 └── auth.js # Token存取用views和components分隔的意义在于views是按路由维度组织的页面components是按复用维度组织的通用零件。比如供应商列表、联系人弹窗、资质上传这些页面组件之间一定会共用分页组件、状态标签组件、上传组件所以把通用逻辑抽到components里是省时间的关键。5.2 Axios封装拦截器与统一错误处理前端所有接口调用都走统一封装的Axios实例。这个封装要做三件事// utils/request.js import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器加上Token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) // 响应拦截器统一处理后端返回的code service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { Message.error(error.message || 网络异常) return Promise.reject(error) } )响应拦截器里判断code并弹出后端返回的message意味着前端每个API调用就只需要写请求本身错误处理全是自动的。这里有个容易被忽略的细节不要把整个Response返回直接返回res.data让业务代码拿到的就是后端数据本体代码会清爽非常多。5.3 Element UI表格页面的标准写法以供应商列表页为例标准的四段式搜索区、按钮区、表格区、分页区。搜索区是一个el-form内联表单表格区是el-table绑定数据数组分页区是el-pagination。这里我分享一个写表格页面的小套路template div classapp-container !-- 搜索区域 -- el-form :inlinetrue :modelquery el-form-item label供应商名称 el-input v-modelquery.keyword placeholder请输入名称 clearable / /el-form-item el-form-item label状态 el-select v-modelquery.status placeholder全部 el-option label待审核 :value0 / el-option label合作中 :value1 / el-option label已停用 :value2 / /el-select /el-form-item el-form-item el-button typeprimary clickloadData查询/el-button /el-form-item /el-form !-- 表格区域 -- el-table :datalist border stripe el-table-column propsupplierCode label编码 width120 / el-table-column propname label供应商名称 / el-table-column propcategoryName label主营品类 / el-table-column label状态 template slot-scope{ row } el-tag :typestatusType[row.status]{{ statusText[row.status] }}/el-tag /template /el-table-column el-table-column propcreateTime label创建时间 width170 / el-table-column label操作 width220 fixedright template slot-scope{ row } el-button typetext clickviewDetail(row)详情/el-button el-button typetext clickhandleEdit(row)编辑/el-button el-button typetext clickhandleDelete(row)删除/el-button /template /el-table-column /el-table !-- 分页 -- el-pagination background layouttotal, prev, pager, next, sizes :totaltotal :page-sizequery.pageSize current-changehandlePageChange size-changehandleSizeChange / /div /template这段代码里有两个细节说一下。一是状态列用el-tag加动态类型让不同状态变色体验感直接上一个台阶二是操作列加fixedright当表格横向滚动时操作按钮始终可见这个交互细节导师演示时很容易注意到。5.4 前端路由与权限控制Vue Router配置里登录页和首页分开业务页面全部挂在Layout布局组件下作为子路由。权限控制的简单做法是在前端路由配置的meta字段里加roles比如供应商管理页面仅管理员可见。不过更真实的做法是后端返回该用户可访问的菜单列表前端根据它动态生成路由这就是很多人搜的vue动态路由。动态路由实现起来不难登录成功后请求/api/auth/menus拿到当前角色可见的菜单数组用router.addRoutes动态添加。这样做还有个额外的好处是侧边栏菜单也不用写死了直接根据菜单数据循环渲染。权限控制这块在毕设里属于加分项如果你时间不够先做好按钮级别的权限就够了。6. 从源码到可演示本地环境部署全流程与避坑指南不管代码写得多漂亮最后导师要看的是能跑起来的演示。这一章我把整个部署流程从头到尾捋一遍全是实操中容易卡住的地方。我拿到的这套源码配套了SQL脚本和接口文档正好可以按标准流程走。6.1 环境准备清单先把环境版本定下来避免后面各种不兼容问题软件推荐版本说明JDK1.8 或 11别用太高版本如JDK 21某些老依赖不兼容Maven3.6.x 或 3.8.x配置阿里云镜像加速下载MySQL5.7 或 8.0注意8.0的驱动名变化Node.js14.x 或 16.xVue 2项目建议16Vue 3 Vite建议18npm/yarn随Node建议指定淘宝镜像源这里重点说两个坑SpringBoot版本太高是个常见问题很多项目的代码是基于SpringBoot 2.x写的你非要用3.x测会发现一堆javax和jakarta包名不兼容的错误。拿到源码先看pom.xml里的parent版本如果它写的是2.x就老老实实用JDK 8。MySQL 8和MySQL 5.7的驱动差异驱动名从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver而且8.x要求配置时区参数serverTimezoneAsia/Shanghai。修改application.yml时注意区分。6.2 导入SQL脚本的正确顺序项目提供了SQL脚本但很多人导入时会踩坑。正确步骤是先在MySQL里创建数据库CREATE DATABASE supplier_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;选择数据库USE supplier_db;执行SQL脚本source /path/to/init.sql;命令行方式或用Navicat直接运行SQL文件。这个顺序有个关键点先建库再跑脚本。如果SQL脚本里没有CREATE DATABASE语句而你又直接运行会报没有选择数据库的错误。还有字符集一定要用utf8mb4因为它能存储emoji和生僻字utf8在MySQL里是不够用的。导入完成后检查一下数据正常情况下应该有管理员账号比如admin/admin123、若干个测试供应商、几笔订单数据。强烈建议别清空这些测试数据演示时直接有内容看比现场造数据体面多了。6.3 后端启动流程与常见报错后端配置集中在application.yml里。需要修改的无非是数据源spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/supplier_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你自己的密码 servlet: multipart: max-file-size: 50MB max-request-size: 50MBmultipart配置是文件上传功能必须的不配的话默认1MB传个资质证书图片都可能会报错。启动时用IDE直接跑主类或者打包后跑java -jar xxx.jar。常见报错和排查思路Access denied for user用户名密码错误或者权限不够。Unknown database数据库没建成功。Port was already in use8080端口被占用改server.port。Failed to configure a DataSource数据源配置没生效检查application.yml的缩进层级。Failed to configure a DataSource这个报错很阴险它不一定是你配置写错了而可能是配置文件根本没被加载。检查方法看启动日志里有没有加载配置的提示或者在application.yml目录确认一下文件名是不是拼错了application不是applications。6.4 前端启动与联调前端启动前先装依赖。强烈建议用npm并指定镜像源npm install --registryhttps://registry.npmmirror.com npm run devnpm install慢或者报错是新手最常卡住的地方。如果一直卡住用淘宝镜像如果node-sass安装失败这个东西是Vue 2项目的常客尝试用npm install -g node-sass --registryhttps://registry.npmmirror.com或者在项目里换dart-sass替代后者是更省心的选择。前端跑起来后会有个关键问题跨域。前端开发服务器默认跑在8080可能被后端占了接口请求的跨域问题需要配置vue.config.js里的代理module.exports { devServer: { port: 8888, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端的/api开头的请求全部转发到后端8080端口解决了跨域问题前后端联调顺畅。这个代理配置在本地方便但如果最后要打包成生产部署就用Nginx做反向代理把前端和后端挂在同一个域名的不同路径下。我把这个细节写在部署章节的最后因为很多毕设演示就是在本地跑记住开发代理这一条就够了。7. 答辩呈现、接口文档与常见追问拆解代码跑通只是第一步把项目的价值讲清楚、把导师可能追问的点提前准备到才是毕设拿高分的关键。这一章我说些实在的答辩经验。7.1 接口文档的正确打开方式配套提供的接口文档是项目的说明书但我不建议答辩时灵机一动翻文档那样显得对项目不熟。正确用法是把接口文档里每个接口的作用、参数、返回结果都过一遍做到心里有数。比如导师随口问供应商分页查询支持哪些条件你张口就来支持名称模糊查询、状态筛选、品类筛选、分页然后顺手在演示页面里操作一遍给他看。如果接口文档是Swagger自动生成的答辩时打开Swagger UI界面也是一种很专业的展示方式。不会手写接口文档的话项目里可以用springfox-swagger2或者knife4j国产增强版页面更好看生成在线接口文档。Knife4j接入很简单加依赖、加EnableKnife4j注解启动后访问/doc.html就能看到漂亮的接口列表。这个属于一眼就能看到的加分项。7.2 演示流程怎么走最稳我的习惯是设计一条业务故事线来演示而不是东点一下西点一下。推荐顺序登录演示管理员登录顺带说一句登录用了JWT Token认证用户密码是MD5加盐存储。仪表盘一进来先看数据仪表盘指出供应商总数、品类分布、订单趋势让导师第一眼觉得这系统有数据支撑。供应商列表演示分页、搜索、筛选点击一个供应商进详情页。供应商审核找一个状态为待审核的供应商演示审核通过状态从灰色变成绿色标签。供应商资质查看展开详情里边的资质证照列表指出有有效期预警。创建采购订单从供应商列表切入选择该供应商的产品填数量价格生成订单再到订单列表看到新订单出现。供应商评价给一个合作过的供应商打分保存后列表出现评价记录。图表收尾回到仪表盘此时采购订单趋势图多了一个点说明刚才的演示产生了真实数据变化。这套演示流程的逻辑是每个操作步骤都在验证前一个步骤的结果导师会觉得整个系统浑然一体而不是各个页面孤立的拼盘。而且最后图表多了一个点这种细节能展现出系统的数据联动能力这个点千万别忽略。7.3 导师必问的问题与回答思路根据我的经验导师问来问去就这么几个方向提前准备就稳了你的系统有哪些角色权限怎么控制的答分管理员和采购员两类后端用拦截器校验Token前端通过动态路由控制菜单显隐。如果只做了单一角色就如实说当前版本以管理员为核心后续可以扩展多角色。MySQL有几种表为什么这么设计答说清楚核心表有哪些、哪几张是关联表中间表、为什么要拆订单主表和明细表。这是体现你数据库基本功的时刻。状态字段是怎么设计的为什么要用数字不用字符串答数字存储省空间、查询快、不容易写错代码中用枚举去映射可以避免魔法数字到处飞。同时提一句状态机流转显得有设计感。如果供应商数量很大比如百万级你的查询怎么优化答这是经典的性能引申问题。你可以先说当前用了单表索引和分页大规模场景下可以加Redis缓存热点数据、引入Elasticsearch做全文检索、根据查询模式建联合索引、垂直拆分和水平分表。重点是让导师看到你有意识地站在扩展性上思考过。你做了哪些测试系统质量怎么保证答功能测试覆盖了所有接口的正常和异常场景重点测了订单状态流转和权限拦截如果写了接口测试类也可以提。注意不要吹做了完整自动化测试导师随便追问细节就容易露馅。这些问题都不难但需要你提前把答案组织好、说到点子上。写论文的时候把这些问题的答案作为核心论据分散到各个章节论文的查重率和逻辑性都会更好。7.4 拿着这套项目还能往哪里扩展毕设交付不是终点。如果后续你想继续完善这个项目或者面试时拿来当作品集聊我可以给几个扩展方向按投入产出比排序MinIO对象存储替换本地文件存储让文件模块更贴近生产环境。引入Redis做验证码缓存和接口限流登录验证码、供应商列表的缓存实现起来都不难面试能聊的深度立刻提升。基于WebSocket做审核消息通知供应商提交资料后管理员页面实时弹出一条待办通知技术点清晰、演示效果惊艳。对接EasyExcel做供应商资料批量导入导出企业中几乎必备涉及大数据量处理简历上也能写一条。这些扩展方向不需要全做挑一两个就够。它们背后的共同逻辑是把一个简单的管理页面做到有真实工程的样子这在面试官和导师眼里含金量是完全不同的。最后说点实际的个人体会。做毕设这件事目录上抄十张表不如自己上线跑通一个完整流程。我见过太多同学把时间耗在纠结选什么技术栈更酷、要不要加个算法上面最后连基本的增删改查都写得磕磕绊绊。这套供应商管理系统最值得学习的地方恰恰在于它把一个常见的业务场景用最稳妥的技术栈老老实实落地了——数据建模清楚、接口规范统一、前后端分工明确、能部署能演示毕设该有的它全有了。你照着跑通一遍、把每一行代码都看明白再去谈扩展和优化自然就知道下一步该往哪里走。