Spring Boot应急物资管理系统开发实战：库存批次与预警机制设计

1. 项目概述与需求拆解

1.1 应急物资管理系统到底要解决什么问题

如果你接了一个“基于Spring Boot的应急物资管理系统”的毕业设计课题，或者在工作中被要求做类似的模块，先别急着写代码，把需求吃透比什么都重要。

这个系统的核心管理对象就是应急物资。什么是应急物资？简单说就是应急救援场景下需要调拨、分发、储备的那批东西：帐篷、折叠床、棉被、口罩、消毒液、应急照明灯、发电机、方便食品、饮用水等。这类物资的特点是：平时存储在仓库里不常动，一旦发生突发事件，需要快速出库、快速调拨、按区域按优先级分发。所以这个系统不能简单做成一个普通的进销存，它需要围绕“应急”两个字做文章。

从用户的角色来看，系统涉及的人员大致有这么几类：系统管理员、仓库管理员、应急指挥人员、普通录入人员。日常工作中，管理员需要维护物资的基础信息，比如物资名称、分类、规格、计量单位、存储条件、保质期要求；仓库管理员负责执行入库、出库、盘点操作，确保账实相符；应急指挥人员关注的是各地的物资储备情况、库存上下限预警、物资分布统计，以便在关键时刻做出调度决策。

如果只看这个标题，很多同学容易把项目做窄，做成一个“增删改查”的简单CRUD系统。我见过不少失败案例，问题都出在同一个地方：表建得太简单，根本没有把应急物资的真实业务约束设计进去。

1.2 为什么选Spring Boot这套技术栈

先聊技术选型。做毕业设计，Spring Boot几乎是目前最合理的选择。理由很简单：生态成熟、上手门槛低、资料多、招人单位认。

Spring Boot相比传统的SSH（Spring + Struts + Hibernate）或者SSM（Spring + Spring MVC + MyBatis）组合，最大的优势在于自动化配置，省掉了大量XML配置的繁琐工作。你用IDEA新建一个Spring Initializr项目，勾选Web、MyBatis、MySQL驱动这几个依赖，一个可运行的项目骨架就出来了。对于毕设这种周期短、要求快速出成果的场景，这套方案稳。

数据持久层方面，我推荐用MyBatis-Plus而不是纯MyBatis，更不要用Spring Data JPA。为什么？MyBatis-Plus提供内置的BaseMapper，单表CRUD不需要自己写SQL，省时间。应急物资系统的复杂查询主要是多表关联、条件筛选、统计汇总，MyBatis-Plus的Wrapper条件构造器写起来非常顺手，分页插件也内置了，适合C端快速开发。

前端的话，两种路线都可以。一种是用Thymeleaf模板引擎，直接在服务端渲染HTML，适合追求简单、不想多写前端代码的同学；另一种是前后端分离，用Vue + Element Plus做一个管理后台，视觉效果好，但是工作量会大不少。我个人的建议是，如果你的毕设时间还有两个月以上，可以上Vue + Element Plus，整体观感会高一个档次；如果时间紧，Thymeleaf + Bootstrap也完全够用，照样能讲清楚业务流程。

提示：毕设答辩最看重的是“业务逻辑是否完整、需求分析是否清晰、数据库设计是否合理、代码能否跑通”。技术栈只要主流且你能讲明白原理，加分点就够了。

2. 数据库设计：系统地基，踩坑重灾区

2.1 物资表按批次设计还是按品类设计

这是整个系统最关键的建模决策，直接决定后续功能的复杂度。

如果你的物资表只有一张表，字段大概是“物资编号、名称、分类、数量、单位、存放位置”，那就麻烦了。你去翻实际业务会发现，同一批物资可能因为采购时间不同、生产批次不同、有效期不同，在库存管理上是不能简单合并的。比如口罩，一批是今年3月采购的，一批是去年12月采购的，保质期不一样，出库时必须遵循先进先出原则，优先把临近过期的先发出去。如果只按物资名称维度记录一个总数量，这个逻辑完全无法实现。

正确的设计是引入批次的概念。核心做法是：物资基础信息表保存不变的属性，比如ID、名称、分类、规格、单位；而具体的每一条库存记录，对应到某一个批次，这个批次关联到入库单，保存入库时间、生产日期、有效期、当前库存数量和存放库位。

这样做的另外一个好处是方便追溯。哪天出了一批有问题的物资，你能通过出库单追溯到库存批次，再通过批次追溯到入库单，就能知道这批货是什么时候进来的、经手人是谁、供应商是哪家。应急物资管理对溯源是有隐性要求的，这一点在答辩时讲出来，很加分。

2.2 核心表结构一览

