SpringBoot2+Vue3供应商管理系统实战：从表结构设计到前后端部署全解析

每个做企业应用的老哥应该都遇到过类似的场景：老板哪天突然甩过来一句"搞一套供应商管理系统，把咱们的供货商资料和采购买卖捋清楚"，然后你就要在一个月内从建库到上线拿出东西。这套项目就是干这个事儿的，技术栈是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，前后端分离的经典配方，源码和文档都齐了。适合有JavaSE基础、想练手完整业务系统的人，也适合毕业设计或者中小企业内部系统快速搭建的参考。

我这篇文章就把这套系统从头到尾拆开讲，从需求分析到表结构设计，从后端接口到前端页面，再附带我实操中踩过的坑和复盘笔记。内容偏实战，你可以直接照着做，也可以在这个基础上升级改造。

1. 项目定位与功能蓝图拆解

1.1 供应商管理系统到底要管什么

很多初学朋友一听到"供应商管理系统"第一反应是"这不就是个增删改查吗"。业务上确实以增删改查为核心，但关键在于"查哪张表、改什么状态"背后对应的业务规则。

这套系统设计上覆盖了供应商全生命周期管理，核心角色为采购员、仓库管理员和系统管理员三类。

它的核心目标是解决"供应商信息散落在Excel和聊天记录里"这个痛点。我见过不少小公司用Excel管供应商，一个人一个格式，数据从没准过。这套系统把供应商主数据、订单流程、考核评价整合到一条链路上，所有数据可追溯，这才是它真正值钱的地方。

1.2 角色权限与业务流程设计

业务流从供应商注册或录入开始，到确认合作、采购下单、仓库收货，最后回到对供应商的评价打分，形成闭环。

• 管理员：维护系统用户、角色、菜单权限，查看统计报表
• 采购员：维护供应商档案、发起采购订单、导出数据
• 仓库管理员：按订单收货入库、填写验收结果
• 供应商（可选）：可扩展账号查看自己的订单和评价

权限这块我建议不要过度设计，用简单的角色-菜单-按钮三级控制就行。每个请求拦截下来校验token对应的角色，再判断是否放行。这个系统用的就是JWT + 拦截器实现，不用引入Spring Security这个重家伙，入门理解起来容易，也不耽误二次开发。

这里有个值得留意的设计细节：订单状态和供应商状态要分开控制。供应商状态解决的是"能不能下单"，订单状态解决的是"这笔单走到哪一步"。如果混在一起，会出现供应商冻结之后历史订单状态也跟着乱套的麻烦。所以系统里供应商状态字段supplier_status独立管理，订单状态order_status只归订单管，两套状态互不干扰。

1.3 非功能需求与开发范围约定

这种系统看起来简单，但真要落地还是要约束一下范围。

• 支持数据导入导出：供应商Excel模板批量导入、供应商列表导出
• 敏感操作留痕：拉黑、冻结供应商要有操作日志
• 数据库采用逻辑删除，不从物理上删数据
• 权限数据在Redis做缓存（可选），登录token有效期为24小时
• 前端采用动态菜单渲染，根据角色返回菜单列表

我遇到的不少同学做这类项目时一上来就搞一堆花哨功能，什么消息推送、数据大屏全部往上加，结果核心的订单闭环反而没打通。建议你先按上面这套范围跑通主流程，把文档和测试用例补上，再考虑锦上添花。

2. 技术选型与架构设计，为什么是这套配方

2.1 SpringBoot2比SpringBoot3更稳妥

SpringBoot2.7.x是目前存量企业项目里存量极大的版本线，网上资料、开源组件兼容性、招聘岗位需求，都是围绕这个版本展开的。选它不是因为新，而是因为稳。

如果选SpringBoot3，最低要求JDK17，很多老一点的办公电脑和企业服务器JDK8还没换，跑起来就是一堆环境兼容问题。SpringBoot2搭配JDK8依然是当前后端开发的主流，尤其适合这种业务系统。

需要提醒的是SpringBoot2.7与SpringBoot2.5、2.6之间也有细微差异，比如循环依赖默认禁止策略在2.6以后调整了，配置属性的绑定规则也有变化。建议锁定SpringBoot 2.7.18这个版本，这是SpringBoot2线的最后一个版本，bug修复相对完善，也是我实测下来最稳的。

2.2 为什么MyBatis-Plus取代原生MyBatis

MyBatis-Plus本质上是MyBatis的增强工具，它的BaseMapper帮你把单表CRUD全封装好了。

