最近在带学生做毕业设计，好几个选了这个方向，核心标的都是“基于JAVA的卷烟厂库存管理系统”，或者换个说法叫“基于Spring Boot的卷烟厂原料与成品库存精细化管控平台”。从题目看，这就是典型的企业级Web系统开发，技术栈锁定Java + Spring Boot，业务场景落在烟草行业的原料和成品库存管理上。
说实话，这个题目选得挺聪明的。一方面Spring Boot是目前Java后端开发的事实标准，学了能用；另一方面烟草行业的库存管理比普通超市进销存要复杂得多——烟叶原料要按等级、年份、醇化期管理，成品烟要按牌号、批次、件烟条码追踪，还要考虑片烟、烟梗、香精香料这些辅料的保质期问题。把这些业务逻辑理清楚、做出来，既有技术含量，又有行业深度，答辩时也有的讲。
我先把这个系统该做成什么样、技术方案怎么选、核心代码怎么落地、踩过哪些坑，一条一条给你捋清楚。不管你是自己要写这个毕设，还是想把它当企业级项目的练手案例，这篇文章应该都能帮上忙。
1. 系统定位与功能架构拆解
1.1 卷烟厂库存管理到底在管什么
很多人一听“库存管理”就以为是简单的商品增删改查，这在小卖部系统里成立，但在卷烟厂完全不是一回事。我实际了解过烟草行业的仓储流程，这里面的复杂度主要体现在三个维度。
第一个维度是原料的层次结构。烟叶原料不是单一商品，它分为原烟、片烟、梗丝、膨丝、再造烟叶等不同形态，每种形态又按产地、等级（比如X2F、C3F这种烟草行业专属等级代号）、年份、醇化周期分成多个批次。不同批次的烟叶在配方里的用途不同，投放优先级也不同。这让原料库存必须做到“批次级”管理，而不是简单合并同类项。
第二个维度是成品的多样性。成品烟不是一种，而是按品牌、规格（软盒、硬盒、细支、中支）、焦油含量、口味等多个属性形成SKU矩阵。而且每箱烟有唯一的件烟条码，出库时要能追溯到具体是哪个生产批次、哪个质保时段生产的。
第三个维度是物资流转的复杂性。卷烟厂的仓库不是只有原料和成品，还有大量辅料（烟用纸箱、滤嘴棒、香精香料）、备品备件。以滤嘴棒为例，它有25mm、30mm等多种规格，还要考虑丝束的来料批次。如果只做原料和成品两个模块，当然能满足毕业设计的核心得分点，但要做好主数据和生产计划的衔接，就得把辅料作为一个独立模块考虑进去。
所以，这个系统的核心目标可以概括为：让原料、成品、辅料的入库、存储、出库、盘点全过程可追踪、可校验、可分析，同时打通订单到出库的协同链路。
1.2 基于Spring Boot的模块划分与设计逻辑
我给学生推荐的分层模块是这样的：
- 基础数据模块：管理牌号信息（也就是成品烟的SKU）、原料等级字典、仓库货位、往来单位（供应商、销售客户）、烟叶等级标准。
- 入库管理模块：原料入库（含质检记录）、成品入库（生产下线入库）、辅料入库、采购退货等。
- 出库管理模块：原料领料出库（车间投料）、成品销售出库、辅料领用、调拨出库等。
- 库存管理模块：现存量查询、批次台账、货位库存、移库操作、库存盘点、安全库存预警、效期预警。
- 订单协同模块：销售订单创建、订单审核、订单状态跟踪、根据订单自动生成出库单。
- 系统管理模块：用户、角色、权限、菜单、操作日志。
模块划分的核心思想是“单据驱动库存”。也就是说，所有库存数量的变化必须由业务单据触发，不允许直接修改库存表。比如ERP里常见的逻辑：创建入库单→审核通过→库存自动增加；创建出库单→审核通过→库存自动扣减。这样做的好处是一旦库存数据出现异常，可以顺着单据流往回查，定位是哪个环节出了问题。
在技术结构上，Spring Boot项目内部要严格分层：Controller层只负责接收参数和返回结果，Service层处理业务逻辑，Mapper层操作数据库。我见过很多学生把所有逻辑塞进Controller里，代码倒是能跑，但一涉及事务就会出各种诡异问题。我们后面讲到事务边界和排查问题时，你会看到分层的必要性。
1.3 系统能解决的实际痛点与使用对象
这套系统建设完后，解决的问题不是纸上谈兵，而是车间和仓库每天实打实的痛苦。
第一，解决数据滞后问题。之前用Excel管库存，晚上生产结束第二天上午才能统计出昨天的原料消耗和成品入库量，数据永远滞后。这个系统能做到实时更新，只要你完成出库审核，车间数据员当时就能看到最新的投料库存状态。
第二，解决批次追溯难题。烟草行业对质量追溯的要求非常严格，如果某批原料抽检发现农药残留超标，要立刻锁定这批烟叶被投到了哪些牌号、哪些批次的产品里。手工记录基本做不到这种追溯，而批次化的数据库表设计可以做到“一键倒查”。
第三，解决纸质单证易丢失、易漏登的问题。仓库管理员收发货时用PDA或者电脑做单，单据电子化，月底盘点时再也不用抱着一大摞纸质单据和账本来回翻。
使用对象上，除了作为毕业设计展示，项目里涉及的Web端管理后台、角色权限和报表分析，完全可以拿来做Java后端岗位的求职项目——因为它有完整的业务闭环，面试官问业务问题你也答得上来。
2. 关键技术选型与数据库模型设计
2.1 为什么选Spring Boot而不是Spring MVC
这个问题几乎每次答辩老师都会问，我建议你在文档和答辩PPT里写得明明白白。
Spring Boot相对于传统Spring MVC，核心优势是自动配置和“开箱即用”。你引入spring-boot-starter-web依赖，内嵌Tomcat，写一个@SpringBootApplication启动类，一个简单的Web服务就跑起来了，不需要再去配置一大堆XML文件。这意味着你可以把精力放在业务功能实现上，而不是纠结配置文件怎么少写一个bean。
当然，Spring Boot并不是省掉了Spring的IOC容器和AOP能力，它底层还是Spring Framework，只是帮你做了大量自动化和约定优于配置的封装。在项目里，我们用@Transactional管理事务，用Spring Security做登录认证和权限控制，用Spring AOP实现操作日志记录，这些机制都是Spring的看家本领。
对于毕业设计或小团队内部系统，Spring Boot + MyBatis Plus + MySQL + Redis这套组合，开发效率最高。Java 17或Java 21都行，稳定优先选JDK 8到JDK 17之间的版本，别急着上Java 21的虚拟线程——这个功能确实香，但如果你不熟悉，反而会在毕业设计里给自己挖坑。当然，如果只是Spring Boot 3.5 + Java 21跑个demo级别的系统，虚拟线程的兼容性问题不大，但我个人建议还是求稳。
2.2 数据库表结构设计与核心字段说明
数据库是整个库存管理系统的地基。我直接把核心表结构和字段设计思路列出来，你照着建库就行。
第一张是原料库存表（raw_material_stock）。这张表做批次级管理，核心字段包括：原料ID、原料编码、原料名称、等级编码（如C3F）、产地、年份、形态类型（原烟/片烟）、批次号、仓库ID、货位ID、数量（单位公斤）、质检状态、入库时间。批次号是全局唯一的，由系统生成，比如按日期加流水号生成。
第二张是成品库存表（finished_product_stock）。字段包括：成品ID、牌号编码、牌号名称、规格类型（硬盒/软盒/细支）、包装数量（如每条10包、每箱50条）、批次号（生产批次）、质保截止日期、仓库ID、货位ID、件烟条码、数量。成品库存的最小单位可以设计成“件”或“条”，具体看业务流程。我建议同时保留件数和条数两个字段，出库时可整件可拆条。
第三张是出入库单据主表和明细表。主表（stock_document）存储单据编号、单据类型、业务方向（入库/出库）、关联订单号、往来单位、仓库ID、操作人、审核人、制单时间、审核状态等字段。明细表（stock_document_item）存储单据对应的具体物料、批次、货位、数量。这样设计的好处是同一张入库单可以包含多个不同批次的烟叶，符合实际业务中一车原料混装多批次的场景。
第四张是订单表（sales_order）。字段包括：订单编号、客户编码、客户名称、牌号编码、牌号名称、订货数量、已出库数量、订单状态（待审核/已审核/已分配/已完成）、下单日期、期望交货日期、订单金额。订单状态机是整个订单协同模块的核心，后面在业务实现里我再展开讲。
其他辅助表还包括仓库表、货位表、盘点记录表、库存变动流水表（stock_change_log）、用户角色权限表。其中库存变动流水表非常关键，每笔库存变动都要插入一条流水，记录变动前数量、变动后数量、变动原因、关联单号、操作人。
注意：库存流水和单据明细是“审计追踪”的基础，千万别省。我见过有人图省事只维护库存表，结果库存对不上账时完全无从排查。有了流水表，所有的库存异动都在掌控之内。
2.3 核心数据流与库存数据一致性方案
这个系统里最核心的数据流有两条。
第一条是采购入库流：采购合同/到货通知 → 质检记录 → 创建原料入库单 → 审核通过 → 插入库存明细/更新库存总量 → 记录库存流水。烟草公司对于原料烟叶的质检非常严格，抽样不合格整批可能拒收，所以入库单要有质检状态字段，质检不合格的单据不允许审核入库。
第二条是销售出库流：销售订单创建 → 订单审核 → 库存分配（锁定库存） → 生成出库单 → 出库单审核 → 库存扣减 → 更新订单已出库数量 → 记录库存流水。注意这里涉及一个“库存锁定”的概念：创建出库单时应该先把所需数量的库存锁定（状态变为已分配），但还没真正扣减，等出库单审核后，才执行实际的库存扣减。这样防止A订单刚创建，B订单也看到同一批库存并尝试出库，造成超卖。
在技术上，库存扣减这个动作建议采用“前置校验 + 数据库乐观锁或悲观锁”。最简单可靠的做法是扣减时使用UPDATE ... WHERE id = ? AND quantity >= 所需数量这样的条件更新语句，MySQL会基于行锁保证并发安全。如果更新返回的影响行数为0，说明库存不足，需要回滚并提示用户。这种方式比先SELECT再UPDATE更安全，因为它在数据库层面保证了原子性。
3. 从零实现：前端页面、后端接口与核心业务代码
3.1 技术栈补充与开发环境搭建
从零开始做这个系统，开发环境建议如下：
- IDE：IntelliJ IDEA（社区版也够用，但专业版对Spring Boot的支持更好）
- JDK：JDK 17（Spring Boot 3.x要求JDK 17起步，建议使用）
- 构建工具：Maven 3.8+
- 数据库：MySQL 8.0+，Navicat或DBeaver做客户端
- 缓存：Redis 6.x（用于存token实现单点登录、缓存字典数据）
- 前端框架：Vue 3 + Element Plus + Vite（后台管理界面标准组合），或者直接用Thymeleaf做服务端渲染也可以简化开发量。前端如果时间紧，只做Web端管理后台就足够撑起整个项目的完整度。
脚手架推荐直接去 Spring Initializr 生成项目，勾选Spring Web、MyBatis Framework、MySQL Driver、Spring Security、Validation依赖。项目生成后，在application.yml里配置数据源、Redis和MyBatis的mapper扫描路径。
3.2 后端基础工程结构规范
我一贯偏爱按业务模块而不是按技术层来分包，这样新手拿到项目更好理解：
com.cyg.inventory ├── common // 公共类：统一返回结果、异常处理、工具类 ├── config // 配置类：Redis配置、Security配置、MyBatisPlus配置 ├── controller // 控制器 │ ├── rawmaterial │ ├── finishedproduct │ ├── stock │ ├── order │ └── system ├── service // 业务接口和实现 │ ├── stock │ ├── order │ └── ... ├── mapper // 数据库操作层 ├── entity // 实体类 ├── dto // 数据传输对象 └── vo // 视图对象统一返回结果类建议设计成泛型：Result<T>，包含code、message、data三个字段。Controller返回时统一包装。这样做有两个好处：前端处理接口响应逻辑统一，不需要每个接口单独写判断；错误信息也能标准化，调试起来轻松很多。
3.3 核心功能模块详细实现：入库、出库、盘点
入库业务建议设计成五个步骤的原子事务：
- 前端提交入库单基本信息（仓库、往来单位、单据类型、经办人等）
- 提交入库明细（物料、批次、数量、货位）
- 后端校验批次是否存在、货位是否有效、数量是否为正数且符合精度要求
- 主表状态设为待审核，明细写入单据明细表
- 审核节点通过后，依次执行为库存表增加数量、新增库存变动流水、回填单审核状态
代码层面，这一步尤为关键。我先提供一个简化的Service核心方法，你能直观理解其中逻辑：
@Service public class InStockServiceImpl implements InStockService { @Autowired private StockRecordMapper stockRecordMapper; // 库存流水 @Autowired private RawMaterialStockMapper rawMaterialStockMapper; @Autowired private StockDocumentMapper stockDocumentMapper; @Autowired private StockDocumentItemMapper stockDocumentItemMapper; @Override @Transactional(rollbackFor = Exception.class) public void auditInStock(Long documentId) { // 1. 校验单据状态，防止重复审核 StockDocument doc = stockDocumentMapper.selectById(documentId); if (doc == null) { throw new BizException("单据不存在"); } if (!"待审核".equals(doc.getStatus())) { throw new BizException("单据状态不允许审核"); } // 2. 获取单据明细列表 List<StockDocumentItem> items = stockDocumentItemMapper .selectList(new QueryWrapper<StockDocumentItem>() .eq("document_id", documentId)); // 3. 逐条处理，增加库存并记录流水 for (StockDocumentItem item : items) { RawMaterialStock stock = rawMaterialStockMapper .selectByBatchAndLocation(item.getBatchNo(), item.getLocationId()); if (stock == null) { throw new BizException("库存批次记录不存在：" + item.getBatchNo()); } // 库存增加（注意这里可以加数据库乐观锁防止并发修改） int rows = rawMaterialStockMapper.increaseQuantity( stock.getId(), item.getQuantity(), stock.getQuantity()); if (rows == 0) { throw new BizException("库存更新失败，请重试"); } // 记录库存流水 StockChangeLog log = new StockChangeLog(); log.setMaterialId(stock.getMaterialId()); log.setBatchNo(item.getBatchNo()); log.setChangeType("入库"); log.setBeforeQty(stock.getQuantity()); log.setAfterQty(stock.getQuantity() + item.getQuantity()); log.setDocumentNo(doc.getDocumentNo()); log.setOperateUserId(doc.getAuditUser()); stockChangeLogMapper.insert(log); } // 4. 更新单据状态 doc.setStatus("已审核"); stockDocumentMapper.updateById(doc); } }那行单独的increaseQuantity要落到Mapper的XML里，采用条件更新来保证并发安全：
<update id="increaseQuantity"> UPDATE raw_material_stock SET quantity = quantity + #{increaseQty}, update_time = NOW() WHERE id = #{id} AND quantity = #{expectQty} </update>这里用quantity = 期望值作为乐观锁条件，如果期间有别的操作改了数量，UPDATE影响行数为0，事务回滚，业务提示重试。实测下来这个方案在高并发下既简单又可靠，比在Service层用synchronized锁住一堆代码要高效得多。
出库业务恰好相反，扣减库存前必须校验可用库存是否充足。我建议出库单审核时，先执行这样一条条件更新：
UPDATE raw_material_stock SET quantity = quantity - #{outQty} WHERE id = #{id} AND quantity >= #{outQty}影响行数为0就是库存不足或者库存记录被其他并发事务改了，直接抛业务异常，事务整体回滚。订单分配库存时也要查询“可用库存”，可用库存等于总库存减去已锁定数量，这样才不会被其他出库单抢走同一批货。
盘点业务也不可跳过。建议做“盘点单 → 盘点明细录入 → 盘点差异审核 → 生成盘盈盘亏调整单”四步流程。盘点时系统自动冻结该货位的出入库操作（或者允许录入差异但锁定盘点期间的单据），避免边盘边变。差异审核通过后，要把差异数量反映到库存表和库存流水里，保留完整的盘点差异记录。
3.4 订单协同的关键实现思路
订单协同是这个系统区别于普通进销存的一大亮点，答辩时值得多花篇幅展示。
销售订单的状态机建议设计为：待审核 → 已审核 → 部分出库 → 已完成 → 已取消。用户在订单管理页面创建订单后，销售经理审核通过；物流部门看到已审核订单后，点击“生成出库单”，系统自动根据订单明细生成一条关联的出库单；仓储管理人员对出库单审核出库；出库完系统自动更新订单的已出库数量；当已出库数量等于订单数量时，订单状态自动变更为已完成。
在数据库层面，订单表和出库单表通过order_no字段关联。出库单明细冗余存储了牌号编码、牌号名称、数量、批次号等信息，做到“单据流可追溯、数据不丢失”。
订单里的“库存精准锁定”功能同样值得重点实现：创建出库单的时候，系统根据指定的仓库和货位，按“先进先出”（FIFO）原则自动分配批次库存。这个在SQL里可以用排序实现：先查所有可用批次，按照入库时间升序排列，依次锁定前几个批次，直到数量满足需求。
// 简化示例：按先进先出锁定库存批次 List<FinishedProductStock> batchList = finishedProductStockMapper .selectAvailableBatches(brandCode, warehouseId, orderQty); int allocatedQty = 0; for (FinishedProductStock stock : batchList) { int need = orderQty - allocatedQty; int take = Math.min(need, stock.getAvailableQty()); // 执行库存锁定 update... allocatedQty += take; } if (allocatedQty < orderQty) { throw new BizException("可用库存不足，无法生成出库单"); }这个FIFO逻辑在答辩时讲出来，老师会觉得你懂业务，而不是只会“增删改查”。
3.5 前端页面与后端接口的完整交互设计思路
前端用Vue 3 + Element Plus的话，我建议把页面分成数据看板、业务操作、信息查询、系统配置四大类。数据看板放库存总览（仪表盘统计：今日入库量、今日出库量、库存总值、原料库存预警数量等）；业务操作分别是入库单、出库单、盘点单、移库单的新建与审核页面；信息查询对应库存现存量查询、批次台账查询、出入库流水查询；系统配置对应仓库货位管理、供应商/客户管理、用户权限管理。
接口设计遵循RESTful风格。核心接口如下：
POST /api/stock/raw/inbound # 新建原料入库单 POST /api/stock/raw/inbound/audit # 审核原料入库单 POST /api/stock/raw/outbound # 新建原料出库单（领料） POST /api/stock/raw/outbound/audit # 审核原料出库单 GET /api/stock/raw/current # 原料现存量查询 GET /api/stock/raw/batch # 原料批次台账 POST /api/stock/finished/inbound # 成品入库（生产下线） POST /api/stock/finished/outbound # 成品出库（销售） GET /api/stock/finished/current # 成品现存量查询 POST /api/order/sales/create # 创建销售订单 POST /api/order/sales/audit # 销售订单审核 POST /api/order/sales/toOutbound # 订单生成出库单 GET /api/order/sales/list # 订单列表（含状态查询） POST /api/stock/check/create # 创建盘点单 POST /api/stock/check/audit # 盘点差异审核前端的鉴权方式建议用JWT（配合Spring Security）。用户登录后后端返回一个token，前端请求头带上Authorization: Bearer token，后端通过Security过滤器链校验token有效性和角色权限。这个方案是现在企业级前后端分离项目的主流做法，写进文档和答辩PPT里都很有说服力。
4. 异常场景处理与项目优化经验
4.1 库存超卖与并发扣减怎么防
库存管理系统最怕的就是超卖。两个管理员同时看到一个批次还有2000公斤烟叶，分别给两个车间各开1800公斤的出库单，如果代码是先查库存再判断够不够，两次查询看到的都是2000公斤，随后扣减，就会出现库存变负的情况。
前面已经提过，正确做法是用条件更新SQL确保原子性。我再拓展一个场景：如果出库单要跨多个批次扣减，事务跨度更长，还得注意数据库事务隔离级别。MySQL默认的Repeatable Read下，多个事务同时扣减同一批次的库存时，“行锁”会串行化更新操作，不会出现幻读导致的超扣。只要UPDATE语句里带上“WHERE quantity >= 需要扣减的量”作为条件，并发安全就能保证。
如果Redis用上了，也可以先用Redis的分布式锁或者Lua脚本做库存预扣，再异步落库。但这个方案复杂度高，业务逻辑容易绕晕，单体项目里直接用数据库条件更新是最好的选择，简洁、可靠、易解释。
4.2 报表统计与性能优化怎么做
库存管理系统到后期一定要上报表功能，否则评估说不完整。建议至少实现四个报表：日出入库汇总表（按日和仓库维度）、原料库存结构分析表（按等级/年份/产地维度）、成品库存库龄分析表（按批次和入库时间算库龄）、安全库存预警表（低于阈值的物料列表）。
性能方面有两个最容易踩的坑。第一个坑是列表查询没有做分页，数据量稍大页面直接卡死。MyBatis Plus自带分页插件，配置好PaginationInnerInterceptor，所有列表分页查询必须走分页插件。第二个坑是报表聚合查询用SELECT *然后Java里for循环过滤，这是灾难级别的性能劣化。正确做法是写SQL聚合语句，用GROUP BY、SUM、COUNT直接算出结果。
-- 按仓库+原料等级统计可用库存 SELECT warehouse_id, grade_code, SUM(quantity) AS total_qty FROM raw_material_stock WHERE status = '可用' GROUP BY warehouse_id, grade_code;索引优化也不能忽略。库存表查询频率最高的是按仓库ID、货位ID、批次号、物料编码查询，所以这几个字段要建联合索引。比如(raw_finished_stock表的warehouse_id, location_id)联合索引，能让货位库存查询走索引，避免全表扫描。订单表重点在order_no、status上建索引。
4.3 Spring Boot项目里必踩的坑与排查方法
第一个高频坑是MyBatis的XML文件放错目录导致找不到Mapper。用Spring Boot + MyBatis时，如果XML文件放在resources下，要在application.yml里配置mapper-locations: classpath:/mapper/*.xml。如果XML放在java包目录下（有的人喜欢这样），还得额外在pom.xml里声明resources包含xml文件，否则打包后XML不会进入classpath，启动直接报Invalid bound statement。
第二个高频坑是事务不生效。最常见原因是同类内部方法调用，比如OutStockService的createOutStock方法调用了同类的auditOutStock方法，即使auditOutStock标了@Transactional也不会生效，因为Spring的事务是基于动态代理实现的，内部调用绕过了代理。解决办法：如果是自调用，拆分成不同的Service互相调用，或者自己注入自身代理类（AopContext.currentProxy()）。注意Spring Boot 2.6.0+默认开启@EnableAspectJAutoProxy的exposeProxy=false，想用AopContext得先开启配置。
第三个坑是Spring Security的过滤器链导致接口401。一些学生配置Security后忘记放行登录接口和静态资源，前端页面死活调不通接口，排查老半天发现是Security拦截了。放行配置正确的是：
http.authorizeHttpRequests() .requestMatchers("/api/auth/login", "/doc.html", "/webjars/**", "/css/**", "/js/**").permitAll() .anyRequest().authenticated();第四个坑是MyBatis Plus的字段自动填充不生效。创建时间、更新时间这类字段，如果数据库允许为NULL，代码里没有设置值，插入后查询出来就是NULL。统一用MyBatis Plus的自动填充功能（@TableField的fill策略 + MetaObjectHandler实现），比每张表手动setTime要省心得多。
第五个坑是MySQL的时区问题导致日期差8小时。连接字符串里加上serverTimezone=Asia/Shanghai，并把JDBC驱动版本升级到8.0.30以上，一般就能解决。数据库端建议所有时间字段用datetime类型，代码里统一用LocalDateTime接受。
4.4 线上环境配置与性能压测建议
如果这个系统不只是交作业，还想走到线上试运行，Java的JVM参数建议加上最大堆内存限制，避免默认堆内存大小导致服务器负载飙升。
java -Xms512m -Xmx1024m -jar inventory-system.jar --spring.profiles.active=prodMyBatis打印SQL在生产环境一定要关掉，不然日志量大到恐怖。配置里把mybatis-plus.configuration.log-impl设置为org.apache.ibatis.logging.slf4j.Slf4jImpl，然后日志级别设成INFO即可关闭SQL打印。
系统上线前至少做一轮基础压测，推荐用Apache JMeter模拟50个并发用户，重点关注两个场景：一是并发提交出库审核时的库存扣减正确性；二是库存现存量查询接口在百万级数据量下的响应时间。以我实测经验，不建索引的现存量查询，库存表数据到50万行时，响应时间会从30ms掉到800ms以上，建索引并优化SQL后能稳定在100ms以内。
5. 毕业设计展示与个人收获
页面展示和系统演示这里，重点建议把“数据大屏”做出来——用ECharts做一个库存总览看板页面，显示饼图（各牌号成品库存占比）、折线图（近7天出库趋势）、柱状图（各仓库库存量）以及预警信息列表。这个页面在系统演示时视觉效果最直观，答辩老师打开第一眼就会被吸引住，分数一般不会低。ECharts本身是开源免费的，集成方式也简单，npm安装echarts后按文档配置一个div容器就可以出图。
至于整个项目做完之后的收获，我的感受是：Spring Boot的上手成本确实很低，但真正拉开水平差距的是业务建模能力和数据一致性设计。把一张入库单拆成主表和明细表、把库存变动的每一步都通过事务和流水串起来、把订单到出库的状态机理清楚——这些看不见的“内功”，才是一个Java开发工程师最值钱的部分。这套系统做完，你不仅会写接口，还要能理解业务流程，面试官问起“你来说说你们系统怎么防止并发超卖”时，你能讲出“条件更新 + 数据库行锁 + 库存流水”这套组合拳，工作Offer基本就稳了一半了。
最后说个小技巧。做演示的时候，一定先提前把库存数据造好，别用空数据库。该铺垫的库存数据要提前铺满：几个仓库、几十个货位、几十个牌号的成品批次、不同年份的原料批次。界面上一眼能看到的丰富数据，比你现场敲半天的代码有用得多——毕竟答辩老师看的是你的系统能力和业务理解，不是看你打字速度。