下面把系统的主要表列出来，不需要完全照抄，但思路可以参考。

这个设计的核心逻辑是：库存批次表（stock_record）是物资数量和状态的唯一真源，入库单、出库单都通过明细表和它建立关联，而不是直接去改物资基础表里的某个数量字段。

2.3 为什么要有独立的库存批次表而不是直接在物资表加减库存

很多新手在写进销存业务时，喜欢在material_info表里放一个quantity字段，入库就加、出库就减。这个做法在小数据量下看着没问题，但细想就会发现很多麻烦。

第一，物资数量是可变的，把它和基础信息放在同一个表里，每次加减库存都要update这一行，在高并发下容易产生行锁竞争。第二，如果物资包含多个批次，一个material_id对应一条库存数量，你根本没法区分批次。第三，做库存流水追溯时，你只知道一个总数，不知道这批货哪个批次还剩多少，过期预警更没法实现。

独立出stock_record之后，库存状态一目了然：一条记录就是一个批次，available_quantity就是当前可用的数量。入库时新增记录，出库时从对应的库存批次里扣减和锁定数量。

而且表结构维护起来也方便，比如将来要扩展“质检状态”“冻结数量”这些业务字段，只需要在stock_record表上加字段，不需要去动业务核心表，风险小很多。

3. 核心业务功能与实现逻辑

3.1 入库流程：批次、效期与质检状态

入库流程是应急物资管理系统的“入口”，设计得好不好，直接影响后面所有的库存和预警逻辑。

合理流程应该是这样：仓库管理员根据采购单或捐赠清单填写入库单，选择物资、填写数量、生产日期、有效期，系统自动生成批次号。提交后入库单状态为“待审核”，审核通过后，系统执行真正的库存增加操作。

这里有一个细节值得注意：入库操作时，不要只写一条stock_record，还应该同步记录入库流水。流水表的意义在于审计追踪，任何数量的变化都有据可查。后续做报表、做对账，都是靠流水而不是靠快照。

批号生成策略我建议用规则编码，比如：入库日期 + 顺序号，形如“R20250615001”。这样即使不查表，看一眼批号也能知道大概是什么时候入库的。有效期字段必须存，因为后面还要做效期预警，往期有同学直接忽略了有效期，导致预警功能根本无法实现，只能在答辩前临时改表，非常被动。

3.2 出库流程：申请、审批与库存扣减

出库流程比入库要复杂一点，因为它牵扯到申请、审批、库存锁定、扣减这几个动作。

出库单的初始状态应该是“待审批”，审批通过后变成“待出库”，出库完成后变成“已完成”。为了保证库存不超卖，审批通过的那一刻就应该尝试预占用库存。具体操作是：在生成出库明细时，按照先进先出的原则找到对应批次的可用库存，如果某个批次库存不够，自动继续找下一个批次。全部出库数量都能满足，才允许提交；否则提示库存不足。

预占库存的实现方式比较常规，可以在stock_record表增加一个locked_quantity字段，审批时把库存做成“扣减预占”而不是“直接扣减”。出库完成后，再把实际扣减数量和锁定数量对准，把available_quantity减掉、locked_quantity清零。如果审批被驳回，则把locked_quantity释放回available_quantity，避免库存被白白占用。

3.3 预警机制：库存上下限与效期预警

应急物资系统相比普通进销存，更看重预警。因为应急物资平时沉在仓库，如果管理不当，真的到了灾时才发现库存不足或者物资过期，那就晚点了。

预警功能做起来并不复杂，核心是两类任务：

• 库存数量预警：某个物资的实时库存低于最低储备量或者高于最高储备量，生成预警记录。
• 效期预警：某个批次距离过期时间小于N天（比如30天），生成预警记录。

实现方式有两种：一种是查询时即时计算，用户点击预警页面时，后台执行扫描逻辑，把当前满足预警条件的数据查出来；另一种是定时任务扫表，通过Spring Scheduled每隔一段时间自动检查一次，把结果写入warning_record表。我建议两种结合：列表页实时计算展示最新状态，定时任务负责记录历史预警痕迹，方便答辩时展示“预警历史记录”模块。

定时任务的写法不复杂，在启动类加上@EnableScheduling，再写一个@Service类，方法上用@Scheduled(cron = "0 0 2 * * ?")，表示每天凌晨2点执行一次即可。

3.4 统计报表：辅助决策的数据价值

应急物资系统里的报表，常见的就几张：库存总览表、各分类占比图、出入库趋势图、物资分布表。统计报表的意义不只是“好看”，而是为应急指挥提供决策依据，比如“现在A区域帐篷还剩多少，B区域是否需要紧急调拨”。