开发这套系统时，单据类SQL（如订单明细按orderNo关联查询、统计报表查询）用自定义XML，简单CRUD全靠ServiceImpl继承IService，不需要写一行Mapper XML。以供应商档案管理为例，自动生成的insert、updateById、selectPage这些方法直接可用，省下大量样板代码。

事务处理上，采购订单创建要同时插入订单主表和明细表，我直接在Service方法上加@Transactional(rollbackFor = Exception.class)，一条SQL失败整单回滚，不产生半截订单。这个特性在原生MyBatis下你得自己写事务管理代码，MyBatis-Plus完全省了。

2.3 MySQL8.0到底强在哪

如果还在用MySQL5.7，这套系统跑也能跑，但8.0有几个优势是实打实的。

• 默认字符集utf8mb4，emoji和特殊符号存储不报错
• 窗口函数支持统计类SQL更简洁
• 不可见索引、直方图等优化特性让慢SQL排查更方便
• 支持公用表表达式（CTE），写递归查询更直观

这套系统中统计供应商订单总金额时我用了一段窗口函数，直接按供应商维度算出累计采购额，比传统group by + 子查询的性能表现好得多。

数据库连接串记得加useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai，不然连上8.0会报时区错误。这个坑后面第6节我会详细讲。

2.4 前端Vue3 + Element Plus的组合逻辑

Vue3的组合式API（Composition API）确实比Vue2的Options API适合做中后台系统，因为逻辑复用很舒服。同样的供应商查询条件、分页逻辑，用组合式函数（composables）抽出来以后，订单页、评价页都能复用同一套逻辑。

Element Plus在表单、表格、弹窗、反馈组件上非常成熟，尤其是el-table的列配置和el-form的校验机制。这套系统的前端不是硬凑的，核心页面都用了Element Plus的Pro风格布局，菜单、面包屑、标签页一应俱全。

前端工程化用的是Vite而不是Webpack，本地启动开发服务器基本秒开，热更新速度也远快于Webpack。Vite的proxy配合后端联调非常方便，一个/api前缀直接代理到后端8080端口。

3. 数据库设计，这套系统的地基

3.1 核心表结构与字段设计思路

数据库表设计是整个系统的地基，我直接贴出核心表的字段设计，结合业务场景来解释每个关键字段。

供应商主表（supplier）

为什么主键不用自增ID而用雪花ID？业务系统的供应商数据可能要从老系统迁移、要和其他系统同步，自增ID容易冲突。雪花ID全局唯一且带有时间趋势，MyBatis-Plus内置了ID_WORKER雪花算法策略，指定@TableId(type = IdType.ASSIGN_ID)即可。

供应商联系人单独拆一张表（supplier_contact），和企业客户的"一客多联系人"同理。一个供应商可能有采购对接人、财务对接人、售后对接人，主表只冗余一个默认联系人用于列表展示，完整的联系人均保存在子表。

3.2 订单与明细如何挂接

采购订单主表（purchase_order）的核心字段包括order_no、supplier_id、order_status、total_amount、payment_status、delivery_date。

采购订单明细表（purchase_order_item）的字段为order_id、product_name、specification、unit_price、quantity、amount。

主表和明细表通过order_id关联，一对多关系。做采购订单时，前端表格里可以动态添加多行商品明细，提交时后端用一个DTO统一接收主表数据和明细列表数据，一起insert。明细表冗余了product_name（商品名称）和specification（规格型号），这里刻意不做商品维度的大表设计，因为这类系统往往还没有完整的物料主数据，先按文本记录用，后面接ERP再升级物料编码。

订单金额的计算我采用了单价x数量累加的方式，前端负责展示，后端重新计算一遍防止伪造提交。前端算的金额不可信，后端必须二次计算，这也是这类系统的底线约束。

3.3 资质证书与评价表的关键设计

资质证书表（supplier_certification）有cert_type（证书类型）、cert_code（证书编号）、issue_date、expire_date、file_url（附件地址）、audit_status（审核状态）。证书到期提醒的SQL就是在查询时过滤expire_date < 当前日期+30天的记录，把即将到期的证书推给管理员处理。

供应商评价表（supplier_evaluation）的设计要留意评分字段的拆分，质量评分quality_score、交期评分delivery_score、服务评分service_score，总分为三项加权合计。总分用decimal(5,2)保存，避免因浮点运算产生精度问题。每次到货验收完成后，仓库管理员可以发起一次评价，数据积累起来就能用SQL统计出每家供应商的平均分，页面展示排名。

这套系统的评价维度只有三项，如果业务复杂还可以扩展价格评分、响应速度评分，字段设计预留了扩展空间。表结构千万不要一开始就埋太多冗余字段，宁可后期加字段，也别让表长成杂货铺。

