简介这份资源是面向高校计算机专业学生与Java Web开发学习者的社区生鲜配送系统完整项目源码围绕大学生及周边居民在线购买生鲜的场景覆盖用户管理、商品管理、订单处理、库存控制、配送调度、支付接口、数据分析、客户服务与移动端适配等核心业务模块适合作为课程设计、毕业设计或SSM/Spring Boot实战练手参考。压缩包共909个文件约1.61MB以html页面、css样式、js脚本与png/gif图片构成前端展示层120个java源文件与152个class文件对应后台控制器与业务逻辑另有sql建表脚本、xml与yml配置文件及json数据文件目录结构清晰便于按模块检索。已有139人学习下载读者可从中获取一套可直接运行的三层架构项目骨架、完整的数据库设计与实体关系、后台管理端增删改查实现思路以及订单状态流转、库存扣减与配送调度的具体编码参考便于对照理解并二次开发。1. 高校社区生鲜配送系统一份能跑通“下单—分拣—配送”全链路的源码包很多做课程设计或接私活的开发者一提到“生鲜配送系统”就头大订单要按小区聚合、库存要按批次扣减、配送要按路线分单三件事搅在一起写出来的代码往往只能演示不能落地。这份《高校社区生鲜配送系统.zip》解决的正是这个痛点——它把“用户下单、仓库分拣、骑手配送”这条主链路拆成了可独立调试的模块适合计算机专业做毕业设计的学生、想练手完整业务闭环的初级后端以及需要快速搭一套社区团购原型的从业者。我拆包跑了一遍前后端分离、数据库脚本齐全最值得看的是订单状态机和库存扣减这两块坑基本都埋在那里。下面按“它是什么—怎么跑起来—哪里会翻车”的顺序讲透。2. 系统架构与数据模型先看懂表结构再动手拿到一个陌生源码包我一般不会急着npm install而是先翻数据库脚本。表结构看不懂后面调接口全是盲人摸象。这个项目的核心表不多但字段设计有几个地方值得单独拎出来说。2.1 六张核心表撑起整条链路打开sql/目录下的建表脚本能理出六张主表用户表、商品表、库存批次表、订单主表、订单明细表、配送任务表。真正决定系统能不能跑通的是后四张之间的关联关系。表名关键字段作用易错点productid、name、price、unit商品基础信息价格用decimal(10,2)别用 floatstock_batchproduct_id、batch_no、quantity、expire_at按批次管理库存生鲜必须带保质期扣减要先进先出order_mainorder_no、user_id、status、community_id订单主记录status是状态机核心别随意加值order_itemorder_id、product_id、batch_id、qty订单明细必须记录实际扣减的批次号方便追溯delivery_taskorder_id、rider_id、route_seq、status配送任务route_seq决定同一小区内的配送顺序这里有个设计取舍值得说库存没有直接挂在product表上而是单独拆了stock_batch。生鲜场景下同一商品不同批次进价和保质期都不同扣库存必须按批次先进先出否则会出现“新货先出、旧货烂仓”的玄学问题。订单明细里存batch_id就是为了事后能查清每一单到底扣了哪批货出问题时有据可查。2.2 订单状态机五个状态不能乱跳order_main.status的取值在代码里是硬编码的我数了一下共五个待支付、已支付待分拣、分拣完成待配送、配送中、已完成。状态流转集中在service/OrderService里用了一个简单的switch做校验。// OrderService.java 状态流转核心逻辑节选 public void transitStatus(Long orderId, OrderStatus target) { OrderMain order orderMapper.selectById(orderId); OrderStatus current order.getStatus(); // 只允许按预设路径前进禁止回退和跳级 if (!current.canTransitTo(target)) { throw new BizException(非法状态流转: current - target); } order.setStatus(target); orderMapper.updateById(order); // 状态变更后触发对应副作用分拣、派单、通知 statusHandlerMap.get(target).handle(order); }这段代码的逻辑说明canTransitTo是一个枚举方法内部维护了允许的下一状态集合比如“待支付”只能到“已支付待分拣”“配送中”只能到“已完成”。参数target是目标状态传错直接抛业务异常。这样写的好处是把状态规则收在一处坏处是新增状态要改枚举和 handler 两处扩展时容易漏。我一般会在枚举里加一个ListOrderStatus nextStates字段把规则数据化比switch好维护。2.3 库存扣减放在哪一层一个容易吵起来的问题项目把库存扣减放在OrderService.createOrder里下单即扣。这在高校社区场景下是合理的——下单量小、并发低先扣后付能防止超卖。但如果照搬到高并发场景就会翻车后面避坑章节细说。扣减逻辑本身用了UPDATE ... WHERE quantity ?的乐观写法-- 扣减指定批次库存影响行数为 0 说明库存不足 UPDATE stock_batch SET quantity quantity - #{qty} WHERE id #{batchId} AND quantity #{qty};参数说明batchId来自分拣时选定的批次qty是订单明细数量。靠数据库行锁保证原子性影响行数为 0 时上层抛“库存不足”。这种写法比先SELECT再UPDATE安全但前提是批次要选对——选批次的逻辑在StockService.pickBatch里按expire_at升序取第一个够量的批次这就是先进先出的落地。3. 本地跑通全流程从建库到下单成功看懂表结构后就可以动手了。这个包是前后端分离的后端 Spring Boot、前端 Vue数据库 MySQL 8。我按实际跑通的顺序写命令可以直接抄。3.1 环境准备与建库先确认本机有 JDK 8、Maven 3.6、Node 14、MySQL 8。版本别贪新我试过 JDK 17 跑这个包有个老版本依赖会报模块访问异常换回 JDK 8 就没事。# 1. 建库并导入表结构和初始数据 mysql -uroot -p -e CREATE DATABASE fresh_delivery DEFAULT CHARSET utf8mb4; mysql -uroot -p fresh_delivery sql/schema.sql mysql -uroot -p fresh_delivery sql/data.sql # 2. 改后端数据库配置 # 编辑 src/main/resources/application-dev.yml # spring.datasource.url / username / password 三处改成自己的 # 3. 启动后端 mvn clean package -DskipTests java -jar target/fresh-delivery-1.0.jar --spring.profiles.activedev逻辑说明schema.sql只建表data.sql灌了三个小区、二十个商品和几个测试账号分开导入方便你只重置数据不动结构。application-dev.yml里默认连的是localhost:3306/fresh_delivery账号密码是占位符不改必报连接失败。启动参数--spring.profiles.activedev不能省否则会去读生产配置。3.2 前端启动与接口联调后端起来后默认 8080前端在web/目录下cd web npm install # 开发环境接口地址在 .env.development 里默认指向 http://localhost:8080 npm run serve前端跑在 8081登录页用data.sql里的测试账号手机号加验证码验证码在开发模式下固定为 1234写在AuthController的注释里。登录后进商品列表选一个小区、加购、下单能看到订单状态从“待支付”变成“已支付待分拣”——这一步能走通说明订单、库存、状态机三条线都通了。3.3 用接口脚本验证分拣和配送页面点一遍只能验证主流程分拣和配送的边界得用接口脚本压。项目自带docs/api.http我用 curl 复现了关键几步# 1. 管理员登录拿 token TOKEN$(curl -s -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {phone:13800000001,code:1234} | jq -r .data.token) # 2. 查询待分拣订单 curl -s http://localhost:8080/api/admin/orders?statusPAID_WAIT_PICK \ -H Authorization: $TOKEN | jq .data[].orderNo # 3. 对指定订单执行分拣会自动选批次扣库存 curl -s -X POST http://localhost:8080/api/admin/orders/1/pick \ -H Authorization: $TOKEN # 4. 生成配送任务并分配骑手 curl -s -X POST http://localhost:8080/api/admin/delivery/dispatch \ -H Authorization: $TOKEN \ -H Content-Type: application/json \ -d {communityId:1,riderId:2}参数说明第 3 步的1是订单主键分拣接口内部会调StockService.pickBatch逐条明细选批次任何一条库存不足整个分拣回滚。第 4 步的communityId决定按哪个小区聚合订单riderId是骑手用户 id派单后delivery_task.route_seq会按订单创建时间排序生成。跑完这四步数据库里订单状态应该是“配送中”stock_batch对应批次数量减少delivery_task多出一条记录——三张表对得上链路才算真通。4. 避坑与排查五个我实际踩过的坑这套代码逻辑不算复杂但生鲜业务本身的特殊性会放大一些细节问题。下面五条都是我跑的时候真实遇到的按“现象—原因—解决”记下来你大概率也会撞上。4.1 下单成功但库存没减事务没生效现象调下单接口返回成功订单表有记录但stock_batch.quantity纹丝不动。原因createOrder方法上标了Transactional但类内部另一个方法通过this.调用它Spring 的代理没拦住事务根本没开。解决把扣库存逻辑抽到独立的StockService里注入调用或者用AopContext.currentProxy()拿代理对象。我一般选前者干净。4.2 分拣时提示库存不足但页面显示有货批次选错现象商品总库存明明够分拣却报“库存不足”。原因pickBatch按expire_at升序选批次如果最早过期的批次量不够它不会自动跨批次凑直接返回失败。解决这是设计上的简化单批次不够时应拆成多条明细跨批次扣减。改法是在pickBatch里循环取批次直到凑够数量每取一批生成一条order_item的批次分摊记录。不改的话运营上就得保证单批次量大于单笔订单量。4.3 同一小区订单配送顺序乱route_seq 没重排现象派单后骑手端看到的配送顺序和下单时间对不上。原因dispatch接口只在首次生成任务时写route_seq后续追加订单没有重排。解决每次派单后对该小区所有未完成任务按create_time重新编号或者干脆在查询时用ORDER BY create_time代替依赖route_seq。后者更省事但分页时会有点别扭看你的量级。4.4 前端跨域报错开发代理没配现象前端 8081 调后端 8080浏览器控制台一片 CORS 红字。原因.env.development里接口地址写的是绝对路径没走vue.config.js的 devServer 代理。解决把接口 baseURL 改成/api在vue.config.js里配proxy: { /api: { target: http://localhost:8080, changeOrigin: true } }。生产环境用 Nginx 反代同理。4.5 测试数据重复导入主键冲突现象第二次执行data.sql报Duplicate entry。原因脚本用的是固定主键插入没加INSERT IGNORE或ON DUPLICATE KEY UPDATE。解决重置数据时先TRUNCATE相关表再导入或者把脚本里的INSERT INTO改成INSERT IGNORE INTO。我习惯在data.sql开头加一段SET FOREIGN_KEY_CHECKS0; TRUNCATE ...; SET FOREIGN_KEY_CHECKS1;一键重置不闹心。提示改完任何一处库存或状态逻辑务必用 3.3 的接口脚本把“下单—分拣—派单”重跑一遍光看页面容易漏掉表间不一致。5. 进阶改造把单机扣库存换成可验证的并发方案这套包默认是单机低并发场景下单即扣库存的写法在高校社区里够用。但如果你要拿它当“高并发秒杀”的课程加分项或者想验证自己对乐观锁的理解就得动库存这块。我给一个我实际改过、能跑通的方案顺带说怎么验证它真的防住了超卖。核心思路是把“选批次”和“扣减”合并成一次带条件的更新避免先查后改的窗口。改造后的扣减 SQL 在原有基础上加了版本号-- 带版本号的乐观扣减version 每次更新自增 UPDATE stock_batch SET quantity quantity - #{qty}, version version 1 WHERE id #{batchId} AND quantity #{qty} AND version #{version};参数说明version是查询批次时读到的版本号更新时带上影响行数为 0 说明要么库存不够、要么被别人抢先改了上层重试一次重新读批次即可。重试次数我设成 3超过就抛“库存紧张请重试”。这个方案比纯quantity qty多了一层版本校验在批次被并发修改时能更早发现冲突代价是多一次重试逻辑。验证方法我用了一个土办法但很有效写个 JMeter 或 Python 脚本对同一批次并发发 100 个下单请求每单买 1 件批次初始库存设 50。跑完查stock_batch.quantity应该正好是 0订单成功数正好 50多一件或少一件都说明扣减有漏洞。# 并发验证脚本核心片段requests ThreadPoolExecutor import requests from concurrent.futures import ThreadPoolExecutor def place_order(_): return requests.post(http://localhost:8080/api/order/create, json{productId: 1, qty: 1, communityId: 1}, headers{Authorization: TOKEN}).status_code with ThreadPoolExecutor(max_workers50) as pool: results list(pool.map(place_order, range(100))) print(成功数:, results.count(200), 库存余量:, query_stock(1))这段脚本的逻辑说明50 个线程并发打 100 个请求统计返回 200 的数量再查一次批次余量。预期是成功 50、余量 0。如果成功数超过 50说明扣减没锁住如果余量是负数说明quantity qty条件被绕过了。我第一次跑的时候成功数是 52查了半天发现是重试逻辑把“版本冲突”也当成了可重试结果重试时又扣了一次——血泪经验重试前必须重新读批次和版本号不能拿旧参数硬重试。改完这套系统就从“能演示”变成了“能讲清楚为什么不会超卖”答辩或评审时这一块最容易被追问提前准备好并发验证的数据比背概念管用。从那以后我每次改库存相关代码都强制先跑一遍这个并发脚本再提交宁可多花十分钟也不想上线后被超卖问题追着跑。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 10:36:55 · 阅读 1.2k 高校社区生鲜配送系统源码实战：订单状态机与库存扣减全链路解析
简介这份资源是面向高校计算机专业学生与Java Web开发学习者的社区生鲜配送系统完整项目源码围绕大学生及周边居民在线购买生鲜的场景覆盖用户管理、商品管理、订单处理、库存控制、配送调度、支付接口、数据分析、客户服务与移动端适配等核心业务模块适合作为课程设计、毕业设计或SSM/Spring Boot实战练手参考。压缩包共909个文件约1.61MB以html页面、css样式、js脚本与png/gif图片构成前端展示层120个java源文件与152个class文件对应后台控制器与业务逻辑另有sql建表脚本、xml与yml配置文件及json数据文件目录结构清晰便于按模块检索。已有139人学习下载读者可从中获取一套可直接运行的三层架构项目骨架、完整的数据库设计与实体关系、后台管理端增删改查实现思路以及订单状态流转、库存扣减与配送调度的具体编码参考便于对照理解并二次开发。1. 高校社区生鲜配送系统一份能跑通“下单—分拣—配送”全链路的源码包很多做课程设计或接私活的开发者一提到“生鲜配送系统”就头大订单要按小区聚合、库存要按批次扣减、配送要按路线分单三件事搅在一起写出来的代码往往只能演示不能落地。这份《高校社区生鲜配送系统.zip》解决的正是这个痛点——它把“用户下单、仓库分拣、骑手配送”这条主链路拆成了可独立调试的模块适合计算机专业做毕业设计的学生、想练手完整业务闭环的初级后端以及需要快速搭一套社区团购原型的从业者。我拆包跑了一遍前后端分离、数据库脚本齐全最值得看的是订单状态机和库存扣减这两块坑基本都埋在那里。下面按“它是什么—怎么跑起来—哪里会翻车”的顺序讲透。2. 系统架构与数据模型先看懂表结构再动手拿到一个陌生源码包我一般不会急着npm install而是先翻数据库脚本。表结构看不懂后面调接口全是盲人摸象。这个项目的核心表不多但字段设计有几个地方值得单独拎出来说。2.1 六张核心表撑起整条链路打开sql/目录下的建表脚本能理出六张主表用户表、商品表、库存批次表、订单主表、订单明细表、配送任务表。真正决定系统能不能跑通的是后四张之间的关联关系。表名关键字段作用易错点productid、name、price、unit商品基础信息价格用decimal(10,2)别用 floatstock_batchproduct_id、batch_no、quantity、expire_at按批次管理库存生鲜必须带保质期扣减要先进先出order_mainorder_no、user_id、status、community_id订单主记录status是状态机核心别随意加值order_itemorder_id、product_id、batch_id、qty订单明细必须记录实际扣减的批次号方便追溯delivery_taskorder_id、rider_id、route_seq、status配送任务route_seq决定同一小区内的配送顺序这里有个设计取舍值得说库存没有直接挂在product表上而是单独拆了stock_batch。生鲜场景下同一商品不同批次进价和保质期都不同扣库存必须按批次先进先出否则会出现“新货先出、旧货烂仓”的玄学问题。订单明细里存batch_id就是为了事后能查清每一单到底扣了哪批货出问题时有据可查。2.2 订单状态机五个状态不能乱跳order_main.status的取值在代码里是硬编码的我数了一下共五个待支付、已支付待分拣、分拣完成待配送、配送中、已完成。状态流转集中在service/OrderService里用了一个简单的switch做校验。// OrderService.java 状态流转核心逻辑节选 public void transitStatus(Long orderId, OrderStatus target) { OrderMain order orderMapper.selectById(orderId); OrderStatus current order.getStatus(); // 只允许按预设路径前进禁止回退和跳级 if (!current.canTransitTo(target)) { throw new BizException(非法状态流转: current - target); } order.setStatus(target); orderMapper.updateById(order); // 状态变更后触发对应副作用分拣、派单、通知 statusHandlerMap.get(target).handle(order); }这段代码的逻辑说明canTransitTo是一个枚举方法内部维护了允许的下一状态集合比如“待支付”只能到“已支付待分拣”“配送中”只能到“已完成”。参数target是目标状态传错直接抛业务异常。这样写的好处是把状态规则收在一处坏处是新增状态要改枚举和 handler 两处扩展时容易漏。我一般会在枚举里加一个ListOrderStatus nextStates字段把规则数据化比switch好维护。2.3 库存扣减放在哪一层一个容易吵起来的问题项目把库存扣减放在OrderService.createOrder里下单即扣。这在高校社区场景下是合理的——下单量小、并发低先扣后付能防止超卖。但如果照搬到高并发场景就会翻车后面避坑章节细说。扣减逻辑本身用了UPDATE ... WHERE quantity ?的乐观写法-- 扣减指定批次库存影响行数为 0 说明库存不足 UPDATE stock_batch SET quantity quantity - #{qty} WHERE id #{batchId} AND quantity #{qty};参数说明batchId来自分拣时选定的批次qty是订单明细数量。靠数据库行锁保证原子性影响行数为 0 时上层抛“库存不足”。这种写法比先SELECT再UPDATE安全但前提是批次要选对——选批次的逻辑在StockService.pickBatch里按expire_at升序取第一个够量的批次这就是先进先出的落地。3. 本地跑通全流程从建库到下单成功看懂表结构后就可以动手了。这个包是前后端分离的后端 Spring Boot、前端 Vue数据库 MySQL 8。我按实际跑通的顺序写命令可以直接抄。3.1 环境准备与建库先确认本机有 JDK 8、Maven 3.6、Node 14、MySQL 8。版本别贪新我试过 JDK 17 跑这个包有个老版本依赖会报模块访问异常换回 JDK 8 就没事。# 1. 建库并导入表结构和初始数据 mysql -uroot -p -e CREATE DATABASE fresh_delivery DEFAULT CHARSET utf8mb4; mysql -uroot -p fresh_delivery sql/schema.sql mysql -uroot -p fresh_delivery sql/data.sql # 2. 改后端数据库配置 # 编辑 src/main/resources/application-dev.yml # spring.datasource.url / username / password 三处改成自己的 # 3. 启动后端 mvn clean package -DskipTests java -jar target/fresh-delivery-1.0.jar --spring.profiles.activedev逻辑说明schema.sql只建表data.sql灌了三个小区、二十个商品和几个测试账号分开导入方便你只重置数据不动结构。application-dev.yml里默认连的是localhost:3306/fresh_delivery账号密码是占位符不改必报连接失败。启动参数--spring.profiles.activedev不能省否则会去读生产配置。3.2 前端启动与接口联调后端起来后默认 8080前端在web/目录下cd web npm install # 开发环境接口地址在 .env.development 里默认指向 http://localhost:8080 npm run serve前端跑在 8081登录页用data.sql里的测试账号手机号加验证码验证码在开发模式下固定为 1234写在AuthController的注释里。登录后进商品列表选一个小区、加购、下单能看到订单状态从“待支付”变成“已支付待分拣”——这一步能走通说明订单、库存、状态机三条线都通了。3.3 用接口脚本验证分拣和配送页面点一遍只能验证主流程分拣和配送的边界得用接口脚本压。项目自带docs/api.http我用 curl 复现了关键几步# 1. 管理员登录拿 token TOKEN$(curl -s -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {phone:13800000001,code:1234} | jq -r .data.token) # 2. 查询待分拣订单 curl -s http://localhost:8080/api/admin/orders?statusPAID_WAIT_PICK \ -H Authorization: $TOKEN | jq .data[].orderNo # 3. 对指定订单执行分拣会自动选批次扣库存 curl -s -X POST http://localhost:8080/api/admin/orders/1/pick \ -H Authorization: $TOKEN # 4. 生成配送任务并分配骑手 curl -s -X POST http://localhost:8080/api/admin/delivery/dispatch \ -H Authorization: $TOKEN \ -H Content-Type: application/json \ -d {communityId:1,riderId:2}参数说明第 3 步的1是订单主键分拣接口内部会调StockService.pickBatch逐条明细选批次任何一条库存不足整个分拣回滚。第 4 步的communityId决定按哪个小区聚合订单riderId是骑手用户 id派单后delivery_task.route_seq会按订单创建时间排序生成。跑完这四步数据库里订单状态应该是“配送中”stock_batch对应批次数量减少delivery_task多出一条记录——三张表对得上链路才算真通。4. 避坑与排查五个我实际踩过的坑这套代码逻辑不算复杂但生鲜业务本身的特殊性会放大一些细节问题。下面五条都是我跑的时候真实遇到的按“现象—原因—解决”记下来你大概率也会撞上。4.1 下单成功但库存没减事务没生效现象调下单接口返回成功订单表有记录但stock_batch.quantity纹丝不动。原因createOrder方法上标了Transactional但类内部另一个方法通过this.调用它Spring 的代理没拦住事务根本没开。解决把扣库存逻辑抽到独立的StockService里注入调用或者用AopContext.currentProxy()拿代理对象。我一般选前者干净。4.2 分拣时提示库存不足但页面显示有货批次选错现象商品总库存明明够分拣却报“库存不足”。原因pickBatch按expire_at升序选批次如果最早过期的批次量不够它不会自动跨批次凑直接返回失败。解决这是设计上的简化单批次不够时应拆成多条明细跨批次扣减。改法是在pickBatch里循环取批次直到凑够数量每取一批生成一条order_item的批次分摊记录。不改的话运营上就得保证单批次量大于单笔订单量。4.3 同一小区订单配送顺序乱route_seq 没重排现象派单后骑手端看到的配送顺序和下单时间对不上。原因dispatch接口只在首次生成任务时写route_seq后续追加订单没有重排。解决每次派单后对该小区所有未完成任务按create_time重新编号或者干脆在查询时用ORDER BY create_time代替依赖route_seq。后者更省事但分页时会有点别扭看你的量级。4.4 前端跨域报错开发代理没配现象前端 8081 调后端 8080浏览器控制台一片 CORS 红字。原因.env.development里接口地址写的是绝对路径没走vue.config.js的 devServer 代理。解决把接口 baseURL 改成/api在vue.config.js里配proxy: { /api: { target: http://localhost:8080, changeOrigin: true } }。生产环境用 Nginx 反代同理。4.5 测试数据重复导入主键冲突现象第二次执行data.sql报Duplicate entry。原因脚本用的是固定主键插入没加INSERT IGNORE或ON DUPLICATE KEY UPDATE。解决重置数据时先TRUNCATE相关表再导入或者把脚本里的INSERT INTO改成INSERT IGNORE INTO。我习惯在data.sql开头加一段SET FOREIGN_KEY_CHECKS0; TRUNCATE ...; SET FOREIGN_KEY_CHECKS1;一键重置不闹心。提示改完任何一处库存或状态逻辑务必用 3.3 的接口脚本把“下单—分拣—派单”重跑一遍光看页面容易漏掉表间不一致。5. 进阶改造把单机扣库存换成可验证的并发方案这套包默认是单机低并发场景下单即扣库存的写法在高校社区里够用。但如果你要拿它当“高并发秒杀”的课程加分项或者想验证自己对乐观锁的理解就得动库存这块。我给一个我实际改过、能跑通的方案顺带说怎么验证它真的防住了超卖。核心思路是把“选批次”和“扣减”合并成一次带条件的更新避免先查后改的窗口。改造后的扣减 SQL 在原有基础上加了版本号-- 带版本号的乐观扣减version 每次更新自增 UPDATE stock_batch SET quantity quantity - #{qty}, version version 1 WHERE id #{batchId} AND quantity #{qty} AND version #{version};参数说明version是查询批次时读到的版本号更新时带上影响行数为 0 说明要么库存不够、要么被别人抢先改了上层重试一次重新读批次即可。重试次数我设成 3超过就抛“库存紧张请重试”。这个方案比纯quantity qty多了一层版本校验在批次被并发修改时能更早发现冲突代价是多一次重试逻辑。验证方法我用了一个土办法但很有效写个 JMeter 或 Python 脚本对同一批次并发发 100 个下单请求每单买 1 件批次初始库存设 50。跑完查stock_batch.quantity应该正好是 0订单成功数正好 50多一件或少一件都说明扣减有漏洞。# 并发验证脚本核心片段requests ThreadPoolExecutor import requests from concurrent.futures import ThreadPoolExecutor def place_order(_): return requests.post(http://localhost:8080/api/order/create, json{productId: 1, qty: 1, communityId: 1}, headers{Authorization: TOKEN}).status_code with ThreadPoolExecutor(max_workers50) as pool: results list(pool.map(place_order, range(100))) print(成功数:, results.count(200), 库存余量:, query_stock(1))这段脚本的逻辑说明50 个线程并发打 100 个请求统计返回 200 的数量再查一次批次余量。预期是成功 50、余量 0。如果成功数超过 50说明扣减没锁住如果余量是负数说明quantity qty条件被绕过了。我第一次跑的时候成功数是 52查了半天发现是重试逻辑把“版本冲突”也当成了可重试结果重试时又扣了一次——血泪经验重试前必须重新读批次和版本号不能拿旧参数硬重试。改完这套系统就从“能演示”变成了“能讲清楚为什么不会超卖”答辩或评审时这一块最容易被追问提前准备好并发验证的数据比背概念管用。从那以后我每次改库存相关代码都强制先跑一遍这个并发脚本再提交宁可多花十分钟也不想上线后被超卖问题追着跑。希望帮到你。本文还有配套的精品资源点击获取