技术实现上，统计SQL一般用GROUP BY结合聚合函数。例如统计各分类物资的库存总量：

SELECT c.category_name, SUM(s.available_quantity) AS total_quantity FROM stock_record s LEFT JOIN material_info m ON s.material_id = m.id LEFT JOIN material_category c ON m.category_id = c.id WHERE s.available_quantity > 0 GROUP BY c.category_name

注意点在于，如果前端用的是ECharts这类图表库，后端接口返回的数据结构应尽量贴合前端需要的结构，可以直接返回name和value两个字段的数组，减少前端二次加工的麻烦。

4. 关键代码实操与过程记录

4.1 建表SQL片段关键部分

先给出一段建表SQL的核心片段，大家在建库时可以参考其中的字段定义和注释规范。开发一个系统，表的字段注释一定要写清楚，否则一个月之后自己都忘了某个字段是什么意思。

CREATE TABLE `stock_record` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `material_id` bigint NOT NULL COMMENT '物资ID', `batch_no` varchar(64) NOT NULL COMMENT '批次号', `quantity` int NOT NULL DEFAULT 0 COMMENT '原始入库数量', `available_quantity` int NOT NULL DEFAULT 0 COMMENT '当前可用数量', `locked_quantity` int NOT NULL DEFAULT 0 COMMENT '锁定数量', `production_date` date DEFAULT NULL COMMENT '生产日期', `expiry_date` date DEFAULT NULL COMMENT '有效期至', `location_id` bigint DEFAULT NULL COMMENT '库位ID', `inbound_time` datetime NOT NULL COMMENT '入库时间', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_material` (`material_id`), KEY `idx_batch` (`batch_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存批次表';

你看我加了available_quantity和locked_quantity两个字段，而不是只留一个quantity，这是为了支持出库审批时的预占库存逻辑。

另外一个建议：amount类型的字段统一用int或者bigint，不要用double，因为浮点运算在涉及价格统计时容易产生精度问题；如果必须存价格，用decimal(10,2)。

4.2 Service层事务与并发控制写法

核心业务代码集中在入库、出库、盘点这三个Service方法中。这里给出出库入库的典型代码逻辑，重点在于事务的边界。

以出库为例，完整流程是：更新出库单状态 -> 遍历出库明细 -> 尝试锁定库存批次。这个流程必须放在同一个事务里，否则可能出现“单据状态更新成功，但库存没锁住”的中间态，一旦操作失败回滚不完整，数据就乱了。