3.4 常用查询SQL与索引设计

订单查询场景最多的是"某个供应商在某个时间段内的订单列表"。我在purchase_order表上建了联合索引(idx_supplier_create)：supplier_id + create_time，这样按供应商查询时间范围的数据，索引命中率非常高。

供应商列表搜索条件通常是供应商编码、名称、状态，我在supplier表的supplier_code上建了唯一索引，在supplier_name上建了普通索引。这里要注意：模糊查询如果写成LIKE '%xx%'，即使有索引也不走索引。可以用前缀匹配优化，或者用MySQL8.0的全文索引，不过量小的话直接like就行，性能不是瓶颈。

常见的统计SQL是查每个供应商的订单总数和采购总额：

SELECT supplier_id, COUNT(order_id) AS order_count, SUM(total_amount) AS total_amount FROM purchase_order WHERE order_status != -1 AND create_time >= #{startTime} GROUP BY supplier_id ORDER BY total_amount DESC

数据量大时考虑加创建时间的过滤条件，避免全表扫描。只要索引用对，这套系统的SQL写到什么阶段都不会有性能问题。

4. 后端核心业务：从接口设计到权限控制

4.1 统一结果集与异常处理

后端接口设计上，我先统一返回结构Result。这个类包含code、message、data三个基本字段，code为200表示成功，401表示未认证，500表示服务器异常，业务异常也可以自定义错误码。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.message = "success"; r.data = data; return r; } public static <T> Result<T> error(Integer code, String message) { Result<T> r = new Result<>(); r.code = code; r.message = message; return r; } }

配合@RestControllerAdvice做全局异常捕获，业务异常抛出ServiceException时统一转成Result结构返回。这样前端axios拦截器只需要判断code字段，不用每个接口单独处理错误分支。

4.2 供应商档案的分页/查询/导入导出

供应商档案是系统的第一个完整CRUD模块。分页查询使用MyBatis-Plus的Page对象：

@Override public Page<Supplier> querySupplierPage(SupplierQuery query) { Page<Supplier> page = new Page<>(query.getPageNum(), query.getPageSize()); LambdaQueryWrapper<Supplier> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(query.getSupplierName()), Supplier::getSupplierName, query.getSupplierName()) .eq(query.getSupplierStatus() != null, Supplier::getSupplierStatus, query.getSupplierStatus()) .orderByDesc(Supplier::getCreateTime); return this.page(page, wrapper); }

这段代码看起来不起眼，但有一个关键点：分页插件必须配置MybatisPlusInterceptor，不配置的话分页不会生效，这是新手最容易踩的坑。后面第6节我会写清楚。

Excel导入导出用的是EasyExcel（阿里开源的），相比POI它封装度高、内存占用小。导入模板第一行是供应商名称、联系人、电话等字段，解析时一行行校验，校验失败的行单独收集起来给出错误提示，不因为一行数据有问题就把整个导入任务中断。导出则直接查数据然后写Excel返回给前端下载。

4.3 采购订单的状态机设计

订单状态管理是这套系统业务复杂度最高的地方。我先定义了状态机：

0 待审核 -> 1 审核通过 -> 2 部分收货 -> 3 已完成 -> -1 驳回 0 待审核 -> -2 作废

状态流转用OrderStatusEnum枚举管理：

public enum OrderStatusEnum { PENDING(0, "待审核"), APPROVED(1, "审核通过"), PART_RECEIVED(2, "部分收货"), COMPLETED(3, "已完成"), REJECTED(-1, "已驳回"), CANCELLED(-2, "已作废"); }

这里有一个值得反复强调的思想：状态流转要写在Service层，不能在前端随便改。每次变更状态前做前置校验，比如只有"审核通过"的订单才能生成收货单，待审核的订单不能直接跳到已完成。这才能保证数据不出现"逻辑上不可能"的脏状态。

收货时如果实收数量小于订单数量，状态置为部分收货；如果全部收齐，状态置为已完成。这个判断在收货Service里完成，用事务包起来，收货单插入成功的同时更新订单状态。

4.4 JWT登录认证与权限拦截

登录流程：用户输入账号密码，后端验证成功后生成JWT token返回前端。前端把token存在localStorage，每次请求通过axios拦截器在header加上Authorization字段。

后端拦截器校验token：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && JwtUtil.verify(token)) { return true; } response.setStatus(401); response.getWriter().write("未登录或token已过期"); return false; } }

