做供应链管理系统这种项目很多人一上来就纠结“用什么技术栈”“要写多少个模块”“数据库怎么设计”结果原型图还没画两张代码先写了一堆最后推倒重来。这套基于SpringBoot的供应链管理系统是我近期完整走下来的一套项目从需求拆解、表结构设计到核心功能实现踩了不少坑也沉淀了不少方法。如果你也正在做类似的后台管理系统或者刚接触企业级项目开发想找个完整案例入手这篇文章应该能帮你省掉很多弯路。先说清楚这套系统到底做了什么。它面向的是典型的中小型贸易/制造企业场景覆盖采购、入库、库存、订单、出库、供应商与客户管理这几条核心链路角色上分为管理员、采购员、仓库管理员、销售员四类配合登录认证、权限拦截、数据统计看板基本就是一个可以拿去答辩、也可以直接改造成生产环境初版的完整解决方案。1. 项目到底在解决什么问题1.1 供应链管理系统的业务痛点我接触过不少做进销存或者供应链方向的毕业设计和外包项目最典型的痛点不是“功能不够多”而是“数据根本对不上”。采购下了单货到了仓库却不知道仓库出了库财务那边没有同步记录销售查库存看到的数据和实际仓库差了十几件。这些问题本质上是业务流程没有在系统里形成闭环。所以这个项目在设计时第一原则就是所有业务动作必须留下数据痕迹。采购订单从创建到审核再到入库状态要可追溯库存每一次变动都要写库存流水销售订单生成后自动锁定库存发货后扣减。这些听起来简单但实际落地时需要把业务状态机设计清楚不然代码写到后面自己都搞混了。另一个痛点是权限。仓库管理员不应该看到采购价格销售员也不应该能修改库存数据。如果用一个简单的用户表加一个角色字段然后到处写if判断后期维护成本会很高。这个项目采用RBAC权限模型用户、角色、菜单三级关联通过拦截器校验接口权限既符合真实企业管理诉求也是面试时能拿得出手的亮点。1.2 为什么选SpringBoot这套组合技术选型上我没有搞花里胡哨的微服务那一套就用SpringBoot MyBatis-Plus MySQL Redis Vue前后端分离。原因是这类管理系统本质上是“业务强、并发低、逻辑复杂”的CRUD密集型应用单体架构完全够用而且部署运维简单性能瓶颈通常出现在慢查询和数据库连接上而不是应用本身。SpringBoot的好处不用多说自动配置、内置容器、生态成熟起步成本极低。重点说一下MyBatis-Plus它在MyBatis基础上封装了通用Mapper和通用Service单表CRUD不用写SQL分页插件和代码生成器也极大提升了开发效率。供应链系统里有大量“根据条件查询列表”的场景比如订单列表按时间、状态、供应商筛选MyBatis-Plus的LambdaQueryWrapper写起来非常清爽。Redis在这个项目里不是刚需但我还是加上了用来缓存字典数据和登录令牌。供应链系统的字典项不少比如订单类型、商品单位、审核状态每次都查数据库没必要缓存到Redis之后接口响应速度提升非常明显。这个设计也方便你在简历上写“引入Redis缓存热点数据降低数据库压力”。提示如果你是毕业设计技术栈里有Redis、JWT、RBAC这些关键词评分和答辩效果会明显好于纯JSPServlet的旧方案。2. 系统整体设计与核心细节拆解2.1 模块划分与架构层次我的模块划分遵循“高内聚、低耦合”的原则先按业务域拆成五个主要功能模块模块核心实体主要功能采购管理采购单、采购明细采购下单、审核、到货登记库存管理商品、库存、库存流水入库、出库、盘点、库存预警销售管理订单、订单明细下单、发货、退换货基础资料供应商、客户、分类数据维护与启用停用系统管理用户、角色、菜单登录认证、权限控制、操作日志从工程结构上我用了标准的四层分包Controller接收请求参数并做参数校验Service处理业务逻辑Mapper负责数据库交互Entity对应数据表。另外单独拆出common包放统一返回结果、异常处理、工具类config包放配置类。这里有个很实用的设计习惯所有接口返回统一格式Result。不管成功还是失败返回体都是{ code: 200, msg: 操作成功, data: {...} }这样。前端只需要判断code就能统一处理比到处返回raw数据或直接抛异常给前端友好得多。2.2 数据库表结构设计的关键决策表设计是整个项目的灵魂我前前后后改了三个版本。核心表主要分这么几组用户表sys_user、角色表sys_role、菜单表sys_menu、用户角色关联表、角色菜单关联表这五张是权限体系的基础。供应商表supplier、客户表customer、商品表product、分类表category这些是基础数据表注意在商品表里冗余了stock字段用于列表展示但真正的库存数据以库存表stock为准。听上去有点冗余对吧这是刻意的因为库存列表页高频查询如果每次都join库存流水表去做sum聚合数据量上来后会很慢。核心业务表是采购单purchase_order、采购明细purchase_item、销售订单sales_order、销售明细sales_item、库存流水stock_record。用一个比较具体的例子来说明状态字段的设计CREATE TABLE purchase_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(32) NOT NULL COMMENT 采购单号, supplier_id BIGINT NOT NULL COMMENT 供应商ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 采购总金额, status TINYINT NOT NULL COMMENT 状态0待审核 1已审核 2已入库 3已完成 4已取消, create_by BIGINT COMMENT 创建人, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT 采购单;为什么不用字符串状态而是要TINYINT加注释因为字符串要靠人记忆很容易写错数字加注释又简练又可控代码里再配一个枚举类做映射前后端展示时统一处理。采购和销售的状态流转一定要单独画一张状态机比如采购单待审核 → 已审核 → 已入库 → 完成任何一步都不能跳。2.3 为什么要把库存流水单独建表库存流水表是整个系统里我最看重的一张表它的存在让库存可追溯成为可能。所谓流水就是每一次库存变化都记录一条数据包含商品ID、变动数量正数入库、负数出库、变动类型1入库 2出库 3盘点调整、关联业务单号、操作时间和操作人。这个方案在真实企业里是标配但在很多项目里容易被忽略。没有流水表库存数据一旦出错你根本不知道是哪一步操作导致的只能对着数据库手工一条条改——这是运维灾难。有了流水表之后要对账或者排查问题直接按关联单号一查所有变动链路清清楚楚。我在设计时还把库存表和流水表做了逻辑层的联动所有的库存变动必须走同一个Service方法。也就是说不管是从采购入库、销售出库还是手动盘点调整最终都会调用StockService.changeStock()这个方法它负责两件事更新库存表字段、写入库存流水。这样做能避免某个业务方绕过统一逻辑直接自己update库存导致数据不一致。3. 核心功能实战采购、库存与报表3.1 采购入库的完整流程实现采购业务流程是供应链系统的起点也是链路最完整的模块。实际代码中我按这样几步走的第一步采购员创建采购单填写供应商、商品明细、数量、采购价系统自动计算总金额此时状态为待审核。这里注意一个细节采购单创建时不需要校验库存因为还没有发生库存变动。第二步审核人一般是管理员审核采购单。审核通过后状态变为已审核此时商品还没有入库库存不可见增量但采购单已经生效。第三步到货登记。仓库管理员根据实际到货数量进行入库操作这时才真正调用库存变更逻辑Transactional(rollbackFor Exception.class) public void stockIn(PurchaseOrder order) { ListPurchaseItem items purchaseItemMapper.selectList( new LambdaQueryWrapperPurchaseItem() .eq(PurchaseItem::getOrderId, order.getId())); for (PurchaseItem item : items) { stockService.changeStock(item.getProductId(), item.getQuantity(), StockRecordType.PURCHASE_IN, order.getOrderNo()); } order.setStatus(OrderStatus.INBOUND.getCode()); purchaseOrderMapper.updateById(order); }有没有发现库存变更和订单状态更新是在同一个事务里的。这里交易的关键点在于一旦事务中途报错库存不能变了但订单状态也不能变否则系统就处于一种“库存加了但单据没更新”的脏状态。所以我给方法加上了Transactional注解保证原子性。3.2 库存扣减的并发一致性问题销售出库时的库存扣减是这个项目里最容易出Bug的地方。如果直接在并发环境下执行“先查库存判断足够然后扣减”这种操作两个订单同时请求就可能出现超卖。我用的处理方式是在SQL层面做条件更新而不是先查后改int rows stockMapper.deductStock(productId, quantity); if (rows 0) { throw new BizException(库存不足或商品不存在); }对应的Mapper SQL大概长这样update iddeductStock UPDATE stock SET stock stock - #{quantity}, update_time NOW() WHERE product_id #{productId} AND stock #{quantity} /update这个方案的精髓在stock #{quantity}这个条件上。数据库的行锁保证同一时刻只能有一个事务更新这条记录条件不满足就更新0行应用层拿到0就知道库存不足直接抛出业务异常。全程不需要额外加锁也不需要事务隔离级别调整性能和安全都兼顾了。注意这里有个细节容易被忽略——扣减库存前必须确认订单状态合法比如未发货、未取消否则可能会出现“订单取消了但库存被扣了”的并联问题。我在代码中先后检查订单状态再扣库存整块包在事务里。3.3 报表统计和看板数据怎么高效查系统首页要展示采购金额趋势、订单数量、库存总量这些统计指标。最傻的办法是每次请求都对整个业务表做count和sum数据少还能看数据一多接口就会卡成PPT。我的做法是单独建一张dashboard_statistics汇总表每天凌晨通过定时任务统计前一天的数据写入汇总表页面的看板接口只查这一张表速度飞快。Component public class StatisticsTask { Scheduled(cron 0 15 0 * * ?) // 每天凌晨0点15分执行 public void dailyStatistics() { // 统计昨日的采购总额、销售总额、订单数量 // 写入dashboard_statistics表 } }即时性要求高的指标比如“今日实时销售额”我直接用Redis的HyperLogLog做近似统计误差在可接受范围内且内存占用极小。这种“离线汇总实时估算”组合拳在数据量几百倍的差距下依然能保持秒级响应。4. 实操过程从零到一的完整搭建记录4.1 项目初始化和基础工程搭建我习惯用Spring Initializr生成基础工程然后手动调整依赖版本。核心依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency这里提醒一下MyBatis-Plus和SpringBoot的版本兼容性真得注意。我用的是SpringBoot 2.7.x搭配MyBatis-Plus 3.5.x运行非常稳定。如果你用的是SpringBoot 3.x就要换成对应新版本的依赖否则启动时会有各种ClassNotFound异常排查起来很恼火。配置文件方面需要单独把数据源、Redis连接和MyBatis-Plus的配置分开spring: datasource: url: jdbc:mysql://localhost:3306/scm?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 mybatis-plus: mapper-locations: classpath:/mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl注意serverTimezoneAsia/Shanghai这个参数很多项目跑起来发现时间差8小时就是没配这个导致时区错乱。4.2 权限认证模块的实现套路权限这块我采用JWT 拦截器的方式。登录成功后生成token返回前端前端每次请求在header里带上Authorization: Bearer token后端拦截器校验token并解析出用户ID之后根据当前用户查角色、查权限再用自定义注解校验接口权限。登录逻辑核心代码public String login(String username, String password) { User user userMapper.selectOne( new LambdaQueryWrapperUser() .eq(User::getUsername, username)); if (user null || !md5(password).equals(user.getPassword())) { throw new BizException(用户名或密码错误); } if (user.getStatus() 0) { throw new BizException(账号已被禁用); } return JwtUtil.createToken(user.getId(), user.getUsername()); }密码不能明文存储这是基本常识。我用的MD5加盐实际项目中用BCrypt更安全。Redis在这里用来存登录状态和token过期时间实现单点登录用户再次登录时旧token直接失效。4.3 核心CRUD的现代化写法MyBatis-Plus让单表CRUD变得非常舒服。拿商品列表查询来说public PageResultProductVO pageQuery(ProductQuery query) { LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getName()), Product::getName, query.getName()) .eq(query.getCategoryId() ! null, Product::getCategoryId, query.getCategoryId()) .orderByDesc(Product::getCreateTime); PageProduct page productMapper.selectPage( new Page(query.getPageNum(), query.getPageSize()), wrapper); // 转VO返回 }注意like方法的第一参数是boolean只有条件成立才会拼接这个查询条件这样就不用在代码里写一堆ifelse来拼接wrapper可读性好很多。另外说一个实用建议Entity和VO一定要分开。Entity里的字段和数据库表一一对应但接口返回给前端的对象可能是Vo字段可以做裁剪、可以聚合展示名等。在列表接口中我一般把关联表的名称字段比如供应商名、商品类别名都填充到VO里避免前端再发一次请求去查字典。5. 常见问题与排查技巧实录5.1 数据权限只做了角色权限用户在多个角色时怎么处理这是我在实际使用中遇到的第一个比较大的设计问题。如果一个人同时是采购员和仓库管理员他拥有两个角色的所有权限这在RBAC模型里是合理的但在具体业务上就有个问题——比如采购单列表普通采购员只能看自己创建的仓库管理员能看所有待入库的而这个人两种身份都具备他应该看到哪些数据我的方案是给角色增加一个数据权限字段data_scope取值是1全部、2本部门、3仅本人。查询时动态拼接当前用户的数据权限SQL片段从“能不能进这个接口”升级成“能看哪些数据”这是很多管理系统没做好的点。这个表增加后业务规则一下子复杂了但真实场景就是如此。开发过程中可以先用“所有角色只能看自己”简化答辩时再说“这只是MVP版本实际生产中会引入数据权限维度”也是有说服力的。5.2 报表统计接口耗时太长怎么办有一次我把业务表的统计接口直接开放给前端有个“获取供应商采购排行”的接口数据量大概二十万条时已经要4秒多。前端一直转圈体验极差。排查顺序我是这样做的第一步看MySQL的慢查询日志定位具体SQL第二步用EXPLAIN查看执行计划发现供应商表和订单表关联时没有走索引因为供应商名称字段没建索引导致全表扫描。加上索引后降到0.3秒但这对一个报表接口来说还是不够好。最终方案还是前面说的拆两路对近30天的明细数据走索引查询实时计算对历史汇总直接读取每日统计表。接口耗时稳定在200毫秒以内。记住一条经验列表接口可以接受几百毫秒聚合报表接口绝对不能实时去跑大表聚合。5.3 事务失效的经典场景处理采购入库时出现过一次诡异Bug库存已经插入流水了但采购单状态没有更新。查了半天发现stockIn方法是在Controller层直接调用的Service方法但方法内部调用了this.stockIn()而不是注入的代理对象调用的导致事务注解根本没生效。Spring的事务是基于AOP动态代理实现的同类内部调用时方法上的事务注解不会触发。要么自己注入自己要么把涉及事务的操作拆到另一个Service类中调用要么直接通过AopContext.currentProxy()拿到代理对象。这个坑在很多系统里都存在排查时如果发现“代码看起来没问题但事务就是不回滚”十有八九就是这个原因。6. 项目完成后还能怎么扩展这套系统做完之后如果想继续发挥它的价值有几个方向我认为性价比很高。第一个是接入消息队列。现在采购单审核通过后需要通知仓库管理员准备收货订单发货后需要通知客户。如果全用同步调用系统耦合度高且体验一般。引入RocketMQ或RabbitMQ做异步解耦不仅提升响应速度还能让项目在架构层面多一个亮点。第二个是补充移动端。很多企业场景下仓库管理员是在仓库现场用手机扫码操作的桌面端很不方便。前端可以用uni-app开发一个轻量级H5应用复用后端现有接口工作量也不大。第三个方向是数据分析预警。比如根据历史销售数据预测未来一周的销量低于安全库存的商品自动生成采购建议单这个就是供应链管理中最有业务价值的部分也是最能体现亮点的地方。从个人实际体会来说这类管理系统难度不在技术多新多深而在于把所有业务流程考虑周全在每个细节上保持严谨。把数据一致性、权限边界、代码结构这些问题老老实实处理好这套系统不管是用来答辩还是用于真实业务场景都是站得住脚的。