简介这份资源是一套基于Java技术栈的采购管理系统完整源码面向需要完成课程设计、毕业设计或进销存项目练手的开发者。系统采用JSP构建企业采购信息管理平台围绕用户登录、供应商管理、材料管理三大模块展开其中登录模块通过用户名密码校验实现权限区分普通用户与超级管理员进入不同操作页面供应商管理支持供货商信息的灵活增删改材料管理则覆盖材料种类与库存维护适合作为Java Web入门到进阶的实战参考。压缩包为rar格式共248个文件约22.71MB包含32个java源文件、30个jsp页面、35个class编译文件、63个jar依赖包以及xml配置、gif与png图片、css样式、properties配置等源码与运行依赖相对完整。目前已有2659人学习下载读者可据此梳理Action、Service分层结构与数据库交互逻辑快速理解采购管理系统的整体实现思路。1. 从一份 .rar 说起Java 采购管理系统到底要解决什么很多人第一次拿到「Java实现采购管理系统含数据库.rar」这类压缩包第一反应是解压、找 main 方法、点运行然后被一堆ClassNotFoundException和数据库连接失败劝退。我当年也是这样血泪经验告诉我采购管理系统不是「跑起来就完事」的练手项目它是一套把「请购 → 审批 → 下单 → 入库 → 对账」串起来的业务闭环数据库设计一旦翻车后面所有增删改查都是给错误结构打补丁。这个标题背后真正要落地的东西有三层一是用 Java多数是 Spring Boot MyBatis 或 MyBatis-Plus把采购单、供应商、物料、库存、审批流这几张核心表管起来二是数据库要能支撑「数据库增删改查」之外的事务一致性比如入库和库存扣减必须同生共死三是给后续扩展留口子比如对接托管数据库服务、做数据库同步、加行级权限。适合谁适合刚学完 Java 基础、想拿一个真实业务练手的人也适合工作两三年、需要快速搭一套内部采购台账的工程师。下面我按「先立结构、再动手、最后避坑」的顺序把能抄作业的部分全写出来。2. 数据库表结构与 Java 实体映射采购系统的地基怎么打采购系统的复杂度不在代码在表关系。我见过太多人一上来就写 Controller结果物料和供应商是多对多还是多对一都没想清楚最后数据库里全是冗余字段。先把地基打对后面 MyBatis-Plus 生成 SQL、写增删改查都是顺水推舟。2.1 五张核心表的最小可用设计一套能跑通采购流程的最小表集合是供应商表、物料表、采购单主表、采购单明细表、库存流水表。审批流如果简单可以先在采购单主表加status字段扛着别一上来就上工作流引擎那是给自己找麻烦。表名关键字段说明supplierid, name, contact, phone, status供应商status 控制启用停用materialid, name, spec, unit, price物料price 是参考单价purchase_orderid, order_no, supplier_id, status, total_amount, create_time采购单主表purchase_order_itemid, order_id, material_id, quantity, price明细价格以明细为准stock_recordid, material_id, change_qty, type, ref_order_id库存流水type 区分入库/出库这里有个关键决策采购单的金额不要只存主表明细里也要存单价和数量主表的total_amount是明细汇总的结果。为什么因为供应商改价、部分入库时你需要能追溯每一行的实际成交价只存一个总数对账时就是黑匣子。2.2 用 MyBatis-Plus 从实体类反推建表 SQL热搜里常出现「mybatisplus根据java实体类生成创建表的sql语句」这确实是省事的路子。但我要提醒自动生成适合快速起步生产环境还是建议手写 DDL 并纳入版本管理。下面给出实体类和对应的建表语句你可以两边对照着改。// PurchaseOrder.java Data TableName(purchase_order) public class PurchaseOrder { TableId(type IdType.AUTO) private Long id; private String orderNo; // 采购单号业务唯一 private Long supplierId; // 关联 supplier.id private Integer status; // 0待审 1已审 2已入库 3已取消 private BigDecimal totalAmount;// 明细汇总金额 private LocalDateTime createTime; }-- 对应的建表语句注意金额用 decimal 不用 float CREATE TABLE purchase_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 采购单号, supplier_id BIGINT NOT NULL COMMENT 供应商ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审1已审2入库3取消, total_amount DECIMAL(14,2) NOT NULL DEFAULT 0.00, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_supplier (supplier_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明order_no加唯一索引防止并发下重复下单supplier_id加普通索引因为按供应商查采购单是高频操作金额字段用DECIMAL(14,2)用FLOAT或DOUBLE做金额计算迟早出现0.10.2≠0.3的玄学问题。参数上status用TINYINT而不是字符串省空间也方便比较create_time交给数据库默认值避免 Java 端时区不一致。2.3 明细表与库存流水的联动约束明细表和库存流水是采购系统最容易出问题的地方。明细表要存「下单时的价格快照」库存流水要存「每一次变动的方向和来源」。CREATE TABLE purchase_order_item ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, material_id BIGINT NOT NULL, quantity INT NOT NULL, price DECIMAL(12,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE stock_record ( id BIGINT NOT NULL AUTO_INCREMENT, material_id BIGINT NOT NULL, change_qty INT NOT NULL COMMENT 正数入库负数出库, type TINYINT NOT NULL COMMENT 1采购入库2领用出库, ref_order_id BIGINT DEFAULT NULL COMMENT 来源采购单, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_material (material_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;change_qty用正负号表示方向比再开一个direction字段更省事但查询时要小心SUM的语义。ref_order_id允许为空因为领用出库不一定关联采购单。这两张表都不设外键约束靠应用层保证一致性——这是互联网项目的常见做法外键在高并发写入时容易造成锁竞争但代价是你必须在 Service 层用事务兜住。3. 采购流程的 Java 实现从请购到入库的事务闭环表建好之后真正体现功力的是 Service 层。采购系统最典型的操作是「审批通过后入库」这一步要同时改采购单状态、写库存流水、更新库存余量任何一步失败都必须回滚。下面把核心代码拆开讲。3.1 采购单创建与明细批量插入创建采购单时主表和明细必须一起成功。用Transactional包住明细用 MyBatis-Plus 的saveBatch。Service public class PurchaseOrderService { Autowired private PurchaseOrderMapper orderMapper; Autowired private PurchaseOrderItemMapper itemMapper; Transactional(rollbackFor Exception.class) public Long createOrder(PurchaseOrderDTO dto) { PurchaseOrder order new PurchaseOrder(); order.setOrderNo(generateOrderNo()); // 业务规则生成单号 order.setSupplierId(dto.getSupplierId()); order.setStatus(0); // 待审 order.setTotalAmount(BigDecimal.ZERO); orderMapper.insert(order); BigDecimal total BigDecimal.ZERO; for (PurchaseOrderItemDTO item : dto.getItems()) { PurchaseOrderItem entity new PurchaseOrderItem(); entity.setOrderId(order.getId()); entity.setMaterialId(item.getMaterialId()); entity.setQuantity(item.getQuantity()); entity.setPrice(item.getPrice()); itemMapper.insert(entity); // 明细金额累加用 multiply 不用手算 total total.add(item.getPrice() .multiply(BigDecimal.valueOf(item.getQuantity()))); } order.setTotalAmount(total); orderMapper.updateById(order); // 回写汇总金额 return order.getId(); } }逻辑说明先插主表拿到自增id再插明细最后回写总金额。rollbackFor Exception.class是关键默认 Spring 只对RuntimeException回滚受检异常不回滚这个坑我踩过不止一次。参数上generateOrderNo()建议用「日期 序列」而不是 UUID方便人工核对金额累加用BigDecimal.multiply和add全程不碰double。3.2 审批通过后入库一个必须原子化的操作入库是采购系统的核心动作。它要做三件事把采购单状态改成「已入库」、给每个明细写一条库存流水、更新物料库存余量。这三件事必须在一个事务里。Transactional(rollbackFor Exception.class) public void stockIn(Long orderId) { PurchaseOrder order orderMapper.selectById(orderId); if (order null || order.getStatus() ! 1) { throw new BizException(采购单状态不允许入库); } ListPurchaseOrderItem items itemMapper.selectList(new LambdaQueryWrapperPurchaseOrderItem() .eq(PurchaseOrderItem::getOrderId, orderId)); for (PurchaseOrderItem item : items) { StockRecord record new StockRecord(); record.setMaterialId(item.getMaterialId()); record.setChangeQty(item.getQuantity()); // 入库为正 record.setType(1); record.setRefOrderId(orderId); stockRecordMapper.insert(record); // 更新库存余量用 SQL 原子自增避免并发覆盖 materialMapper.update(null, new LambdaUpdateWrapperMaterial() .setSql(stock stock item.getQuantity()) .eq(Material::getId, item.getMaterialId())); } order.setStatus(2); orderMapper.updateById(order); }逻辑说明状态校验放在最前面防止重复入库。库存更新用setSql(stock stock N)让数据库做原子自增而不是先查再改后者在并发下会丢更新。参数上type1表示采购入库和前面表设计对应refOrderId记录来源方便日后追溯。这里没有用外键所以如果materialId不存在插入流水不会报错需要在业务层加校验。3.3 分页查询与条件组合的写法采购单列表通常要支持按供应商、状态、时间范围筛选还要分页。MyBatis-Plus 的Page配合LambdaQueryWrapper能写得很干净。public PagePurchaseOrderVO pageQuery(OrderQuery query) { PagePurchaseOrder page new Page(query.getPageNo(), query.getPageSize()); LambdaQueryWrapperPurchaseOrder wrapper new LambdaQueryWrapper(); wrapper.eq(query.getSupplierId() ! null, PurchaseOrder::getSupplierId, query.getSupplierId()) .eq(query.getStatus() ! null, PurchaseOrder::getStatus, query.getStatus()) .ge(query.getStartTime() ! null, PurchaseOrder::getCreateTime, query.getStartTime()) .le(query.getEndTime() ! null, PurchaseOrder::getCreateTime, query.getEndTime()) .orderByDesc(PurchaseOrder::getCreateTime); return orderMapper.selectPage(page, wrapper); }逻辑说明每个条件都带! null判断避免拼出WHERE supplier_id null这种查不到数据的语句。orderByDesc按创建时间倒序符合「最新单据在最上面」的使用习惯。参数上pageNo从 1 开始pageSize建议在接口层限制上限比如 100防止有人传pageSize100000把数据库拖垮。4. 避坑与排查采购系统上线前必须过的五道坎代码能跑通不代表能用。下面这五条是我在真实项目里踩出来的每条都按「现象 → 原因 → 解决」写你对照着自查。4.1 现象入库后库存对不上明细和余量差几件原因库存余量更新和流水写入不在同一事务或者用了「先查再改」导致并发丢更新。另一个常见原因是明细数量用了int但前端传了小数被截断。解决把入库逻辑收进一个Transactional方法库存更新统一用stock stock N的原子写法。数量字段在 DTO 层就用Integer并加校验拒绝小数。上线前跑一次「流水汇总 当前库存」的对账 SQL对不上就说明有历史脏数据。4.2 现象采购单号重复插入报唯一键冲突原因单号生成用了时间戳高并发下同一毫秒生成相同单号或者用了 UUID 但截断后碰撞。解决单号生成改成「日期 数据库序列」或 Redis 自增别用纯时间戳。数据库层保留uk_order_no唯一索引作为最后防线捕获DuplicateKeyException后重试一次。我一般会在 Service 里包一层重试最多三次。4.3 现象数据库连接池耗尽接口大面积超时原因Transactional方法里做了远程调用或文件操作事务持有连接时间过长或者连接池最大连接数设得太小。解决事务方法里只做数据库操作远程调用挪到事务外。连接池参数上maximumPoolSize按「CPU 核数 × 2 磁盘数」估算再结合压测调。监控上打开连接池的leakDetectionThreshold超过阈值打印堆栈能快速定位谁没释放连接。4.4 现象审批状态乱跳已入库的单子还能被取消原因状态流转没有做前置校验任何接口都能改status。解决把状态流转规则集中到一个OrderStatusMachine类里定义「待审 → 已审 → 已入库」的单向流转取消只能从待审或已审发起。所有改状态的入口都走这个类别在 Controller 里直接setStatus。这是行级权限和审批流的基础。4.5 现象金额出现 0.01 的误差对账对不平原因金额计算混用了double或者汇总时四舍五入的时机不对。解决全链路用BigDecimal数据库用DECIMAL。汇总时先累加再setScale(2, RoundingMode.HALF_UP)不要每行先舍入再累加。对账时用 SQL 的SUM和 Java 端汇总交叉验证差一分钱都要查清楚。5. 进阶技巧用对账 SQL 和慢查询日志守住数据质量系统跑起来之后真正让你睡得着觉的不是功能多全而是数据对不对。我现在的习惯是每个采购系统上线前先写好三条对账 SQL再打开慢查询日志这两样东西比任何监控面板都实在。第一条对账 SQL校验库存余量和流水汇总是否一致SELECT m.id, m.name, m.stock, IFNULL(SUM(r.change_qty), 0) AS flow_sum FROM material m LEFT JOIN stock_record r ON r.material_id m.id GROUP BY m.id, m.name, m.stock HAVING m.stock IFNULL(SUM(r.change_qty), 0);这条语句查出来的每一行都是「账实不符」的物料。LEFT JOIN保证没有流水的物料也能被查出来HAVING过滤掉一致的行。建议做成定时任务每天凌晨跑一次结果推送到运维群。第二条校验采购单主表金额和明细汇总是否一致SELECT o.id, o.order_no, o.total_amount, IFNULL(SUM(i.price * i.quantity), 0) AS item_sum FROM purchase_order o LEFT JOIN purchase_order_item i ON i.order_id o.id GROUP BY o.id, o.order_no, o.total_amount HAVING o.total_amount IFNULL(SUM(i.price * i.quantity), 0);这条能抓出「主表金额被手工改过」或「明细插入失败但主表已提交」的脏数据。注意price * quantity在 MySQL 里会自动转DECIMAL但如果你price建表时用了FLOAT这里就会出误差所以前面强调金额字段必须DECIMAL。第三条查长时间处于「已审未入库」的单子防止漏入库SELECT id, order_no, supplier_id, create_time FROM purchase_order WHERE status 1 AND create_time DATE_SUB(NOW(), INTERVAL 7 DAY);status 1是已审超过 7 天还没入库要么是仓库忘了要么是流程卡住了。这条 SQL 配合定时提醒能省掉很多人工核对。慢查询日志方面MySQL 打开slow_query_log把long_query_time设成 1 秒跑一周后看mysqldumpslow的汇总。采购系统里最慢的通常是「按供应商 时间范围 状态」的组合查询如果没走对索引全表扫描几万行就上秒了。解决办法是按查询条件建联合索引比如(supplier_id, status, create_time)注意字段顺序要和查询条件的区分度匹配——区分度高的放前面。最后说一个我自己的习惯每次改完表结构或索引先在测试库用生产数据量跑一遍对账 SQL 和慢查询确认没问题再上。数据库这东西没有后悔药ALTER TABLE在大表上锁几分钟业务就停几分钟。宁可多花半小时在测试库验证也别在生产库赌运气。希望帮到你。本文还有配套的精品资源点击获取 Java采购管理系统实战：数据库设计与事务一致性避坑指南
简介这份资源是一套基于Java技术栈的采购管理系统完整源码面向需要完成课程设计、毕业设计或进销存项目练手的开发者。系统采用JSP构建企业采购信息管理平台围绕用户登录、供应商管理、材料管理三大模块展开其中登录模块通过用户名密码校验实现权限区分普通用户与超级管理员进入不同操作页面供应商管理支持供货商信息的灵活增删改材料管理则覆盖材料种类与库存维护适合作为Java Web入门到进阶的实战参考。压缩包为rar格式共248个文件约22.71MB包含32个java源文件、30个jsp页面、35个class编译文件、63个jar依赖包以及xml配置、gif与png图片、css样式、properties配置等源码与运行依赖相对完整。目前已有2659人学习下载读者可据此梳理Action、Service分层结构与数据库交互逻辑快速理解采购管理系统的整体实现思路。1. 从一份 .rar 说起Java 采购管理系统到底要解决什么很多人第一次拿到「Java实现采购管理系统含数据库.rar」这类压缩包第一反应是解压、找 main 方法、点运行然后被一堆ClassNotFoundException和数据库连接失败劝退。我当年也是这样血泪经验告诉我采购管理系统不是「跑起来就完事」的练手项目它是一套把「请购 → 审批 → 下单 → 入库 → 对账」串起来的业务闭环数据库设计一旦翻车后面所有增删改查都是给错误结构打补丁。这个标题背后真正要落地的东西有三层一是用 Java多数是 Spring Boot MyBatis 或 MyBatis-Plus把采购单、供应商、物料、库存、审批流这几张核心表管起来二是数据库要能支撑「数据库增删改查」之外的事务一致性比如入库和库存扣减必须同生共死三是给后续扩展留口子比如对接托管数据库服务、做数据库同步、加行级权限。适合谁适合刚学完 Java 基础、想拿一个真实业务练手的人也适合工作两三年、需要快速搭一套内部采购台账的工程师。下面我按「先立结构、再动手、最后避坑」的顺序把能抄作业的部分全写出来。2. 数据库表结构与 Java 实体映射采购系统的地基怎么打采购系统的复杂度不在代码在表关系。我见过太多人一上来就写 Controller结果物料和供应商是多对多还是多对一都没想清楚最后数据库里全是冗余字段。先把地基打对后面 MyBatis-Plus 生成 SQL、写增删改查都是顺水推舟。2.1 五张核心表的最小可用设计一套能跑通采购流程的最小表集合是供应商表、物料表、采购单主表、采购单明细表、库存流水表。审批流如果简单可以先在采购单主表加status字段扛着别一上来就上工作流引擎那是给自己找麻烦。表名关键字段说明supplierid, name, contact, phone, status供应商status 控制启用停用materialid, name, spec, unit, price物料price 是参考单价purchase_orderid, order_no, supplier_id, status, total_amount, create_time采购单主表purchase_order_itemid, order_id, material_id, quantity, price明细价格以明细为准stock_recordid, material_id, change_qty, type, ref_order_id库存流水type 区分入库/出库这里有个关键决策采购单的金额不要只存主表明细里也要存单价和数量主表的total_amount是明细汇总的结果。为什么因为供应商改价、部分入库时你需要能追溯每一行的实际成交价只存一个总数对账时就是黑匣子。2.2 用 MyBatis-Plus 从实体类反推建表 SQL热搜里常出现「mybatisplus根据java实体类生成创建表的sql语句」这确实是省事的路子。但我要提醒自动生成适合快速起步生产环境还是建议手写 DDL 并纳入版本管理。下面给出实体类和对应的建表语句你可以两边对照着改。// PurchaseOrder.java Data TableName(purchase_order) public class PurchaseOrder { TableId(type IdType.AUTO) private Long id; private String orderNo; // 采购单号业务唯一 private Long supplierId; // 关联 supplier.id private Integer status; // 0待审 1已审 2已入库 3已取消 private BigDecimal totalAmount;// 明细汇总金额 private LocalDateTime createTime; }-- 对应的建表语句注意金额用 decimal 不用 float CREATE TABLE purchase_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 采购单号, supplier_id BIGINT NOT NULL COMMENT 供应商ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审1已审2入库3取消, total_amount DECIMAL(14,2) NOT NULL DEFAULT 0.00, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_supplier (supplier_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明order_no加唯一索引防止并发下重复下单supplier_id加普通索引因为按供应商查采购单是高频操作金额字段用DECIMAL(14,2)用FLOAT或DOUBLE做金额计算迟早出现0.10.2≠0.3的玄学问题。参数上status用TINYINT而不是字符串省空间也方便比较create_time交给数据库默认值避免 Java 端时区不一致。2.3 明细表与库存流水的联动约束明细表和库存流水是采购系统最容易出问题的地方。明细表要存「下单时的价格快照」库存流水要存「每一次变动的方向和来源」。CREATE TABLE purchase_order_item ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, material_id BIGINT NOT NULL, quantity INT NOT NULL, price DECIMAL(12,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE stock_record ( id BIGINT NOT NULL AUTO_INCREMENT, material_id BIGINT NOT NULL, change_qty INT NOT NULL COMMENT 正数入库负数出库, type TINYINT NOT NULL COMMENT 1采购入库2领用出库, ref_order_id BIGINT DEFAULT NULL COMMENT 来源采购单, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_material (material_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;change_qty用正负号表示方向比再开一个direction字段更省事但查询时要小心SUM的语义。ref_order_id允许为空因为领用出库不一定关联采购单。这两张表都不设外键约束靠应用层保证一致性——这是互联网项目的常见做法外键在高并发写入时容易造成锁竞争但代价是你必须在 Service 层用事务兜住。3. 采购流程的 Java 实现从请购到入库的事务闭环表建好之后真正体现功力的是 Service 层。采购系统最典型的操作是「审批通过后入库」这一步要同时改采购单状态、写库存流水、更新库存余量任何一步失败都必须回滚。下面把核心代码拆开讲。3.1 采购单创建与明细批量插入创建采购单时主表和明细必须一起成功。用Transactional包住明细用 MyBatis-Plus 的saveBatch。Service public class PurchaseOrderService { Autowired private PurchaseOrderMapper orderMapper; Autowired private PurchaseOrderItemMapper itemMapper; Transactional(rollbackFor Exception.class) public Long createOrder(PurchaseOrderDTO dto) { PurchaseOrder order new PurchaseOrder(); order.setOrderNo(generateOrderNo()); // 业务规则生成单号 order.setSupplierId(dto.getSupplierId()); order.setStatus(0); // 待审 order.setTotalAmount(BigDecimal.ZERO); orderMapper.insert(order); BigDecimal total BigDecimal.ZERO; for (PurchaseOrderItemDTO item : dto.getItems()) { PurchaseOrderItem entity new PurchaseOrderItem(); entity.setOrderId(order.getId()); entity.setMaterialId(item.getMaterialId()); entity.setQuantity(item.getQuantity()); entity.setPrice(item.getPrice()); itemMapper.insert(entity); // 明细金额累加用 multiply 不用手算 total total.add(item.getPrice() .multiply(BigDecimal.valueOf(item.getQuantity()))); } order.setTotalAmount(total); orderMapper.updateById(order); // 回写汇总金额 return order.getId(); } }逻辑说明先插主表拿到自增id再插明细最后回写总金额。rollbackFor Exception.class是关键默认 Spring 只对RuntimeException回滚受检异常不回滚这个坑我踩过不止一次。参数上generateOrderNo()建议用「日期 序列」而不是 UUID方便人工核对金额累加用BigDecimal.multiply和add全程不碰double。3.2 审批通过后入库一个必须原子化的操作入库是采购系统的核心动作。它要做三件事把采购单状态改成「已入库」、给每个明细写一条库存流水、更新物料库存余量。这三件事必须在一个事务里。Transactional(rollbackFor Exception.class) public void stockIn(Long orderId) { PurchaseOrder order orderMapper.selectById(orderId); if (order null || order.getStatus() ! 1) { throw new BizException(采购单状态不允许入库); } ListPurchaseOrderItem items itemMapper.selectList(new LambdaQueryWrapperPurchaseOrderItem() .eq(PurchaseOrderItem::getOrderId, orderId)); for (PurchaseOrderItem item : items) { StockRecord record new StockRecord(); record.setMaterialId(item.getMaterialId()); record.setChangeQty(item.getQuantity()); // 入库为正 record.setType(1); record.setRefOrderId(orderId); stockRecordMapper.insert(record); // 更新库存余量用 SQL 原子自增避免并发覆盖 materialMapper.update(null, new LambdaUpdateWrapperMaterial() .setSql(stock stock item.getQuantity()) .eq(Material::getId, item.getMaterialId())); } order.setStatus(2); orderMapper.updateById(order); }逻辑说明状态校验放在最前面防止重复入库。库存更新用setSql(stock stock N)让数据库做原子自增而不是先查再改后者在并发下会丢更新。参数上type1表示采购入库和前面表设计对应refOrderId记录来源方便日后追溯。这里没有用外键所以如果materialId不存在插入流水不会报错需要在业务层加校验。3.3 分页查询与条件组合的写法采购单列表通常要支持按供应商、状态、时间范围筛选还要分页。MyBatis-Plus 的Page配合LambdaQueryWrapper能写得很干净。public PagePurchaseOrderVO pageQuery(OrderQuery query) { PagePurchaseOrder page new Page(query.getPageNo(), query.getPageSize()); LambdaQueryWrapperPurchaseOrder wrapper new LambdaQueryWrapper(); wrapper.eq(query.getSupplierId() ! null, PurchaseOrder::getSupplierId, query.getSupplierId()) .eq(query.getStatus() ! null, PurchaseOrder::getStatus, query.getStatus()) .ge(query.getStartTime() ! null, PurchaseOrder::getCreateTime, query.getStartTime()) .le(query.getEndTime() ! null, PurchaseOrder::getCreateTime, query.getEndTime()) .orderByDesc(PurchaseOrder::getCreateTime); return orderMapper.selectPage(page, wrapper); }逻辑说明每个条件都带! null判断避免拼出WHERE supplier_id null这种查不到数据的语句。orderByDesc按创建时间倒序符合「最新单据在最上面」的使用习惯。参数上pageNo从 1 开始pageSize建议在接口层限制上限比如 100防止有人传pageSize100000把数据库拖垮。4. 避坑与排查采购系统上线前必须过的五道坎代码能跑通不代表能用。下面这五条是我在真实项目里踩出来的每条都按「现象 → 原因 → 解决」写你对照着自查。4.1 现象入库后库存对不上明细和余量差几件原因库存余量更新和流水写入不在同一事务或者用了「先查再改」导致并发丢更新。另一个常见原因是明细数量用了int但前端传了小数被截断。解决把入库逻辑收进一个Transactional方法库存更新统一用stock stock N的原子写法。数量字段在 DTO 层就用Integer并加校验拒绝小数。上线前跑一次「流水汇总 当前库存」的对账 SQL对不上就说明有历史脏数据。4.2 现象采购单号重复插入报唯一键冲突原因单号生成用了时间戳高并发下同一毫秒生成相同单号或者用了 UUID 但截断后碰撞。解决单号生成改成「日期 数据库序列」或 Redis 自增别用纯时间戳。数据库层保留uk_order_no唯一索引作为最后防线捕获DuplicateKeyException后重试一次。我一般会在 Service 里包一层重试最多三次。4.3 现象数据库连接池耗尽接口大面积超时原因Transactional方法里做了远程调用或文件操作事务持有连接时间过长或者连接池最大连接数设得太小。解决事务方法里只做数据库操作远程调用挪到事务外。连接池参数上maximumPoolSize按「CPU 核数 × 2 磁盘数」估算再结合压测调。监控上打开连接池的leakDetectionThreshold超过阈值打印堆栈能快速定位谁没释放连接。4.4 现象审批状态乱跳已入库的单子还能被取消原因状态流转没有做前置校验任何接口都能改status。解决把状态流转规则集中到一个OrderStatusMachine类里定义「待审 → 已审 → 已入库」的单向流转取消只能从待审或已审发起。所有改状态的入口都走这个类别在 Controller 里直接setStatus。这是行级权限和审批流的基础。4.5 现象金额出现 0.01 的误差对账对不平原因金额计算混用了double或者汇总时四舍五入的时机不对。解决全链路用BigDecimal数据库用DECIMAL。汇总时先累加再setScale(2, RoundingMode.HALF_UP)不要每行先舍入再累加。对账时用 SQL 的SUM和 Java 端汇总交叉验证差一分钱都要查清楚。5. 进阶技巧用对账 SQL 和慢查询日志守住数据质量系统跑起来之后真正让你睡得着觉的不是功能多全而是数据对不对。我现在的习惯是每个采购系统上线前先写好三条对账 SQL再打开慢查询日志这两样东西比任何监控面板都实在。第一条对账 SQL校验库存余量和流水汇总是否一致SELECT m.id, m.name, m.stock, IFNULL(SUM(r.change_qty), 0) AS flow_sum FROM material m LEFT JOIN stock_record r ON r.material_id m.id GROUP BY m.id, m.name, m.stock HAVING m.stock IFNULL(SUM(r.change_qty), 0);这条语句查出来的每一行都是「账实不符」的物料。LEFT JOIN保证没有流水的物料也能被查出来HAVING过滤掉一致的行。建议做成定时任务每天凌晨跑一次结果推送到运维群。第二条校验采购单主表金额和明细汇总是否一致SELECT o.id, o.order_no, o.total_amount, IFNULL(SUM(i.price * i.quantity), 0) AS item_sum FROM purchase_order o LEFT JOIN purchase_order_item i ON i.order_id o.id GROUP BY o.id, o.order_no, o.total_amount HAVING o.total_amount IFNULL(SUM(i.price * i.quantity), 0);这条能抓出「主表金额被手工改过」或「明细插入失败但主表已提交」的脏数据。注意price * quantity在 MySQL 里会自动转DECIMAL但如果你price建表时用了FLOAT这里就会出误差所以前面强调金额字段必须DECIMAL。第三条查长时间处于「已审未入库」的单子防止漏入库SELECT id, order_no, supplier_id, create_time FROM purchase_order WHERE status 1 AND create_time DATE_SUB(NOW(), INTERVAL 7 DAY);status 1是已审超过 7 天还没入库要么是仓库忘了要么是流程卡住了。这条 SQL 配合定时提醒能省掉很多人工核对。慢查询日志方面MySQL 打开slow_query_log把long_query_time设成 1 秒跑一周后看mysqldumpslow的汇总。采购系统里最慢的通常是「按供应商 时间范围 状态」的组合查询如果没走对索引全表扫描几万行就上秒了。解决办法是按查询条件建联合索引比如(supplier_id, status, create_time)注意字段顺序要和查询条件的区分度匹配——区分度高的放前面。最后说一个我自己的习惯每次改完表结构或索引先在测试库用生产数据量跑一遍对账 SQL 和慢查询确认没问题再上。数据库这东西没有后悔药ALTER TABLE在大表上锁几分钟业务就停几分钟。宁可多花半小时在测试库验证也别在生产库赌运气。希望帮到你。本文还有配套的精品资源点击获取