配置拦截器时需要对登录接口、静态资源、Swagger文档放行。权限控制在角色层面，用自定义注解@RequireRole("ADMIN")标注在需要特定角色的接口上，拦截器里读取角色信息和注解比对，不匹配直接返回403。

JWT这里有个实用细节：token里不要放太多业务信息，userId和role就够用了。用户被冻结之后要立即失去权限，光靠token是解决不了的。所以我加了一个简单的Redis token黑名单机制，冻结用户时把token加入黑名单，拦截器里查一下黑名单，实现"实时踢人"的效果。

5. 前端Vue3页面实现与前后端交互

5.1 工程初始化与项目结构

前端工程用Vite创建，npm create vite@latest supplier-web，选择Vue3 + JavaScript。项目目录结构如下：

src ├── api │ ├── supplier.js │ ├── order.js │ └── user.js ├── components │ ├── Pager.vue │ └── SupplierSelect.vue ├── router │ └── index.js ├── stores │ ├── user.js │ └── app.js ├── views │ ├── dashboard │ ├── supplier │ │ ├── SupplierList.vue │ │ └── SupplierDetail.vue │ ├── order │ │ ├── OrderList.vue │ │ └── OrderCreate.vue │ └── login │ └── Login.vue └── utils └── request.js

api目录统一放接口定义，views目录按业务模块拆页面，每个页面对应一个路由。中后台系统这么分层，维护成本是最低的。

5.2 Axios二次封装与请求拦截

request.js对axios做统一封装，核心逻辑是请求拦截器加token，响应拦截器处理业务错误码统一提示。

import axios from 'axios' import { ElMessage } from 'element-plus' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) service.interceptors.response.use(response => { const res = response.data if (res.code === 200) { return res } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { if (error.response?.status === 401) { localStorage.removeItem('token') window.location.href = '/login' } return Promise.reject(error) }) export default service

这套封装抽出来以后，每个业务模块的接口文件就非常干净：

// api/supplier.js import request from '@/utils/request' export function getSupplierPage(params) { return request.post('/supplier/page', params) } export function updateSupplier(data) { return request.put('/supplier', data) }

5.3 供应商列表页：动态表格与分页

供应商列表页是最典型的表格页面。页面加载时调用分页接口，把查询条件和分页参数传给后端。

组合式API在这里优势很明显，把查询、加载、重置逻辑封装成可复用的函数：

export function useSupplierList() { const loading = ref(false) const list = ref([]) const total = ref(0) const queryParams = reactive({ pageNum: 1, pageSize: 10, supplierName: '', supplierStatus: null }) async function fetchList() { loading.value = true const res = await getSupplierPage({ ...queryParams }) list.value = res.data.records total.value = res.data.total loading.value = false } return { loading, list, total, queryParams, fetchList } }

分页组件直接配合el-pagination，current-change和size-change事件触发fetchList重新查询。页面侧边栏菜单根据登录角色动态渲染，Vue Router的路由守卫在跳转前判断权限，不匹配页面会重定向到403页面。

5.4 采购订单创建页：动态添加明细

订单创建页是前端交互最复杂的部分。用户选择供应商后，下方明细表格可以逐行添加商品、填写单价数量，合计金额实时计算。

实现用的是el-table + el-input组合，明细数据保存在订单表单的items数组里。每次添加一行就push一个新对象，删除行就splice掉。因为明细项总金额=单价×数量，用computed对items做reduce求和，页面实时显示总金额。

提交时把form和items打包成一个payload发送给后端。这里前端有一个隐藏逻辑：提交前必须校验明细行至少有一行，商品名称不能为空，单价不能小于0，数量必须是大于0的整数。Element Plus表单校验规则配合自定义validator可以完成大部分校验，但行内校验我习惯在提交前整体循环检查一次，保证万无一失。

6. 前后端联调、部署与常见坑点实录

6.1 开发环境跨域代理

前端用Vite本地开发时，接口路径/api的请求默认会被浏览器拦截跨域，通过在vite.config.js中配置proxy解决：

export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: path => path.replace(/^\/api/, '') } } } })

生产环境交给Nginx反向代理，配置下面这段就够：

location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }

6.2 MySQL8.0时区报错与驱动兼容

MySQL8.0连接串少了serverTimezone参数，启动项目时会直接抛InvalidConnectionAttributeException异常。这个问题我开发时连着两次遇到，印象很深。

正确的URL格式：

jdbc:mysql://localhost:3306/supplier_db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval=true是MySQL8.0的另一个小坑，不设的话部分版本会报Public Key Retrieval is not allowed错误。驱动建议用mysql-connector-j 8.0.x版本，JDBC驱动类和5.x不同，从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver。

