SpringBoot+Vue3+MyBatis实现应急物资管理系统实战总结

SpringBoot Vue3 MyBatis MySQL 这套组合在中小型管理系统开发里基本是标准答案。最近我刚把一个常规应急物资管理系统从零到一完整做了一遍前后端分离、MySQL 存数据、MyBatis 做持久层需求覆盖物资档案、出入库、库存预警、应急调拨这几块。这篇文章就是这套系统的落地总结想照抄作业也好想避开我踩过的坑也好都可以直接往下看。写之前先说清楚一个判断这个项目真正难的从来不是“写代码”而是把业务规则想清楚。应急物资管理跟普通进销存最大的区别在于它要同时应对“日常领用”和“应急大批量调拨”两种模式库存的准确性直接决定关键时刻能不能调得出物资。所以我做这套系统的第一件事不是建工程而是把流程和表结构梳理明白。1. 应急物资管理系统的业务痛点与模块拆解1.1 为什么需要一套“常规”应急物资管理系统我特意强调“常规”两个字不是随便写的。市面上很多系统叫“应急物资管理”实际套了一层大额采购和防灾调度的壳把简单台账搞得很重。但真实的仓库场景往往是这样区县或园区一级的物资仓库日常要管帐篷、棉被、口罩、消毒液、照明设备、简易医疗包甚至还有方便面、矿泉水这类生活物资。SKU 通常几百到几千个人也不多往往就是两三个仓库管理员加一个审批负责人。在这种规模下管理难点反而不是大数据量而是这些老问题账实不符。采购入库、应急领用、盘盈盘亏全都靠 Excel时间一长版本乱飞库里到底有多少物资没人说得准。效期没人盯。口罩、药品、饮用水都有保质期放久了过期关键时刻发出去反而出问题。领用审批靠口头。一个领导打电话说“先拿 50 箱水”事后补单库存怎么都对不上账。应急时要快速汇总。“某某物资还有多少、在哪个仓、哪个批次先到期”手工翻表格根本来不及。所以这套系统必须做到四件事第一每一种物资有唯一档案第二每一笔库存变动有据可查第三过期和低库存能主动提醒第四应急调拨时能快速生成出库单并扣减库存。后面所有模块设计都是围绕这四件事展开的。1.2 核心业务模块与角色权限划分我把整个系统拆成六个模块系统管理用户、角色、菜单、操作日志。这部分用很常规的 RBAC 思路——角色跟菜单做多对多。物资档案管理物资分类树、物资基本信息、计量单位、供应商维护。入库管理采购入库、调拨入库、捐赠入库、期初入库。每种入库类型单独配置单号前缀方便对账。出库管理应急领用出库、日常领用出库、调拨出库、报废出库。库存管理实时库存查询、库存流水、批次效期管理、库存预警。统计报表出入库明细、月度出入库汇总、物资库存台账导出。角色权限我简单分了四类角色主要权限说明系统管理员全部权限用户维护、数据字典、菜单权限仓库管理员出入库、库存、盘点日常库存操作的核心角色审批负责人出库审核、报表只读 审核不直接改库存普通用户物资查询、我的申请可提交领用申请但不能直接出库这里有一个容易忽略的点权限设计不能只卡“页面/按钮”还要卡“数据范围”。仓库管理员只能看自己仓库的库存审批负责人可以看全库存。我后来在查询模块全部加了warehouse_id条件避免出现“能看到但不应看到”的数据越权。1.3 核心业务流程梳理业务流程大致分两条线。日常线是“申请—审批—出库”领用人提交申请单 → 选择物资和数量 → 审批人在线审核 → 审核通过后自动生成出库单 → 仓库管理员确认出库 → 库存扣减、流水落库。应急线是“事件—需求—出库”登记应急事件 → 按事件选择关联物资并填需求数量 → 系统自动检查可用库存 → 判断库存是否充足 → 生成出库单 → 仓库拣货出库 → 库存回填、需求完成状态更新。应急线的关键点在于“先检查后扣减”。因为应急批量出库往往一次涉及几十种物资如果挨个扣库存可能出现前几种扣了、后几种库存不够最后单子只能作废但库存已经扣掉了。我的做法是先生成一张“预占单”把所需物资在预占表里先锁定等出库确认时再统一扣减真实库存。这个设计虽然多了一张表和几个状态但避免了很尴尬的“半成功”状态。2. 技术选型的取舍逻辑为什么是SpringBootVue3MyBatis2.1 后端框架选择的实际考量后端我直接用的 SpringBoot没有上微服务那套 Spring Cloud。理由很简单这类系统就一个应用拆成多个服务纯属给自己找事引入注册中心、配置中心、网关之后光解决依赖问题和部署问题就能多花两三天。SpringBoot 的自动配置在这个规模下已经非常够用内嵌 Tomcat