@Override @Transactional(rollbackFor = Exception.class) public boolean submitOutbound(OutboundOrder order, List<OutboundItem> items) { // 1. 保存出库单，状态为待审批 order.setStatus(OrderStatus.PENDING_APPROVAL.getCode()); order.setOrderNo(generateOrderNo("C")); outboundOrderMapper.insert(order); // 2. 遍历明细，校验库存并尝试预占 for (OutboundItem item : items) { List<StockRecord> stockRecords = stockRecordMapper .findAvailableByMaterialId(item.getMaterialId()); int need = item.getQuantity(); for (StockRecord sr : stockRecords) { if (need <= 0) break; int available = sr.getAvailableQuantity() - sr.getLockedQuantity(); if (available <= 0) continue; int lockNum = Math.min(available, need); stockRecordMapper.lockStock(sr.getId(), lockNum); need -= lockNum; } if (need > 0) { throw new BusinessException("物资库存不足: " + item.getMaterialId()); } } // 3. 保存明细 items.forEach(outboundItemMapper::insert); return true; }

注意方法上使用了@Transactional(rollbackFor = Exception.class)，而不是默认只回滚RuntimeException。因为在自定义业务校验时经常抛的是自定义的BusinessException，如果不指定rollbackFor，事务不会触发回滚，这会导致出库单已经插入但库存预占失败却一直留存的情况。

4.3 登录认证与权限控制

配套的登录认证使用JWT令牌。很多人觉得毕业设计用JWT是“过度设计”，其实不然，现在的管理系统如果还靠Session，面试官会质疑你的知识结构。

这里给出一个简化的登录接口核心逻辑：

@Service public class UserServiceImpl implements UserService { @Autowired private UserMapper userMapper; @Autowired private JwtUtil jwtUtil; @Override public String login(String username, String password) { // 1. 根据用户名查询用户 LambdaQueryWrapper<SysUser> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(SysUser::getUsername, username); SysUser user = userMapper.selectOne(wrapper); if (user == null) { throw new BusinessException("用户名或密码错误"); } // 2. 校验密码（注意实际项目中密码要使用BCrypt加密存储） if (!BCrypt.checkpw(password, user.getPassword())) { throw new BusinessException("用户名或密码错误"); } // 3. 校验状态 if (user.getStatus() == 0) { throw new BusinessException("账号已被禁用"); } // 4. 生成JWT令牌（可以把用户ID和角色身份放进去） return jwtUtil.generateToken(user.getId(), user.getRoleCode()); } }

密码加密这里需要特别强调一下。很多同学图省事，把密码明文存数据库，这个在期末答辩可能不会被当场指出，但将来如果作品被拿走做二次开发或者面试被问，一定会被扣印象分。推荐使用Spring Security Crypto模块引入的BCryptPasswordEncoder。使用方式很简单：

String encoded = new BCryptPasswordEncoder().encode(rawPassword);

加一个JWT拦截器，配合Spring拦截器注册机制，把需要登录的接口保护起来，用户没带Token访问，直接返回401，整体逻辑就闭环了。

5. 高频问题与排查实录

5.1 并发扣减库存超卖问题

这是我在多个项目里都看到过的典型问题，也适合在毕设答辩时当亮点讲。

如果扣库存这条SQL语句写的是：

UPDATE stock_record SET available_quantity = available_quantity - #{num} WHERE id = #{id}

在高并发场景下，两个请求同时读到可用数量为10，然后各自执行减5，最后可能两个都成功，但实际库存只剩5，超卖了。

解决方式有两种。第一种是利用数据库的行锁，把SQL改为条件更新：

UPDATE stock_record SET available_quantity = available_quantity - #{num} WHERE id = #{id} AND available_quantity >= #{num}

这样只有库存真正足够时才更新成功，否则影响行数为0，业务上再根据影响行数判断是否扣减成功。第二种做法是使用悲观锁或乐观锁，但实现会更复杂，对于毕设系统，第一种条件更新的方式已经足够稳妥，实操中我也一直推荐优先采用这种方案。

5.2 @Transactional 失效的三类场景

我自己踩过无数次坑，在这里集中说一下事务失效最常见的三个原因。

第一，同类内直接调用。在一个Service里，A方法调用同类B方法，并且B方法上有@Transactional，此时事务不会生效。原因在于Spring的事务是基于AOP代理实现的，同类调用不会经过代理对象。解决办法是拆分成两个独立的Bean，或者在类上注入自身代理。

第二，方法用private修饰。事务注解加在private方法上是无效的，因为代理机制无法为私有方法生成增强。这也解释了为什么事务方法一定要保证是public。

第三，数据库引擎不支持事务。如果某张表的引擎是MyISAM，那么就算代码写法都对，事务也不会生效。建表时一般使用默认的InnoDB引擎，问题不大，但如果是复制过来的旧库脚本就容易被忽略，需要检查一下。

5.3 前端联调阶段的跨域与时间格式坑

联调时最容易出问题的是两个地方，跨域和时间格式。

跨域解决方式很简单，最常见的做法是后端加一个全局CORS配置：

@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); } }

另外，在使用前后端分离的时候，后端的返回值格式要统一设计。我一般定义一个统一的Result类，带code、message、data三个字段。成功时code为200，失败时code为400或500。这样前端拦截器只用判断一个字段，不至于处处做异常判断。

时间格式方面，Java后端默认序列化出来的LocalDateTime前面会带T，比如“2025-06-15T10:30:00”，前端接受不了这个格式。解决方案是在application.yml里配置：

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

配置完之后前端接收到的就是正常的“2025-06-15 10:30:00”格式了。

6. 经验之谈与后续扩展方向

说实话，应急物资管理系统这个题目在毕业设计里不算难，真正难的是把每个环节的细节想明白。我前前后后带过好几个做类似题目的学生，发现做得好的同学都有一个特点，他们会先去模拟真实的业务场景，把自己代入仓库管理员的角色走一遍流程，从“计划申报”到“物资入库”再到“应急调拨”再到“盘点报废”，每一步都问自己“这一步想在系统里怎么体现”。带着这些问题去建表、写代码，做出来的系统就有灵魂，而不是一个空壳的CRUD。

还有一个细节想多说一句：系统中预留的扩展点其实不少，比如捐赠物资管理、疫情专项储备、跨区域调拨审批流，都是可以和老师沟通后延伸的方向。如果答辩时能说出“当前系统已预留了哪些扩展能力，将来可以怎么演进”，整个项目的完成度评价会明显上一个台阶。

如果时间允许，我建议后续把移动端扫码盘点这个功能做掉。现在仓库盘点还靠纸笔记录再回电脑录入，效率低且容易出错。给库存批次生成一个二维码，盘点时手机扫码直接确认数量，这个场景在应急物资管理中非常真实。哪怕只是做一个演示版，也能让答辩评委眼前一亮。