基于SpringBootVue学校物资采购系统的设计与实现毕业设计年年有但是真正能把一个学校物资采购系统做清楚、做透的其实不多。很多人一听到“学校物资采购系统”下意识就认为这不过是“商品下单加一个后台管理”但实际上学校采购和普通电商采购是两码事。它带有非常鲜明的组织属性预算约束、多级审批、审计追踪、库存联动。这篇文章就围绕我在一个模拟项目X中从零搭建的这套基于SpringBootVue的前后端分离采购系统把需求拆解、表设计、核心流程、状态机处理以及实际操作里踩过的坑完整分享一下。不管是准备做类似课题的学生还是想在公司内部搭建一套轻量采购工具的开发人员这篇内容都会有参考价值。1. 先把业务想清楚学校采购到底在采什么、卡在哪做系统最怕什么最怕一上来就写代码。你连业务本身都没有建模清楚写出来的系统只能是“看起来功能齐全用起来处处别扭”。所以第一步先把学校物资采购这件事本身拆透。1.1 学校采购的特殊性这不是网购普通电商系统用户选商品、下单、付款流程就结束了。但学校采购系统有完全不同的业务结构采购主体不是个人而是部门或者课题组。也就是说物资的需求方是组织不是某个自然人。采购资金来自预算。不管是财政拨款还是自筹资金每一笔采购都必须在预算范围内超预算的申请系统是不能放行的。审批链长。一般学校内采购要经过申请人 → 部门负责人 → 采购管理部门 → 分管领导甚至大额采购还要上会。每一级都可能驳回驳回后要能重新修改再次提交。审计要求高。每一笔支出都要能回溯谁申请的、谁审批的、向哪家供应商买的、验收人是谁、入到哪个仓库。这个链条是强审计链条一旦断掉系统就是失职。采购与库存强相关。很多物资是重复性采购比如办公耗材、实验器材。如果不和库存联动就会出现“仓库里堆着100盒粉笔采购单上又批了50盒”的荒唐事。所以这套系统的核心关键词不是“下单”而是“流程、预算、留痕、联动”。1.2 角色与权限一个动作都不能越权基于这个业务模型我设计了六类角色角色权限范围典型操作普通教职工在线填写采购申请查看自己的申请进度新增申请、撤回未审批的申请、查看历史记录部门审批人审批本部门下属提交的采购申请通过、驳回、退回修改采购管理员汇总已审批的申请执行采购生成采购单、录入供应商报价、确认采购结果仓库管理员物资到货后验收、入库、出库创建入库单、领用登记、库存查询财务管理员预算管理、采购金额核对调整预算、查看采购支出明细、结算确认系统管理员基础数据维护、用户管理、日志审计用户开户、物资分类维护、供应商管理、系统参数配置这里权限模型的背后需要一套完整的RBAC基于角色的访问控制权限体系。前端用路由守卫控制菜单和按钮的可见性后端用拦截器加权限注解双保险。我见过不少项目只做了前端权限后端接口裸奔这是要出事的。别人只要知道你的接口地址就能越权操作审计一查一个准。1.3 核心流程梳理一条主线贯穿系统这套系统的业务主线可以归纳为七个状态节点申请填报 → 部门审批 → 采购审批 → 采购执行 → 到货验收 → 入库登记 → 领用出库这条链路上的每一个节点都必须有明确的状态标识、操作人、时间戳和操作记录。我最初在设计时把这些状态直接做成了订单里的一个字段后来发现太天真了——因为你要同时记录“当前状态”和“历史轨迹”还要支持“驳回后回到上一状态并允许修改”。所以最后采用了状态机 流水表的设计主表存当前状态流水表存每一次状态变更。这样无论审计查什么都能一键还原当时的完整轨迹。2. 技术选型为什么是SpringBoot Vue而不是别的技术选型这个东西没有绝对的最好只有是不是匹配项目的规模和团队的习惯。我选SpringBoot Vue不是因为它高级而是因为它“恰好合适”。2.1 后端选SpringBoot的理由很实在先说结论对于这种典型的“企业级单体内应用 业务逻辑复杂 需要稳定生态”的系统SpringBoot是目前性价比最高的选择之一——尤其是当你的业务里有审批流、时间状态流转、复杂的数据库表关系时SpringBoot能让你把主要精力放在业务代码上而不是花时间搭各种基础框架。约定优于配置不用再像用传统Spring那样写大量XML配置文件。一个启动类几条注解一个内嵌的Tomcat应用就能跑起来。生态成熟到可怕做权限有Spring Security / Shiro做数据访问有Spring Data JPA / MyBatis / MyBatis-Plus做接口文档有Swagger做参数校验有Hibernate Validator。几乎你想得到的业务组件都有现成的整合方案。和前端分离架构非常顺RestController直接返回JSON天然就是为前后端分离设计的。部署简单mvn package打一个可执行jar包丢到服务器上 java -jar 就能运行。当然它也有缺点比如胶水代码比较多、启动比Go和Node系要重但在这个体量的项目上这些缺点根本不构成瓶颈。2.2 前端为什么用Vue而不是React如果单纯说技术栈的“热度”React在国内外也很有市场但Vue在国内中小型管理系统里一直是统治级的存在原因是三个字够简单。上手门槛低模板语法和HTML非常贴近一个后端开发转来做前端花半天看一遍Vue的基本指令就能开始干活。React的JSX心智模型和函数式组件思想对不常做前端的开发者来说更陡峭。生态精准对位中后台配合Element UI或者Element Plus表格、表单、弹窗、分页、树形控件基本是开箱即用。你会发现做一个管理后台界面90%的时间不是在写样式而是在配置组件的属性效率极高。组合式API越来越舒服Vue 3的composition API配合setup语法糖让逻辑复用变得干净。我可以把审批相关的逻辑独立抽成一个组合式函数多个页面复用不用再写一堆mixins。我这里采用的是Vue 2 Element UI的方案。为什么不用Vue 3因为在模拟项目X启动的时候电子表格组件和部分第三方库对Vue 3的兼容还不够稳定为了减少踩坑稳定压倒一切。如果你现在从头做建议直接Vue 3 Element Plus新项目的长期维护性更好。2.3 数据库与持久层MySQL MyBatis-Plus数据库选MySQL没有悬念业务复杂度用不到PostgreSQL的王者级功能MySQL在中小型项目上的表现足够稳。持久层我选了MyBatis-Plus它是在MyBatis基础上的增强工具最实用的三个能力代码生成器根据表结构自动生成实体类、Mapper接口、Service省掉大量重复劳动。条件构造器QueryWrapper和LambdaQueryWrapper写复杂查询条件比拼接SQL舒服得多还能避免字符串硬编码导致的维护地狱。分页插件配置一个拦截器分页查询变成一行代码。当然Project里有一个需要特别留神的地方不要在Service里写上千行的业务逻辑。MyBatis-Plus只是帮你简化了数据访问业务逻辑该拆分还是要拆分的。我在这个项目里把业务层按模块拆分得更细采购申请一个Service审批流程单独抽出一个策略服务库存操作用独立的事务服务这样每一层只干一件事后续加需求不头疼。3. 数据库设计一张好表胜过十次重构把这个系统的表结构放到整个博文里单独说是因为数据模型直接决定了这个系统能走多远。如果表设计不对后面每个功能都是一次次挣扎。3.1 核心表清单与设计逻辑系统的主要数据表包括表名用途sys_user用户表存账号、密码BCrypt加密、姓名、所属部门ID、角色IDsys_role / sys_menu / sys_role_menuRBAC权限三件套biz_material_category物资分类表树形结构比如办公用品 → 笔类 --biz_supplier供应商表含联系方式、资质信息、历史报价关联biz_purchase_apply采购申请表主表biz_purchase_apply_item采购申请明细表一个申请对应多个物资条目biz_purchase_order采购单审批通过后由采购管理员生成biz_purchase_order_item采购单明细记录实际采购价和数量biz_stock库存表按物资ID 仓库ID维度存剩余量biz_stock_record出入库流水表每次库存变动都要留痕biz_budget预算表按年度 部门维度记录预算总额与已用金额biz_approval_record审批记录表记录每一步审批的意见和结果这里我最想强调两个容易被忽视的设计点第一个是采购申请的主表和明细表一定要分开。不能图省事把多个物资塞进一个字段哪怕你用的是JSON串也不行。因为后面的统计报表、预算核销、验收入库全部需要按物资明细粒度去操作和聚合。第二个是库存表和流水表必须同时存在。库存表是当前快照流水表是历史变更。只有快照没有流水出了问题无法追溯只有流水没有快照每次查询库存都要临时聚合效率堪忧。两张表互为补充才是正确姿势。3.2 预算控制的数据结构设计预算控制是这个系统里最容易做烂的一个模块因为预算不只是一个“数字字段”它有一系列要求控制总额、记录已用、支持追加调整、在申请提交时做校验。我的设计方案是biz_budget表包含以下关键字段budget_year预算年度比如2025统计和核销都按年度走。department_id部门ID预算的下钻维度到部门。total_amount部门年度总预算DECIMAL(12,2)。used_amount已用金额每次采购申请审批通过时累加驳回/取消时回退。frozen_amount冻结金额待审批的申请占用的预算。这里有用意申请提交后虽然在审批中但金额要先行占用防止同一笔预算被多笔申请重复透支。为什么要搞“占用”这一层是因为实际场景里经常出现“两笔申请同时提交单看都低于剩余预算但加起来超了”的问题。冻结机制就是提前把意向占住剩下的预算校验才有意义。3.3 审批记录表系统留痕的关键审批记录表是审计追踪的重中之重。我设计的数据结构里包含apply_id关联采购申请ID。approver_id审批人ID。approval_action通过 / 驳回 / 退回修改。approval_comment审批意见必填字段。这里从流程上强制审批人留痕避免有流程无意见。create_time操作时间。实践中这个表还承担了一个特殊任务当审批被驳回时系统需要知道“当前节点退回到哪一级”这个信息也记录在审批记录里方便前端快速定位下一个需要处理的人。4. 核心功能模块的设计与实现业务清楚了表结构也设计好了接下来才是“真正写代码”的环节。我把这套系统的实现拆分成几个重模块每一个模块都拎出来说说实现思路和注意点。4.1 多级审批流程状态机是核心不是流程引擎先说结论这套系统的审批流我用的不是Activiti或者Flowable这种重量级流程引擎而是基于状态机手写了一套轻量审批流。为什么不用流程引擎原因是学校的采购审批流程相对固定节点数量少3~5级没有复杂的会签、条件分支、动态路由需求。为一个固定流程引入一套流程引擎要额外学习它的概念体系流程定义、部署ID、任务候选人、监听器等部署和运维成本都上来了得不偿失。我的状态机设计是这样的DRAFT(草稿) --提交-- PENDING_DEPT(待部门审批) --部门通过-- PENDING_PURCHASE(待采购审批) --部门驳回-- REJECTED(已驳回) --重新提交-- PENDING_DEPT --采购通过-- PENDING_EXECUTION(待执行采购) --采购驳回-- REJECTED --采购管理员确认采购完成-- PENDING_ACCEPTANCE(待验收) --验收通过-- PENDING_STOCKING(待入库) --入库确认-- COMPLETED(已完成)这个状态机的核心逻辑在Service层用一个状态流转方法统一处理Transactional public void approveApply(Long applyId, Long approverId, String action, String comment) { PurchaseApply apply applyMapper.selectById(applyId); // 幂等校验防止重复审批 if (!checkCurrentNode(apply, approverId)) { throw new BizException(该申请不在您的待审批队列中); } // 根据当前状态 操作找到下一个状态 PurchaseApplyStatus nextStatus statusMachine.getNextStatus( apply.getStatus(), action ); // 审批通过时需要校验收款预算并占用/核销 if (nextStatus PurchaseApplyStatus.PENDING_EXECUTION) { budgetService.consumeBudget(apply); } apply.setStatus(nextStatus); applyMapper.updateById(apply); // 写审批流水 approvalRecordMapper.insert(new ApprovalRecord(applyId, approverId, action, comment)); }用状态机的最大好处是你可以把所有可能的非法操作拦截在设计阶段。比如一笔已经“已完成”的申请想把它从接口层面改回到“待审批”状态机里没有这个转移代码直接抛异常想走歪门邪道都不可能。4.2 预算控制的代码链路从申请到核销一次都不能漏预算模块的代码逻辑要覆盖四个环节提交申请时冻结预算。申请中的每一条明细都有一个预估金额提交申请时按预估金额累加入冻结额度。审批通过时核销预算。把冻结的金额转成已用金额。审批驳回/申请撤回时释放预算。把冻结金额扣回去。采购价格与申请价格不一致时做差额调整。实际采购金额比申请预估低时把多的已用金额退回比预估高时需要额外的预算补足校验不够就不能确认采购。这四步必须在事务内完成并且每一步都要记录预算操作流水。我当时在这个模块上写的测试是最多的因为预算一旦出错财务那边是要出大事的。这里有个细节值得提所有金额运算一律用BigDecimal禁止用double或者float。double在二进制下根本不是精确小数0.1 0.2 不等于 0.3 这种事情在金额计算里是灾难。数据库层面金额字段统一用 DECIMAL(12,2)JPA或MyBatis映射到BigDecimal这是我从一开始就定死的规矩。4.3 审批之后生成采购单价格的二次确认审批通过的申请不会自动变成“采购单”。在实际业务里采购管理员还需要汇总多个申请单合并向同一个供应商询价然后生成一份采购订单。所以我在这里加了一个“汇总生成采购单”的步骤public PurchaseOrder createOrder(ListLong applyItemIds, Long supplierId, ListOrderItemParam items) { PurchaseOrder order new PurchaseOrder(); order.setOrderNo(generateOrderNo()); // 采购单号如 PO20250601001 order.setSupplierId(supplierId); // 从申请明细中关联当前申请单号 order.setFromApplyIds(...); ... }采购单生成后状态是“待采购确认”。采购管理员确认价格无误状态推进到“采购中”。这里要允许采购人员维护实际采购价、实际数量因为申请时写的是预估真正和供应商谈完之后的价格可能是不一致的。4.4 到货验收与自动入库采购流程走完最容易被忽略的是存货联动机制。我把它设计为采购单状态改成“到货待验收”后仓库管理员进入“到货登记”页面。填写实收数量、检查物资外观和规格点击验收通过。允许部分验收也就是实收数量小于采购数量剩余部分可以后续补收。验收通过后自动生成入库单、自动增加库存、自动写入出入库流水。入库逻辑在一个事务里搞定Transactional public void acceptAndStock(StockInParam param) { // 1. 更新采购单状态 // 2. 创建入库单 // 3. 逐条增加库存 // 4. 逐条写库存流水 // 5. 如果有差异同步更新采购单明细的实际入库数量 }另外我还加了一个库存预警机制在物资分类表或者物资表里设置最低库存阈值一旦某物资库存量低于阈值系统就在首页dashboard上标红提醒采购管理员。虽然这个功能在技术上很简单一个定时统计SQL但使用反馈非常好采购员说这是他们每天打开系统第一眼要看的东西。4.5 报表统计让数据可视化采购系统除了解决流程管理还要回答管理层的问题这个月花了多少钱哪个部门买得最多哪类物资占比最高为此我实现了两个维度的统计接口按时间维度统计采购金额趋势近12个月。按部门维度统计采购金额排行Top10。按物资类别统计采购数量占比。后端提供聚合查询接口前端用ECharts渲染柱状图、折线图和饼图。这里的关键经验是报表查询不要直接在主业务表上做大型聚合建议在数据库中提前创建汇总表或者至少给时间字段和部门字段建好索引否则数据量上来之后查询会非常慢。5. 权限与安全细节一套系统能不能用先看权限稳不稳很多毕业设计做的系统权限部分就是“登录进去就完事”根本没有考虑逐接口鉴权、水平越权和敏感操作审计的问题。学校采购系统有审计要求所以这一块必须做得扎实。5.1 后端接口鉴权JWT 拦截器 注解用户登录成功后后端发一个JWT令牌前端存在localStorage里每次请求头部带Authorization字段。后端拦截器统一校验令牌是否存在、是否过期、用户是否被禁用。根据请求路径匹配需要的权限码。只有角色拥有该权限码时才能调用接口。代码大致这样public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和静态资源 if (checkWhitelist(request.getRequestURI())) return true; // 解析令牌 LoginUser loginUser jwtUtils.parseToken(request.getHeader(Authorization)); if (loginUser null) { response.setStatus(401); return false; } request.setAttribute(loginUser, loginUser); // 方法级权限校验 HandlerMethod hm (HandlerMethod) handler; RequiresPermission permission hm.getMethodAnnotation(RequiresPermission.class); if (permission ! null !userService.hasPermission(loginUser, permission.value())) { response.setStatus(403); return false; } return true; } }这个方案“轻”但足够用不需要引入Spring Security全家桶对只有几个角色的系统来说手写拦截器反而更容易掌控。5.2 越权防护你不能查别人的申请单有权限不代表没有越权风险。采购申请有一个非常常见的越权漏洞普通用户A如果知道申请的ID直接请求“查询申请详情”接口就能看到用户B的申请信息。我在所有查询接口上都强制加了数据归属校验普通用户只能查询自己提交的申请。部门审批人只能查询本部门的申请。采购管理员可以查询所有已经审批通过的申请但不能随意修改别人的草稿。这层校验写在Service层而不是前端前端可以骗后端不能骗。实际开发时我建议把这条作为一个代码评审的固定检查项凡是按ID查询的接口都要问一句“当前登录人是否有权查看这条数据”。5.3 密码安全不允许明文用户密码存储我使用的是BCrypt加密。它不是简单的Hash而是带随机盐、可调节计算强度的算法。哪怕两个用户的密码相同加密后的字符串也是不一样的这就杜绝了通过密文反推密码规律的可能。6. 从开发到部署我踩过的那些坑以及排查实录这部分是最有实战价值的因为几乎每一个坑都是“上网查不到、文档没写、服务器还等着上线”的那种。6.1 坑一时间字段的前后端时区错乱前端传了一个“2025-06-01 08:00:00”后端接到的却变成了“2025-06-01 00:00:00”或者Json序列化后返回给前端的是“20250601T000000Z”这种格式前端Date对象解析完又差了8小时。这是前后端分离项目几乎必踩的坑。我最后的解决方案是“三管齐下”数据库中统一用 datetime 类型存储按服务器时区写入。后端实体类上对日期字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)强制序列化格式和时区。前端封装 axios 拦截器对请求参数和响应数据统一做好格式化。6.2 坑二JWT过期了前端还在傻傻地发请求JWT设计为“无状态”后端无法主动把某个令牌踢下线那过期之后就麻烦用户点击某功能发现自己“登录已过期”但跳转登录页之前那个失败的请求已经被抛出去了前端路由守卫没有感知到401错误。处理办法是在axios响应拦截器里统一加401判断service.interceptors.response.use( (response) response, (error) { if (error.response error.response.status 401) { // 清除本地登录信息跳转到登录页 store.dispatch(logout); router.push(/login); } return Promise.reject(error); } );这个处理让所有未经登录的请求不管是什么业务都会回到登录页逻辑统一且不会漏。6.3 坑三审批接口被人用脚本重复刷审批操作不是幂等的用户可能双击了“通过”按钮或者有人用脚本模拟重复提交审批请求如果后端没有做防重那么一笔申请可能会被审批两次状态被推进两次甚至更多造成数据错乱。我用了两种手段防重数据库层面在审批记录表增加一个唯一索引 (apply_id, approver_id, target_status)同一申请同一审批人针对同一目标状态的审批记录只允许一条数据库层面就拦住硬重复。代码层面在状态机流转前加一个版本号字段version执行update语句时用UPDATE ... SET version version1 WHERE id ? AND version oldVersion如果影响行数是0说明数据已被修改过抛异常拒绝操作。这种“乐观锁版本号 唯一索引”的连环做法是我在实际运维中真正用过且有效的手段。6.4 坑四模糊查询导致数据库全表扫描在“申请单号模糊查询”和“物资名称模糊查询”这两个高频接口上刚开始直接用了LIKE %关键字%查询速度在数据量上来后肉眼可见地变慢。解决办法必须模糊查询的字段加上全文索引或者用内嵌的ElasticSearch但这个项目用不上太重。更常见的做法是加约束条件如时间范围必选强制用户在搜索时限制最近三个月内的数据这样SQL能有效利用时间索引缩小扫描范围。分页查询必须加Redis缓存但对这个量级的系统先通过让用户选时间范围来换取性能是成本最低的优化。6.5 部署与配置本地能跑不代表服务器能跑本地开发环境和服务器环境不一致是部署阶段最常见的麻烦。我们遇到过这些差异本地连的MySQL是8.0服务器是5.7SQL语法有一些不兼容。解决方法是统一两边版本并外置配置文件。前端静态资源打包后访问接口用的是相对路径导致Nginx转发时404。需要在Vue的axios baseURL上明确配置/api然后Nginx把/api反向代理到后端服务。服务器内存只有2G跑一个MySQL加一个SpringBoot应用差点OOM。解决办法是给JVM设置合适的启动参数-Xms256m -Xmx512m并对MySQL调低缓冲池大小。这些问题的排查靠的是耐心。我的习惯是先看日志再复现最后才动手改。SpringBoot的logback日志一定要配置好输出文件的滚动策略不然日志文件会把磁盘塞满。7. 关于测试和上线前的自我检查很多人在毕业设计或者小项目里不写测试理由是“时间紧、没必要”。但在我这个项目上测试帮我挡下了至少三个本来要上线才暴露的严重Bug。所以我还是想专门说说这一块。7.1 接口测试不能省Postman 集成测试双管齐下接口测试我用的是Postman核心是把所有接口的请求样例保存到一个Collection里并且把登录接口的token设成一个环境变量后续接口自动带上。这样每次改完后端代码我都可以跑一遍Collection快速验证核心链路是否被改坏。同时对几个核心流程提交申请、审批通过、生成采购单、验收入库、预算核销编写了集成测试在测试环境数据库上跑一套完整的业务链路。这里有个心得集成测试的数据库必须和开发库隔离否则测试数据会污染真数据还可能把预算金额搞得乱七八糟。7.2 上线前的自检清单整理了一下我每次上线前必查的清单所有金额计算是否使用了BigDecimal有没有遗漏double类型。所有查询用户数据的接口是否都做了数据归属校验。MySQL的公共字段创建时间、更新时间是否统一维护。导出文件的接口是否限制了导出的数据量防止一次性查十几万条把内存打爆。系统部署后外网是否能访问到后端的Swagger文档如果不能记得在安全层面把Swagger在线文档关掉或者加权限。8. 这套系统后续还能怎么扩展开发完一版运行稳定之后有几个方向是明显的扩展升级路径8.1 引入外部审批通知渠道现在审批人需要主动登录系统才能看到待办。可以对接企业微信、钉钉群机器人或者邮件审批人收到消息提醒后点击链接跳转到系统处理页面。这个属于消息通知层面的增强接口设计好了其实不难。8.2 用缓存降低数据库压力系统运行一段时间后可以引入Redis把物资分类树、供应商列表、系统参数这些高频读、低频写的数据缓存起来读写性能有一个质的提升。对于当前业务体量来说Redis不是必须的但为扩展做准备没有坏处。8.3 流程可配置化如果担心未来的审批流程会复杂化比如同一个物资大类的采购要走不同的审批链路或者在某个金额节点额外增加一会上会审批那当前的状态机模式就不够用可以换成一个轻量的流程配置引擎让管理员在界面上配置节点和流转条件。这个升级的投入较大应该在有真实需求的时候再动手不要提前过度设计。8.4 对接财务系统与资产管理系统学校采购的终点往往不是“入库”而是“资产”。设备类的采购入库后还要同步到学校的资产管理系统生成资产编号、录入资产档案。如果你们学校已经有一套资产业务系统那采购系统的入库接口应该预留对外的消息推送或API对接出口。写在最后做完这套基于SpringBootVue的学校物资采购系统我最深的体会是写代码之前一定要先把业务状态流转、权限边界和预算口径想清楚。这些基础设计一旦搭错后面所有功能都会在同一个地方反复撞墙。数据表的关联关系、状态机的转移规则、审批记录的完整性才是这套系统真正的灵魂。另外这也是一个“开发三个月维护三年”的典型场景。系统上线后每天跑在它上面的是真实的数据、真实的钱、真实的责任。没有审计追踪功能没有幂等防重没有越权校验哪怕界面做得再花哨它也不是一个可以放心交付的系统。如果你也正在做类似的项目建议先从“一张完整的申请单从提交到归档的流程”入手画出状态图再开始建表和写代码。把这条主线打通了其他模块都只是顺着这条主线上长出来的枝叶。