尧图网站建设 
简介这份资源是一份基于Java的供应链管理信息系统毕业设计文档面向计算机相关专业学生及需要完成课程设计或论文的开发者帮助解决供应链信息管理系统的设计与实现问题。文档围绕系统用户管理、供应商信息、制造商信息、分销商信息、商品信息、登录与退出等核心模块展开采用JSP页面技术、SSH框架、MyEclipse编辑器与SQL Server数据库并针对旧系统数据处理弱、扩展性差、操作复杂等不足进行了改进设计。资源包共1个docx文件约730KB内容涵盖摘要、目录、技术介绍、系统分析与测试等完整章节结构清晰可直接作为论文撰写与项目开发的参考模板。目前已有54人学习适合需要快速理解SSH框架整合与供应链业务模块划分的读者借鉴。1. 从一份“供应链管理信息系统”文档说起Java 技术栈怎么选才不翻车供应链管理信息系统这个词听起来很大但落到代码层面核心就三件事把采购、库存、销售、物流这些环节的数据管起来让上下游能在一个系统里看到同一份账并且把审批流、预警、对账这些动作自动化。很多毕业设计或企业内训项目会以“基于 Java 的供应链管理信息系统设计与实现”为题要求交付一套可运行、可演示、能讲清楚设计思路的系统。这类项目真正的难点不在业务概念而在于 Java 技术选型、模块拆分、数据一致性保障和权限控制这几处容易翻车的地方。如果你正在做类似题目或者想用 Java 搭一套进销存加供应链协同的底子下面这套从选型到落地、从建表到避坑的路径可以直接参考。我会按实际开发顺序讲不堆概念重点说清楚每个环节为什么这么选、参数怎么定、出问题看哪里。2. 技术选型与工程骨架Spring Boot MyBatis 还是别的组合2.1 为什么供应链系统优先考虑 Spring Boot 加 MyBatis供应链系统的数据模型通常比较“重”供应商、物料、仓库、采购单、入库单、出库单、库存流水、结算单表之间关联多查询条件复杂。这种场景下JPA 的自动建表和对象导航在初期很舒服但到了多表联查、动态条件分页、批量更新库存时SQL 可控性就成了刚需。MyBatis 允许你把 SQL 写在 XML 或注解里配合foreach、if标签处理动态查询库存扣减这类需要精确控制update ... where quantity #{num}的操作也更直观。Spring Boot 则负责把事务、连接池、Web 层、定时任务这些基础设施用 starter 方式装配好省去大量 XML 配置。常见做法是 Spring Boot 2.7 或 3.x 加 MyBatis-Plus后者提供通用 CRUD 和分页插件但复杂供应链查询仍然手写 SQL。数据库选 MySQL 8.0事务隔离级别用默认的 REPEATABLE READ库存扣减场景配合行锁或乐观锁。2.2 用 Spring Initializr 生成可运行骨架的最小步骤第一步不是急着写业务而是把工程跑起来。用 IDEA 的 Spring Initializr 或命令行curl生成项目依赖勾选 Spring Web、MyBatis Framework、MySQL Driver、Lombok。生成后先改application.yml把数据源和 MyBatis 配好。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/scm_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 minimum-idle: 2 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.scm.entity configuration: map-underscore-to-camel-case: true这段配置里serverTimezone必须显式指定否则 MySQL 8 驱动可能报时区错误。map-underscore-to-camel-case让数据库的supplier_id自动映射到 Java 的supplierId省去大量 resultMap。Hikari 连接池的maximum-pool-size在开发机设 10 足够生产环境要根据数据库最大连接数和并发量调整一般不超过 20。配完后写一个ScmApplication启动类和一个测试 Controller访问/ping返回字符串确认 Web 层和数据库连接都正常。这一步跑通再往下做能避免后面业务代码写完才发现环境有问题。2.3 分层结构怎么定Controller、Service、Mapper 的职责边界供应链系统的 Controller 只做参数校验和响应封装不写业务逻辑。Service 层承担事务边界比如“采购入库”要同时更新入库单状态、增加库存、写库存流水这三个操作必须在一个Transactional方法里。Mapper 层只负责单表或明确的多表查询不嵌套调用其他 Mapper。常见错误是把库存计算写在 Controller 里导致事务失效、并发扣减出错。我一般会在 Service 层用Transactional(rollbackFor Exception.class)显式指定回滚异常类型避免默认只回滚 RuntimeException 导致受检异常不回滚。DTO 和 Entity 分开Controller 接收 DTOService 转换成 Entity 落库返回时再转 VO这样数据库字段变更不会直接影响接口契约。3. 供应链核心表设计与库存扣减的 Java 实现3.1 供应商、物料、仓库、库存四张主表的字段与索引供应链系统的表设计决定了后面查询和扩展的难易。供应商表supplier至少包含id、name、contact、phone、status、create_time。物料表material包含id、code、name、spec、unit、category_id。仓库表warehouse包含id、name、location、manager。库存表inventory是核心字段为id、material_id、warehouse_id、quantity、locked_quantity、update_time并在(material_id, warehouse_id)上建唯一索引防止同一物料在同一仓库出现多条库存记录。采购单表purchase_order和明细表purchase_order_item用主外键关联明细里记录物料、数量、单价。索引方面inventory的唯一索引是必须的purchase_order的order_no建唯一索引create_time建普通索引用于按时间范围查询。字符集统一用utf8mb4排序规则utf8mb4_general_ci避免中文和特殊符号乱码。3.2 用 MyBatis 写库存扣减乐观锁与条件更新的取舍库存扣减是供应链系统最容易出并发问题的地方。两种常见做法一是乐观锁在inventory表加version字段更新时where id #{id} and version #{version}失败则重试二是条件更新直接update inventory set quantity quantity - #{num} where material_id #{mid} and warehouse_id #{wid} and quantity #{num}根据返回的影响行数判断是否成功。条件更新更简单适合库存量不大、并发不极端的场景。下面是一个 Mapper 接口和 XML 片段。Mapper public interface InventoryMapper { int deductStock(Param(materialId) Long materialId, Param(warehouseId) Long warehouseId, Param(num) Integer num); }update iddeductStock update inventory set quantity quantity - #{num}, update_time now() where material_id #{materialId} and warehouse_id #{warehouseId} and quantity #{num} /updateService 层调用后判断返回值如果为 0 说明库存不足或并发冲突抛出业务异常并回滚事务。参数说明materialId和warehouseId定位库存记录num是扣减数量quantity #{num}是防止超卖的关键条件。注意不要在 Java 里先查再减那样在并发下必然出问题。如果业务要求锁定库存可以增加locked_quantity字段下单时增加锁定出库时扣减实际库存并释放锁定逻辑更复杂但更贴近真实供应链场景。3.3 采购入库的事务边界与异常回滚验证采购入库涉及三张表更新采购单状态为“已入库”、增加库存、插入库存流水。这三步必须在同一个事务里。Service 方法上加Transactional(rollbackFor Exception.class)任何一步抛异常都整体回滚。验证事务是否生效可以在插入流水后手动抛一个 RuntimeException观察采购单状态和库存是否回到操作前。常见坑是 Mapper 方法被同类内部调用导致代理失效、事务不生效。解决办法是把事务方法放到独立的 Service 类里或者用AopContext.currentProxy()获取代理对象。另一个坑是 MySQL 的 autocommit 默认开启Spring 事务会先关闭 autocommit 再执行如果数据源配置了defaultAutoCommittrue且事务管理器没接管可能出现部分提交。检查DataSourceTransactionManager是否配置正确日志里打开org.springframework.transaction的 DEBUG 级别可以看到事务开启和提交记录。4. 权限控制与工作流供应链系统绕不开的两块硬骨头4.1 行级权限在 Java 里怎么落地从角色到数据过滤供应链系统里不同角色看到的数据范围不同。采购员只能看自己创建的采购单仓库管理员只能看自己仓库的库存财务能看所有结算单但不能改库存。这种行级权限如果只靠前端隐藏菜单后端接口裸奔等于没做。常见做法是在 Service 层拼接数据过滤条件比如查询采购单时根据当前用户角色动态加and create_by #{userId}或and warehouse_id in (...)。更优雅的方式是用 MyBatis 拦截器或 Spring AOP在 SQL 执行前统一注入权限条件。下面是一个简单的 AOP 思路定义DataScope注解在 Mapper 方法上标注拦截器解析当前用户和角色修改 SQL 的 where 条件。参数上用户上下文用 ThreadLocal 存储请求进入时由拦截器从 Token 解析并放入请求结束清除。注意 ThreadLocal 在异步任务和线程池里会丢失如果用了Async或定时任务需要手动传递用户上下文。4.2 基于状态机的采购审批流用 Java 枚举替代重型工作流引擎很多供应链项目一上来就想引入 Activiti 或 Flowable结果配置复杂、学习成本高最后只用到最简单的审批。如果审批节点固定、分支不多用 Java 枚举加状态机更轻量。定义PurchaseOrderStatus枚举DRAFT、PENDING_APPROVAL、APPROVED、REJECTED、RECEIVED。每个状态允许的迁移写在枚举方法里Service 层调用status.next(event)获取下一状态非法迁移直接抛异常。这样审批逻辑集中在枚举里测试好写数据库只存状态字符串。如果后续节点变多再迁移到工作流引擎也不迟。常见坑是把状态判断散落在各个 Service 方法里改一个流程要翻十几个文件。集中到枚举后新增状态只需改一处。4.3 定时任务与库存预警用 Spring Task 还是 Quartz供应链系统需要定时检查库存低于安全库存的物料并生成预警。Spring Task 的Scheduled注解足够应对单机定时任务配置cron表达式即可。如果任务需要持久化、集群防重复执行、动态修改执行时间才考虑 Quartz。单机项目用 Spring Task在启动类加EnableScheduling写一个StockWarningTask组件每天凌晨两点执行查询。注意定时任务里如果调用Transactional方法事务同样生效但任务方法本身不要加事务否则长事务占用连接。预警生成后可以插入warning表前端轮询或 WebSocket 推送。集群环境下 Spring Task 会在每个节点都执行导致重复预警这时要么用数据库唯一约束去重要么换 Quartz 的集群模式。5. 避坑与排查供应链系统开发中常见的五类翻车现场5.1 库存扣成负数现象、原因与解决现象是并发测试时库存出现负值或者明明库存足够却提示不足。原因通常是先查后减两个线程同时查到库存 10各自扣 8结果 -6。解决方法是改用条件更新where quantity #{num}根据影响行数判断。如果已经出现负库存先写脚本把负值修正为 0再排查所有扣减入口是否都走了条件更新。另外检查数据库字段是否用了无符号整数unsigned在减到负数时会报错而不是存负值这也是一种保护。5.2 事务不回滚现象、原因与解决现象是采购入库时库存加了但采购单状态没变或者抛异常后数据部分提交。原因可能是异常类型不在回滚范围内比如抛了受检异常但没配rollbackFor也可能是方法内部调用导致代理失效还可能是数据库表用了 MyISAM 引擎不支持事务。解决方法是显式写Transactional(rollbackFor Exception.class)把事务方法抽到独立 Bean建表时统一用 InnoDB。排查时打开 Spring 事务日志看是否有 “Participating in existing transaction” 或 “Initiating transaction rollback” 的记录。5.3 分页查询慢现象、原因与解决现象是采购单列表翻到后面几页越来越慢或者库存流水查询超时。原因是limit offset, size在 offset 很大时要扫描大量行加上多表联查和order by没有合适索引。解决方法是给排序字段建索引比如create_time或者改用游标分页用上一页最后一条记录的 id 作为下一页的起点。MyBatis-Plus 的分页插件默认用limit数据量大时建议手写where id #{lastId} order by id limit #{size}。另外避免在分页查询里做count(*)全表统计可以缓存总数或估算。5.4 中文乱码现象、原因与解决现象是供应商名称或物料规格在页面显示问号或者接口返回的 JSON 里中文变成\uXXXX。原因是数据库字符集不是utf8mb4或者 JDBC URL 没加characterEncodingutf8或者 HTTP 响应头没指定charsetUTF-8。解决方法是建库建表统一utf8mb4JDBC URL 加useUnicodetruecharacterEncodingutf8Spring Boot 的server.servlet.encoding.charsetUTF-8和forcetrue。如果已经建表用alter table ... convert to character set utf8mb4修改。5.5 定时任务重复执行现象、原因与解决现象是库存预警每天生成两条相同记录或者集群部署后每个节点都跑一遍。原因是 Spring Task 默认在每个节点都执行没有分布式锁。解决方法是加数据库唯一约束比如warning表对(material_id, warning_date)建唯一索引插入时用insert ignore或捕获重复键异常。或者引入 Redis 分布式锁任务执行前抢锁抢到才执行。单机环境检查是否重复配置了Scheduled方法或者cron表达式写错导致一分钟内触发多次。6. 从能跑到好用供应链系统的验证方法与一个压测技巧系统能跑通业务后怎么验证它真的可靠我一般会做三件事第一写集成测试覆盖核心链路用SpringBootTest加Transactional让每个测试方法自动回滚测试采购入库、库存扣减、审批流转。第二用 JMeter 或 wrk 对库存扣减接口做并发压测观察是否出现超卖和响应时间飙升。第三检查所有查询接口的 SQL 执行计划用explain看是否走索引。这里分享一个压测技巧不要一上来就压全链路先单独压库存扣减接口把并发数从 10 逐步加到 100观察数据库连接池和 CPU。如果响应时间在 50ms 以内且库存无负数再压采购单创建和查询。压测数据要提前准备比如 1000 个物料、10 个仓库、每个仓库 10000 库存用脚本批量插入。-- 批量生成测试库存数据 INSERT INTO inventory (material_id, warehouse_id, quantity, locked_quantity, update_time) SELECT m.id, w.id, 10000, 0, NOW() FROM material m CROSS JOIN warehouse w WHERE m.id 1000 AND w.id 10;这段 SQL 用交叉连接生成 10000 条库存记录material_id和warehouse_id组合唯一不会重复。压测时随机选material_id和warehouse_id调用扣减接口每次扣 1跑完后检查quantity是否等于初始值减去成功请求数。如果对不上说明有并发问题或事务问题。另外压测环境不要和生产共用数据库避免影响真实数据。最后说一个我自己的习惯每次改完库存相关的代码不管多小的改动都会在本地跑一遍并发扣减的单元测试用CountDownLatch模拟 100 个线程同时扣同一件库存断言最终库存等于初始值减 100。这个习惯帮我拦住了好几次“看起来没问题”的提交。供应链系统的数据一致性没有后悔药测试多花十分钟上线少熬一个通宵。希望帮到你。本文还有配套的精品资源点击获取 Java供应链管理系统开发实战：技术选型、库存扣减与避坑指南
简介这份资源是一份基于Java的供应链管理信息系统毕业设计文档面向计算机相关专业学生及需要完成课程设计或论文的开发者帮助解决供应链信息管理系统的设计与实现问题。文档围绕系统用户管理、供应商信息、制造商信息、分销商信息、商品信息、登录与退出等核心模块展开采用JSP页面技术、SSH框架、MyEclipse编辑器与SQL Server数据库并针对旧系统数据处理弱、扩展性差、操作复杂等不足进行了改进设计。资源包共1个docx文件约730KB内容涵盖摘要、目录、技术介绍、系统分析与测试等完整章节结构清晰可直接作为论文撰写与项目开发的参考模板。目前已有54人学习适合需要快速理解SSH框架整合与供应链业务模块划分的读者借鉴。1. 从一份“供应链管理信息系统”文档说起Java 技术栈怎么选才不翻车供应链管理信息系统这个词听起来很大但落到代码层面核心就三件事把采购、库存、销售、物流这些环节的数据管起来让上下游能在一个系统里看到同一份账并且把审批流、预警、对账这些动作自动化。很多毕业设计或企业内训项目会以“基于 Java 的供应链管理信息系统设计与实现”为题要求交付一套可运行、可演示、能讲清楚设计思路的系统。这类项目真正的难点不在业务概念而在于 Java 技术选型、模块拆分、数据一致性保障和权限控制这几处容易翻车的地方。如果你正在做类似题目或者想用 Java 搭一套进销存加供应链协同的底子下面这套从选型到落地、从建表到避坑的路径可以直接参考。我会按实际开发顺序讲不堆概念重点说清楚每个环节为什么这么选、参数怎么定、出问题看哪里。2. 技术选型与工程骨架Spring Boot MyBatis 还是别的组合2.1 为什么供应链系统优先考虑 Spring Boot 加 MyBatis供应链系统的数据模型通常比较“重”供应商、物料、仓库、采购单、入库单、出库单、库存流水、结算单表之间关联多查询条件复杂。这种场景下JPA 的自动建表和对象导航在初期很舒服但到了多表联查、动态条件分页、批量更新库存时SQL 可控性就成了刚需。MyBatis 允许你把 SQL 写在 XML 或注解里配合foreach、if标签处理动态查询库存扣减这类需要精确控制update ... where quantity #{num}的操作也更直观。Spring Boot 则负责把事务、连接池、Web 层、定时任务这些基础设施用 starter 方式装配好省去大量 XML 配置。常见做法是 Spring Boot 2.7 或 3.x 加 MyBatis-Plus后者提供通用 CRUD 和分页插件但复杂供应链查询仍然手写 SQL。数据库选 MySQL 8.0事务隔离级别用默认的 REPEATABLE READ库存扣减场景配合行锁或乐观锁。2.2 用 Spring Initializr 生成可运行骨架的最小步骤第一步不是急着写业务而是把工程跑起来。用 IDEA 的 Spring Initializr 或命令行curl生成项目依赖勾选 Spring Web、MyBatis Framework、MySQL Driver、Lombok。生成后先改application.yml把数据源和 MyBatis 配好。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/scm_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 minimum-idle: 2 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.scm.entity configuration: map-underscore-to-camel-case: true这段配置里serverTimezone必须显式指定否则 MySQL 8 驱动可能报时区错误。map-underscore-to-camel-case让数据库的supplier_id自动映射到 Java 的supplierId省去大量 resultMap。Hikari 连接池的maximum-pool-size在开发机设 10 足够生产环境要根据数据库最大连接数和并发量调整一般不超过 20。配完后写一个ScmApplication启动类和一个测试 Controller访问/ping返回字符串确认 Web 层和数据库连接都正常。这一步跑通再往下做能避免后面业务代码写完才发现环境有问题。2.3 分层结构怎么定Controller、Service、Mapper 的职责边界供应链系统的 Controller 只做参数校验和响应封装不写业务逻辑。Service 层承担事务边界比如“采购入库”要同时更新入库单状态、增加库存、写库存流水这三个操作必须在一个Transactional方法里。Mapper 层只负责单表或明确的多表查询不嵌套调用其他 Mapper。常见错误是把库存计算写在 Controller 里导致事务失效、并发扣减出错。我一般会在 Service 层用Transactional(rollbackFor Exception.class)显式指定回滚异常类型避免默认只回滚 RuntimeException 导致受检异常不回滚。DTO 和 Entity 分开Controller 接收 DTOService 转换成 Entity 落库返回时再转 VO这样数据库字段变更不会直接影响接口契约。3. 供应链核心表设计与库存扣减的 Java 实现3.1 供应商、物料、仓库、库存四张主表的字段与索引供应链系统的表设计决定了后面查询和扩展的难易。供应商表supplier至少包含id、name、contact、phone、status、create_time。物料表material包含id、code、name、spec、unit、category_id。仓库表warehouse包含id、name、location、manager。库存表inventory是核心字段为id、material_id、warehouse_id、quantity、locked_quantity、update_time并在(material_id, warehouse_id)上建唯一索引防止同一物料在同一仓库出现多条库存记录。采购单表purchase_order和明细表purchase_order_item用主外键关联明细里记录物料、数量、单价。索引方面inventory的唯一索引是必须的purchase_order的order_no建唯一索引create_time建普通索引用于按时间范围查询。字符集统一用utf8mb4排序规则utf8mb4_general_ci避免中文和特殊符号乱码。3.2 用 MyBatis 写库存扣减乐观锁与条件更新的取舍库存扣减是供应链系统最容易出并发问题的地方。两种常见做法一是乐观锁在inventory表加version字段更新时where id #{id} and version #{version}失败则重试二是条件更新直接update inventory set quantity quantity - #{num} where material_id #{mid} and warehouse_id #{wid} and quantity #{num}根据返回的影响行数判断是否成功。条件更新更简单适合库存量不大、并发不极端的场景。下面是一个 Mapper 接口和 XML 片段。Mapper public interface InventoryMapper { int deductStock(Param(materialId) Long materialId, Param(warehouseId) Long warehouseId, Param(num) Integer num); }update iddeductStock update inventory set quantity quantity - #{num}, update_time now() where material_id #{materialId} and warehouse_id #{warehouseId} and quantity #{num} /updateService 层调用后判断返回值如果为 0 说明库存不足或并发冲突抛出业务异常并回滚事务。参数说明materialId和warehouseId定位库存记录num是扣减数量quantity #{num}是防止超卖的关键条件。注意不要在 Java 里先查再减那样在并发下必然出问题。如果业务要求锁定库存可以增加locked_quantity字段下单时增加锁定出库时扣减实际库存并释放锁定逻辑更复杂但更贴近真实供应链场景。3.3 采购入库的事务边界与异常回滚验证采购入库涉及三张表更新采购单状态为“已入库”、增加库存、插入库存流水。这三步必须在同一个事务里。Service 方法上加Transactional(rollbackFor Exception.class)任何一步抛异常都整体回滚。验证事务是否生效可以在插入流水后手动抛一个 RuntimeException观察采购单状态和库存是否回到操作前。常见坑是 Mapper 方法被同类内部调用导致代理失效、事务不生效。解决办法是把事务方法放到独立的 Service 类里或者用AopContext.currentProxy()获取代理对象。另一个坑是 MySQL 的 autocommit 默认开启Spring 事务会先关闭 autocommit 再执行如果数据源配置了defaultAutoCommittrue且事务管理器没接管可能出现部分提交。检查DataSourceTransactionManager是否配置正确日志里打开org.springframework.transaction的 DEBUG 级别可以看到事务开启和提交记录。4. 权限控制与工作流供应链系统绕不开的两块硬骨头4.1 行级权限在 Java 里怎么落地从角色到数据过滤供应链系统里不同角色看到的数据范围不同。采购员只能看自己创建的采购单仓库管理员只能看自己仓库的库存财务能看所有结算单但不能改库存。这种行级权限如果只靠前端隐藏菜单后端接口裸奔等于没做。常见做法是在 Service 层拼接数据过滤条件比如查询采购单时根据当前用户角色动态加and create_by #{userId}或and warehouse_id in (...)。更优雅的方式是用 MyBatis 拦截器或 Spring AOP在 SQL 执行前统一注入权限条件。下面是一个简单的 AOP 思路定义DataScope注解在 Mapper 方法上标注拦截器解析当前用户和角色修改 SQL 的 where 条件。参数上用户上下文用 ThreadLocal 存储请求进入时由拦截器从 Token 解析并放入请求结束清除。注意 ThreadLocal 在异步任务和线程池里会丢失如果用了Async或定时任务需要手动传递用户上下文。4.2 基于状态机的采购审批流用 Java 枚举替代重型工作流引擎很多供应链项目一上来就想引入 Activiti 或 Flowable结果配置复杂、学习成本高最后只用到最简单的审批。如果审批节点固定、分支不多用 Java 枚举加状态机更轻量。定义PurchaseOrderStatus枚举DRAFT、PENDING_APPROVAL、APPROVED、REJECTED、RECEIVED。每个状态允许的迁移写在枚举方法里Service 层调用status.next(event)获取下一状态非法迁移直接抛异常。这样审批逻辑集中在枚举里测试好写数据库只存状态字符串。如果后续节点变多再迁移到工作流引擎也不迟。常见坑是把状态判断散落在各个 Service 方法里改一个流程要翻十几个文件。集中到枚举后新增状态只需改一处。4.3 定时任务与库存预警用 Spring Task 还是 Quartz供应链系统需要定时检查库存低于安全库存的物料并生成预警。Spring Task 的Scheduled注解足够应对单机定时任务配置cron表达式即可。如果任务需要持久化、集群防重复执行、动态修改执行时间才考虑 Quartz。单机项目用 Spring Task在启动类加EnableScheduling写一个StockWarningTask组件每天凌晨两点执行查询。注意定时任务里如果调用Transactional方法事务同样生效但任务方法本身不要加事务否则长事务占用连接。预警生成后可以插入warning表前端轮询或 WebSocket 推送。集群环境下 Spring Task 会在每个节点都执行导致重复预警这时要么用数据库唯一约束去重要么换 Quartz 的集群模式。5. 避坑与排查供应链系统开发中常见的五类翻车现场5.1 库存扣成负数现象、原因与解决现象是并发测试时库存出现负值或者明明库存足够却提示不足。原因通常是先查后减两个线程同时查到库存 10各自扣 8结果 -6。解决方法是改用条件更新where quantity #{num}根据影响行数判断。如果已经出现负库存先写脚本把负值修正为 0再排查所有扣减入口是否都走了条件更新。另外检查数据库字段是否用了无符号整数unsigned在减到负数时会报错而不是存负值这也是一种保护。5.2 事务不回滚现象、原因与解决现象是采购入库时库存加了但采购单状态没变或者抛异常后数据部分提交。原因可能是异常类型不在回滚范围内比如抛了受检异常但没配rollbackFor也可能是方法内部调用导致代理失效还可能是数据库表用了 MyISAM 引擎不支持事务。解决方法是显式写Transactional(rollbackFor Exception.class)把事务方法抽到独立 Bean建表时统一用 InnoDB。排查时打开 Spring 事务日志看是否有 “Participating in existing transaction” 或 “Initiating transaction rollback” 的记录。5.3 分页查询慢现象、原因与解决现象是采购单列表翻到后面几页越来越慢或者库存流水查询超时。原因是limit offset, size在 offset 很大时要扫描大量行加上多表联查和order by没有合适索引。解决方法是给排序字段建索引比如create_time或者改用游标分页用上一页最后一条记录的 id 作为下一页的起点。MyBatis-Plus 的分页插件默认用limit数据量大时建议手写where id #{lastId} order by id limit #{size}。另外避免在分页查询里做count(*)全表统计可以缓存总数或估算。5.4 中文乱码现象、原因与解决现象是供应商名称或物料规格在页面显示问号或者接口返回的 JSON 里中文变成\uXXXX。原因是数据库字符集不是utf8mb4或者 JDBC URL 没加characterEncodingutf8或者 HTTP 响应头没指定charsetUTF-8。解决方法是建库建表统一utf8mb4JDBC URL 加useUnicodetruecharacterEncodingutf8Spring Boot 的server.servlet.encoding.charsetUTF-8和forcetrue。如果已经建表用alter table ... convert to character set utf8mb4修改。5.5 定时任务重复执行现象、原因与解决现象是库存预警每天生成两条相同记录或者集群部署后每个节点都跑一遍。原因是 Spring Task 默认在每个节点都执行没有分布式锁。解决方法是加数据库唯一约束比如warning表对(material_id, warning_date)建唯一索引插入时用insert ignore或捕获重复键异常。或者引入 Redis 分布式锁任务执行前抢锁抢到才执行。单机环境检查是否重复配置了Scheduled方法或者cron表达式写错导致一分钟内触发多次。6. 从能跑到好用供应链系统的验证方法与一个压测技巧系统能跑通业务后怎么验证它真的可靠我一般会做三件事第一写集成测试覆盖核心链路用SpringBootTest加Transactional让每个测试方法自动回滚测试采购入库、库存扣减、审批流转。第二用 JMeter 或 wrk 对库存扣减接口做并发压测观察是否出现超卖和响应时间飙升。第三检查所有查询接口的 SQL 执行计划用explain看是否走索引。这里分享一个压测技巧不要一上来就压全链路先单独压库存扣减接口把并发数从 10 逐步加到 100观察数据库连接池和 CPU。如果响应时间在 50ms 以内且库存无负数再压采购单创建和查询。压测数据要提前准备比如 1000 个物料、10 个仓库、每个仓库 10000 库存用脚本批量插入。-- 批量生成测试库存数据 INSERT INTO inventory (material_id, warehouse_id, quantity, locked_quantity, update_time) SELECT m.id, w.id, 10000, 0, NOW() FROM material m CROSS JOIN warehouse w WHERE m.id 1000 AND w.id 10;这段 SQL 用交叉连接生成 10000 条库存记录material_id和warehouse_id组合唯一不会重复。压测时随机选material_id和warehouse_id调用扣减接口每次扣 1跑完后检查quantity是否等于初始值减去成功请求数。如果对不上说明有并发问题或事务问题。另外压测环境不要和生产共用数据库避免影响真实数据。最后说一个我自己的习惯每次改完库存相关的代码不管多小的改动都会在本地跑一遍并发扣减的单元测试用CountDownLatch模拟 100 个线程同时扣同一件库存断言最终库存等于初始值减 100。这个习惯帮我拦住了好几次“看起来没问题”的提交。供应链系统的数据一致性没有后悔药测试多花十分钟上线少熬一个通宵。希望帮到你。本文还有配套的精品资源点击获取