6.3 MyBatis-Plus分页失效与正确配置

很多人写好了Page查询，却发现返回的total一直是0，records也没有分页效果。原因就是没有注入分页插件。

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

这个配置类的完整版还需要配置LogicDelete逻辑删除插件和OptimisticLocker乐观锁插件。逻辑删除我用的是@TableLogic注解配合全局配置logic-delete-field，删除操作自动转成update set is_deleted=1，查询自动过滤is_deleted=0的数据，这比物理删除安全得多。

6.4 LocalDateTime序列化格式

SpringBoot返回的LocalDateTime默认序列化成"2025-01-15T10:30:00"这种带字母T的格式，前端显示很不友好。我在application.yml里做了全局配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这样所有接口返回的日期格式统一，前端表格渲染不再需要单独处理时间字符串。

6.5 订单明细批量插入的事务控制

采购订单创建接口涉及订单主表+明细表+操作日志三张表的写操作。任何一张表插入失败，数据都不能落库。在Service方法上添加事务注解，并指定rollbackFor：

@Transactional(rollbackFor = Exception.class) public Long createPurchaseOrder(PurchaseOrderCreateDTO dto) { // 1. 校验供应商状态 // 2. 计算订单总金额 // 3. 插入订单主表 // 4. 批量插入订单明细 // 5. 插入操作日志 return orderId; }

rollbackFor = Exception.class这个细节不能省，不加的话RuntimeException才会回滚，某些受检异常可能导致事务失效。交易类场景的代码里我就是被这个问题坑过才长记性的。

6.6 几张实用排查SQL

上线后发现某个供应商的订单金额对不上，我会先用这几条SQL定位问题：

-- 查看订单主表金额 SELECT order_no, total_amount, create_time FROM purchase_order WHERE supplier_id = 1001 AND create_time BETWEEN '2025-01-01 00:00:00' AND '2025-12-31 23:59:59'; -- 按明细累计金额，核对主表金额是否一致 SELECT order_id, SUM(quantity * unit_price) AS detail_total FROM purchase_order_item GROUP BY order_id HAVING detail_total < 0;

这类SQL在联调阶段能帮你快速定位是前端传参问题还是后端计算问题，建议实际项目中提前准备。

7. 实操心得：开发这套系统的经验复盘

项目开发过程中，我踩过不少坑，也积累了些值得分享的经验。列几条最实用的：

字段类型和校验要前置设计。供应商的联系电话在数据库里用varchar(20)，但前端表单校验规则里一定要写手机号正则。数据从Excel导入时，电话一列能解析成科学计数法（比如1.38E+10），必须在导入逻辑里做格式转换。这个问题在导出Excel回来看数据时极其常见。

逻辑删除不要和唯一索引冲突。供应商表的supplier_code是唯一索引，逻辑删除的供应商还占着这行数据，如果再次导入同一个code会违反唯一索引冲突。我采用的方案是唯一索引改为supplier_code + is_deleted联合索引，这样逻辑删除的数据不阻塞重新录入同编码供应商。

不要过度封装。这种规模系统的Service层直接暴露业务动作是最直观的。我见过有人搞了三层泛型基类套娃，改一个字段要跳五层代码，维护成本反而暴增。中小型项目优先保证代码直白可读，比花里胡哨的架构设计更重要。

接口参数校验别省。前端做了表单校验，后端同样要走参数校验，我习惯在DTO字段上标注@NotBlank、@NotNull、@Min等校验注解，配合@Validated统一处理。不要信任任何前端传过来的数据，这笔功夫不能省。

库存和金额用Decimal不要用Double。Java的Double在计算金额时会有精度丢失风险，数据库存储金额用decimal(10,2)，实体类用BigDecimal。BigDecimal除法还要指定精度和舍入模式，这些细节看着小，但在财务对账时就是大事儿。

这套系统做完，我最大的感受是：一个项目值钱的部分不在代码量，而在数据结构和状态流转是否设计得干净。供应商管理系统的技术点不复杂，但"设计表结构时有没有想到一客多联系人，做订单时有没有考虑部分收货的状态，做评价时有没有把评分维度拆开"，这些才是真正体现业务能力的地方。

如果在现有基础上继续扩展，可以往三个方向走：引入消息队列做采购订单异步通知、加PowerJob或Quartz做证书到期定时提醒、用ECharts做采购金额趋势大屏。不管怎么扩展，核心主链路这版代码已经打好了底子，框架和思路都在这儿，你想怎么玩都有空间。