简介这份超市进销存管理系统源码面向Java初学者、课程设计学生及需要小型零售管理系统的开发者帮助理解采购、销售、库存等核心业务在代码层面的实现方式。资源包共239个文件约1.24MB以146个class编译文件与49个java源码为主另含25个png、6个jpg界面素材以及4个db数据库文件、mdf与ldf数据文件、xml配置、fatjar可执行包和doc说明文档覆盖登录验证、销售管理、商品统计、入库退货等模块便于对照源码梳理分层结构与数据库交互逻辑。已有48人学习下载适合作为课程设计参考或二次开发基础可从中获取完整项目结构、界面资源与数据文件快速搭建可运行的进销存演示环境。1. 超市进销存管理系统源码从“能跑”到“敢用”之间差了什么很多开发者拿到一份超市进销存管理系统源码第一反应是打开 IDE 跑起来看看界面长什么样。能登录、能加商品、能开单就觉得“这套东西能用”。但真正放到一家日均几百单的小超市里跑一周问题就会集中爆发库存对不上、并发开单丢数据、退货后成本价算错、盘点差异查不到原因。进销存系统的核心难点从来不在界面而在库存扣减的时机、成本核算的算法、以及单据之间的勾稽关系。这份源码值不值得投入精力去改取决于它有没有把这三件事做对。本文面向手里已经有一份源码、或者准备选一套进销存系统二次开发的从业者把选型判断、核心模块实现、参数配置和常见翻车点拆开讲清楚让你看完能判断手里的代码能不能用、该怎么改。2. 拿到源码先别急着改界面四个模块的验收顺序一套完整的超市进销存系统代码结构通常分为基础资料、采购入库、销售出库、库存盘点四大块。很多人上来就调前端样式结果改到一半发现库存逻辑是错的前面的工作全白费。正确的验收顺序应该从数据模型开始往业务逻辑推最后才是交互层。2.1 先看数据库表结构能不能撑住业务打开源码的 SQL 文件或者 ORM 映射文件重点看这几张表的设计商品表、库存表、入库单主表/明细表、出库单主表/明细表、库存流水表。判断标准很直接——库存流水表是不是独立存在的。如果源码里只有一张库存表每次出入库直接 update 数量字段没有流水记录这套代码在出现库存差异时你根本查不到原因直接放弃或者做好重写库存模块的准备。库存流水表至少要包含这些字段CREATE TABLE stock_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_id BIGINT NOT NULL COMMENT 商品ID, warehouse_id BIGINT NOT NULL DEFAULT 1 COMMENT 仓库ID单店默认1, biz_type TINYINT NOT NULL COMMENT 业务类型1采购入库 2销售出库 3退货入库 4退货出库 5盘点调整 6报损, biz_no VARCHAR(32) NOT NULL COMMENT 关联单据号, change_qty DECIMAL(12,3) NOT NULL COMMENT 变动数量入库为正出库为负, before_qty DECIMAL(12,3) NOT NULL COMMENT 变动前数量, after_qty DECIMAL(12,3) NOT NULL COMMENT 变动后数量, cost_price DECIMAL(12,4) DEFAULT NULL COMMENT 该次变动的成本单价, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_goods_time (goods_id, created_at), INDEX idx_biz_no (biz_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;这张表的关键在于before_qty和after_qty两个字段。它们记录了每次变动的快照盘点时如果发现账实不符可以顺着流水逐笔核对定位到是哪一笔单据出了问题。cost_price字段用于移动加权平均法的成本核算后面会展开讲。biz_type用枚举值区分业务类型比用字符串可读性差一点但查询效率和存储空间都更优。如果源码里库存表用的是stock单表且没有流水你需要评估改造工作量。简单做法是在现有出入库逻辑里插入流水记录但要注意历史数据的初始化——上线前做一次全量盘点把盘点结果作为第一条流水写入before_qty设为 0after_qty设为实际库存。2.2 采购入库的成本价是怎么算的采购入库单的明细里通常有采购价但库存的成本价不一定等于采购价。超市场景下同一商品不同批次的进价可能不同出库时用哪个价格算成本直接影响毛利报表的准确性。常见做法有三种先进先出、移动加权平均、手工指定。大部分中小超市用移动加权平均就够了实现也简单。移动加权平均的公式是新成本价 (原库存金额 本次入库金额) / (原库存数量 本次入库数量)。每次入库后重新计算出库时按当前成本价扣减。用代码实现时注意在同一个事务里完成库存更新和成本价更新def purchase_inbound(goods_id, qty, price, biz_no): 采购入库更新库存、重算移动加权平均成本、写流水 qty: 入库数量正数 price: 本次采购单价 with db.transaction(): stock db.query_one( SELECT qty, cost_price FROM stock WHERE goods_id%s FOR UPDATE, (goods_id,) ) old_qty stock[qty] old_cost stock[cost_price] old_amount old_qty * old_cost new_amount old_amount qty * price new_qty old_qty qty new_cost new_amount / new_qty if new_qty 0 else 0 db.execute( UPDATE stock SET qty%s, cost_price%s WHERE goods_id%s, (new_qty, round(new_cost, 4), goods_id) ) db.execute( INSERT INTO stock_flow (goods_id, biz_type, biz_no, change_qty, before_qty, after_qty, cost_price) VALUES (%s, 1, %s, %s, %s, %s, %s), (goods_id, biz_no, qty, old_qty, new_qty, round(new_cost, 4)) )这段代码有两个关键点。第一SELECT ... FOR UPDATE是必须的否则两个采购单同时入库会导致成本价算错。第二成本价保留 4 位小数因为多次加权平均后小数位会累积保留太少会导致金额对不上。出库时直接用stock.cost_price作为成本单价写入流水不需要重新计算。如果源码里用的是先进先出代码会复杂很多需要按批次记录库存。中小超市除非有明确的批次管理需求比如生鲜保质期否则不建议用先进先出维护成本太高。2.3 销售出库的库存扣减时机销售出库的库存扣减时机是个容易翻车的点。有的源码在收银时直接扣库存有的在日结时统一扣。两种做法各有适用场景但超市场景下建议收银时实时扣减因为库存不准会影响后续销售——顾客要买 10 瓶水系统显示还有 8 瓶这单就做不成。实时扣减的代码逻辑和采购入库类似只是方向相反def sale_outbound(goods_id, qty, biz_no): 销售出库扣减库存、按当前成本价写流水 qty: 出库数量正数 with db.transaction(): stock db.query_one( SELECT qty, cost_price FROM stock WHERE goods_id%s FOR UPDATE, (goods_id,) ) if stock[qty] qty: raise BizError(f库存不足当前库存 {stock[qty]}) new_qty stock[qty] - qty db.execute( UPDATE stock SET qty%s WHERE goods_id%s, (new_qty, goods_id) ) db.execute( INSERT INTO stock_flow (goods_id, biz_type, biz_no, change_qty, before_qty, after_qty, cost_price) VALUES (%s, 2, %s, %s, %s, %s, %s), (goods_id, biz_no, -qty, stock[qty], new_qty, stock[cost_price]) )注意change_qty存的是负数这样在流水表里直接 sum 就能得到当前库存方便对账。库存不足时抛异常回滚事务避免超卖。如果源码里没有这个判断一定要加上否则会出现负库存后续盘点全是坑。2.4 盘点单的差异处理逻辑盘点单是进销存系统里最容易被忽视的模块。很多源码的盘点功能只是把库存数量改成盘点数量没有记录差异原因和调整流水。正确的做法是盘点单保存时生成一条biz_type5的流水change_qty等于盘点数量减账面数量before_qty是账面数量after_qty是盘点数量。这样盘点差异就变成了库存流水的一部分可以追溯。盘点单的明细表还需要一个diff_reason字段记录差异原因如破损、丢失、录入错误。这个字段在后续做损耗分析时很有用。如果源码里没有加一个 varchar 字段的成本很低但带来的管理价值很高。3. 库存扣减的并发问题从超卖到死锁的排查库存扣减是进销存系统里并发问题最集中的地方。单机单线程跑没问题一上多收银台就出各种玄学问题。这一章把常见的并发场景和排查方法讲清楚。3.1 超卖的三种典型场景超卖是指库存扣成了负数或者多个订单同时扣同一批库存导致实际库存不够。第一种场景是两个收银台同时卖同一商品都查到库存为 1都判断库存充足然后都扣减结果库存变成 -1。第二种场景是收银和退货同时操作退货先加库存收银后扣库存但退货事务还没提交收银读到的还是旧库存。第三种场景是批量导入历史销售数据时没有加锁多线程同时更新。这三种场景的根因都一样读库存和写库存之间没有原子性保证。解决办法就是在读取库存时加行锁SELECT ... FOR UPDATE是最直接的方式。但加锁会带来性能问题如果商品数量多、并发高锁竞争会很严重。3.2 用乐观锁还是悲观锁悲观锁就是上面代码里的FOR UPDATE优点是实现简单、不容易出错缺点是并发高时锁等待时间长。乐观锁是在库存表加一个version字段更新时检查版本号UPDATE stock SET qty qty - 5, version version 1 WHERE goods_id 1001 AND version 3 AND qty 5;如果影响行数为 0说明版本号变了或者库存不足需要重试。乐观锁适合读多写少的场景但超市收银是写多读少而且重试逻辑会增加代码复杂度。我的经验是中小超市日均 500 单以内直接用悲观锁简单可靠大型超市或者线上线下一体化的场景再考虑乐观锁或者分布式锁。3.3 死锁是怎么产生的死锁通常发生在批量操作时两个事务以不同的顺序锁定多行库存。比如事务 A 先锁商品 1 再锁商品 2事务 B 先锁商品 2 再锁商品 1两者互相等待。排查死锁的方法是看数据库的死锁日志MySQL 用SHOW ENGINE INNODB STATUS可以看到最近一次死锁的详细信息。避免死锁的做法是统一加锁顺序。在批量扣减库存时先把商品 ID 排序再按顺序逐个加锁。这样所有事务的加锁顺序一致就不会出现循环等待。代码里加一行排序就能解决goods_ids sorted(set(item[goods_id] for item in items)) for gid in goods_ids: db.query_one(SELECT qty FROM stock WHERE goods_id%s FOR UPDATE, (gid,))3.4 事务隔离级别怎么选MySQL 默认的隔离级别是 RR可重复读在这个级别下FOR UPDATE会加间隙锁可能导致更多的锁等待。如果业务允许可以把隔离级别降到 RC读已提交减少间隙锁。但 RC 级别下可能出现不可重复读也就是同一个事务里两次读同一行数据结果不一样。对于库存扣减来说只要加了FOR UPDATERC 和 RR 都能保证正确性RC 的并发性能更好。设置隔离级别的命令是SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED可以在连接池初始化时统一设置。如果源码里没有显式设置默认就是 RR中小超市够用不用急着改。4. 避坑源码二次开发中最容易翻车的五个地方这一章记录的是我在改造和部署进销存系统时踩过的坑每个都按现象、原因、解决来写。如果你手里的源码有类似问题提前改掉能省很多时间。4.1 库存流水和库存表对不上现象盘点时发现库存表的数量和流水表 sum 出来的数量不一致差异不大但一直存在。原因出入库代码里更新库存表和写流水不在同一个事务里或者流水写入失败后没有回滚库存更新。还有一种情况是历史数据初始化时只写了库存表没有写初始流水。解决把所有库存变动逻辑收敛到一个统一的函数里库存更新和流水写入必须在同一个事务中。初始化时用盘点单的方式写入初始流水before_qty0after_qty实际库存。上线后定期跑对账脚本发现差异立即排查。4.2 退货后成本价算错现象顾客退货后库存数量对了但毛利报表里的成本金额不对。原因退货入库时用了销售时的成本价但移动加权平均法下退货应该按当前成本价入库而不是原销售成本价。如果源码里退货逻辑直接取原单的成本价就会导致成本价偏差。解决退货入库时重新计算移动加权平均成本和采购入库用同一套逻辑。退货单的biz_type设为 3cost_price取退货时的当前成本价。如果业务上需要按原单成本退货那成本核算方法就要改成先进先出不能混用。4.3 盘点后库存被覆盖现象盘点单审核后库存数量变成了盘点数量但盘点期间发生的出入库单据被覆盖了。原因盘点逻辑是直接UPDATE stock SET qty 盘点数量没有考虑盘点期间的新增流水。正确做法是盘点单审核时计算盘点数量与当前库存的差异生成调整流水而不是直接覆盖。解决盘点单保存时记录盘点时的账面数量审核时用盘点数量 - 当前库存作为调整量写入流水。这样盘点期间的出入库不会被覆盖差异也能追溯。4.4 并发开单时单据号重复现象两个收银台同时开单生成的单据号一样导致后续查询和退货找不到单。原因单据号生成用了SELECT MAX(biz_no) 1的方式并发时两个事务读到同一个最大值。解决单据号生成用数据库序列或者 Redis 自增不要用 max1。如果源码里用的是 max1改成时间戳加随机数或者数据库自增 ID。单据号只要求唯一不要求连续所以用 UUID 也可以只是可读性差一点。4.5 商品条码重复导致入库错乱现象扫码入库时扫 A 商品的条码系统识别成了 B 商品。原因商品表没有对条码做唯一约束或者条码字段允许为空多个商品条码为空时扫码查询返回了错误记录。解决商品表的条码字段加唯一索引允许为空但不允许重复。扫码查询时如果返回多条记录提示用户手动选择。如果源码里没有唯一索引加索引前先清理重复数据。5. 从单店到多店库存调拨和权限控制的实现要点单店跑通之后如果业务扩展到多店源码需要支持库存调拨和门店权限隔离。这一章讲两个进阶功能的实现思路和关键参数。5.1 库存调拨的单据设计调拨本质上是两次库存变动调出门店出库调入门店入库。但这两次变动不能独立发生必须在一个事务里完成否则会出现货已发出但对方没收到的情况。调拨单的主表记录调出和调入门店明细表记录商品和数量。审核时执行def transfer_approve(transfer_id): 调拨单审核调出门店扣库存调入门店加库存 items db.query(SELECT * FROM transfer_item WHERE transfer_id%s, (transfer_id,)) with db.transaction(): for item in items: # 调出门店出库 outbound(item[from_warehouse_id], item[goods_id], item[qty], transfer_id) # 调入门店入库成本价取调出门店的当前成本价 cost get_cost_price(item[from_warehouse_id], item[goods_id]) inbound(item[to_warehouse_id], item[goods_id], item[qty], cost, transfer_id)调入门店的成本价取调出门店的成本价这样调拨不会产生利润只是库存位置的转移。如果源码里调拨时重新按采购价入库会导致毛利虚高。5.2 门店权限隔离的三种方案多店场景下每个门店只能看自己的库存和单据。实现方案有三种按门店 ID 过滤、按仓库 ID 过滤、按数据权限角色过滤。最简单的是在库存表和单据表加warehouse_id字段所有查询都带上这个条件。如果源码里没有这个字段改造工作量较大需要评估。权限控制建议用角色加数据范围的方式。角色定义能操作哪些菜单数据范围定义能看哪些门店的数据。这样新增门店时只需要配置数据范围不用改代码。如果源码里权限是硬编码的建议先重构权限模块再扩展多店。5.3 调拨在途库存的处理调拨单审核后、调入方确认前这批货处于在途状态。严格来说在途库存既不属于调出门店也不属于调入门店需要单独记录。简单做法是调拨单审核时调出门店直接扣库存调入门店直接加库存不记录在途。这样账面上库存是准的但实物在途时两边都查不到。如果业务上需要跟踪在途可以在调拨单加一个状态字段审核后状态为“在途”调入方确认后状态改为“已完成”库存变动在确认时才执行。两种做法各有取舍。不记录在途的实现简单适合调拨频繁但距离近的场景记录在途的实现复杂但能准确反映实物位置适合跨城市调拨。根据实际业务选不要为了技术先进而增加复杂度。5.4 多店库存查询的性能优化多店场景下库存查询需要跨门店汇总。如果门店数量多直接 join 查询会很慢。优化方式有两种一是加汇总表定时把各门店库存汇总到一张表里查询时直接读汇总表二是用缓存把库存数据缓存到 Redis查询时先读缓存。汇总表适合对实时性要求不高的场景缓存适合对实时性要求高的场景。如果源码里没有做这些优化门店数量在 10 家以内时直接查询问题不大。超过 10 家再考虑加汇总表或缓存。不要过早优化先把业务跑通。6. 用对账脚本验证库存准确性一个可复用的排查方法库存准确性是进销存系统的生命线。不管代码写得多好上线后都要定期对账。这一章给一个可复用的对账脚本以及我平时排查库存问题的习惯。6.1 对账脚本的核心逻辑对账脚本要回答三个问题库存表的数量是否等于流水表的 sum流水表的 before_qty 和 after_qty 是否连续成本价是否在合理范围内。下面是一个 Python 脚本的骨架def reconcile_stock(): 库存对账检查库存表与流水表是否一致 返回差异列表 diffs [] # 1. 数量对账 rows db.query( SELECT s.goods_id, s.qty AS stock_qty, COALESCE(SUM(f.change_qty), 0) AS flow_qty FROM stock s LEFT JOIN stock_flow f ON s.goods_id f.goods_id GROUP BY s.goods_id, s.qty HAVING s.qty ! COALESCE(SUM(f.change_qty), 0) ) for row in rows: diffs.append({ type: qty_mismatch, goods_id: row[goods_id], stock_qty: row[stock_qty], flow_qty: row[flow_qty] }) # 2. 流水连续性检查 flows db.query( SELECT goods_id, before_qty, after_qty, change_qty FROM stock_flow ORDER BY goods_id, id ) last_after {} for f in flows: gid f[goods_id] if gid in last_after and f[before_qty] ! last_after[gid]: diffs.append({ type: flow_discontinuous, goods_id: gid, expected_before: last_after[gid], actual_before: f[before_qty] }) if f[before_qty] f[change_qty] ! f[after_qty]: diffs.append({ type: flow_calc_error, goods_id: gid, before: f[before_qty], change: f[change_qty], after: f[after_qty] }) last_after[gid] f[after_qty] return diffs这个脚本跑一次就能把大部分库存问题暴露出来。qty_mismatch说明库存表和流水表不一致通常是事务问题flow_discontinuous说明流水中间有断档可能是历史数据初始化没做flow_calc_error说明流水本身的 beforechange 不等于 after是代码 bug。6.2 对账频率和差异处理对账频率根据业务量定。日均 100 单以下每周跑一次100 到 500 单每天跑一次500 单以上建议实时对账——每笔单据完成后异步检查一次。差异处理的原则是先查原因再调整不要直接改库存表。找到差异原因后用盘点单的方式调整库存这样调整本身也会留下流水记录。如果差异金额较小比如几分钱可能是小数位精度问题可以设置一个容差范围比如 0.01 以内忽略。如果差异金额较大一定要查到具体单据不能放过。6.3 我平时排查库存问题的习惯我排查库存问题的第一步永远是看流水表不是看库存表。库存表是结果流水表是过程。过程对了结果一定对过程错了结果对了也是暂时的。看流水时重点看三样变动时间是否连续、变动数量是否合理、成本价是否突变。成本价突变通常意味着加权平均算错了或者有人手工改了库存。第二个习惯是复现问题。找到可疑单据后在测试环境用同样的数据跑一遍看能不能复现。能复现的问题都好解决不能复现的问题通常是并发导致的需要加日志或者压测。第三个习惯是留后悔药。每次调整库存前先备份库存表和流水表调整后立即对账。调整操作要记录操作人和原因方便后续追溯。这些习惯看起来麻烦但比出了问题再翻日志快得多。6.4 一个具体的排查案例某次对账发现商品 A 的库存表数量比流水 sum 多了 3 个。查流水发现三天前有一笔采购入库单流水记录的数量是 10但库存表只增加了 7。进一步查代码发现那笔入库单的明细里有三行同一个商品代码在处理时只更新了第一行的库存后两行被跳过了。原因是明细表的主键设计有问题同一个商品多行时主键冲突后两行插入失败但事务没有回滚。修复方式是给明细表加自增主键不要用商品 ID 做联合主键。同时把库存更新逻辑改成按商品汇总后更新避免同一商品多次更新。这个案例的教训是明细表的主键设计要在开发初期就定好后期改成本很高。6.5 对账脚本的自动化部署对账脚本建议做成定时任务每天凌晨跑一次结果发到工作群或者邮件。如果差异条数超过阈值比如 5 条触发告警。脚本本身要幂等重复跑不会产生副作用。日志保留至少 30 天方便回溯。如果源码里没有对账功能把这个脚本加进去是投入产出比很高的一件事。它不能防止问题发生但能让你在问题扩大之前发现它。我见过太多超市因为库存不准导致盘点时才发现亏了几万块如果有对账脚本这个损失可以降到几百块。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 9:37:35 · 阅读 1.2k 超市进销存管理系统源码二次开发：库存扣减、成本核算与对账脚本实战
简介这份超市进销存管理系统源码面向Java初学者、课程设计学生及需要小型零售管理系统的开发者帮助理解采购、销售、库存等核心业务在代码层面的实现方式。资源包共239个文件约1.24MB以146个class编译文件与49个java源码为主另含25个png、6个jpg界面素材以及4个db数据库文件、mdf与ldf数据文件、xml配置、fatjar可执行包和doc说明文档覆盖登录验证、销售管理、商品统计、入库退货等模块便于对照源码梳理分层结构与数据库交互逻辑。已有48人学习下载适合作为课程设计参考或二次开发基础可从中获取完整项目结构、界面资源与数据文件快速搭建可运行的进销存演示环境。1. 超市进销存管理系统源码从“能跑”到“敢用”之间差了什么很多开发者拿到一份超市进销存管理系统源码第一反应是打开 IDE 跑起来看看界面长什么样。能登录、能加商品、能开单就觉得“这套东西能用”。但真正放到一家日均几百单的小超市里跑一周问题就会集中爆发库存对不上、并发开单丢数据、退货后成本价算错、盘点差异查不到原因。进销存系统的核心难点从来不在界面而在库存扣减的时机、成本核算的算法、以及单据之间的勾稽关系。这份源码值不值得投入精力去改取决于它有没有把这三件事做对。本文面向手里已经有一份源码、或者准备选一套进销存系统二次开发的从业者把选型判断、核心模块实现、参数配置和常见翻车点拆开讲清楚让你看完能判断手里的代码能不能用、该怎么改。2. 拿到源码先别急着改界面四个模块的验收顺序一套完整的超市进销存系统代码结构通常分为基础资料、采购入库、销售出库、库存盘点四大块。很多人上来就调前端样式结果改到一半发现库存逻辑是错的前面的工作全白费。正确的验收顺序应该从数据模型开始往业务逻辑推最后才是交互层。2.1 先看数据库表结构能不能撑住业务打开源码的 SQL 文件或者 ORM 映射文件重点看这几张表的设计商品表、库存表、入库单主表/明细表、出库单主表/明细表、库存流水表。判断标准很直接——库存流水表是不是独立存在的。如果源码里只有一张库存表每次出入库直接 update 数量字段没有流水记录这套代码在出现库存差异时你根本查不到原因直接放弃或者做好重写库存模块的准备。库存流水表至少要包含这些字段CREATE TABLE stock_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_id BIGINT NOT NULL COMMENT 商品ID, warehouse_id BIGINT NOT NULL DEFAULT 1 COMMENT 仓库ID单店默认1, biz_type TINYINT NOT NULL COMMENT 业务类型1采购入库 2销售出库 3退货入库 4退货出库 5盘点调整 6报损, biz_no VARCHAR(32) NOT NULL COMMENT 关联单据号, change_qty DECIMAL(12,3) NOT NULL COMMENT 变动数量入库为正出库为负, before_qty DECIMAL(12,3) NOT NULL COMMENT 变动前数量, after_qty DECIMAL(12,3) NOT NULL COMMENT 变动后数量, cost_price DECIMAL(12,4) DEFAULT NULL COMMENT 该次变动的成本单价, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_goods_time (goods_id, created_at), INDEX idx_biz_no (biz_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;这张表的关键在于before_qty和after_qty两个字段。它们记录了每次变动的快照盘点时如果发现账实不符可以顺着流水逐笔核对定位到是哪一笔单据出了问题。cost_price字段用于移动加权平均法的成本核算后面会展开讲。biz_type用枚举值区分业务类型比用字符串可读性差一点但查询效率和存储空间都更优。如果源码里库存表用的是stock单表且没有流水你需要评估改造工作量。简单做法是在现有出入库逻辑里插入流水记录但要注意历史数据的初始化——上线前做一次全量盘点把盘点结果作为第一条流水写入before_qty设为 0after_qty设为实际库存。2.2 采购入库的成本价是怎么算的采购入库单的明细里通常有采购价但库存的成本价不一定等于采购价。超市场景下同一商品不同批次的进价可能不同出库时用哪个价格算成本直接影响毛利报表的准确性。常见做法有三种先进先出、移动加权平均、手工指定。大部分中小超市用移动加权平均就够了实现也简单。移动加权平均的公式是新成本价 (原库存金额 本次入库金额) / (原库存数量 本次入库数量)。每次入库后重新计算出库时按当前成本价扣减。用代码实现时注意在同一个事务里完成库存更新和成本价更新def purchase_inbound(goods_id, qty, price, biz_no): 采购入库更新库存、重算移动加权平均成本、写流水 qty: 入库数量正数 price: 本次采购单价 with db.transaction(): stock db.query_one( SELECT qty, cost_price FROM stock WHERE goods_id%s FOR UPDATE, (goods_id,) ) old_qty stock[qty] old_cost stock[cost_price] old_amount old_qty * old_cost new_amount old_amount qty * price new_qty old_qty qty new_cost new_amount / new_qty if new_qty 0 else 0 db.execute( UPDATE stock SET qty%s, cost_price%s WHERE goods_id%s, (new_qty, round(new_cost, 4), goods_id) ) db.execute( INSERT INTO stock_flow (goods_id, biz_type, biz_no, change_qty, before_qty, after_qty, cost_price) VALUES (%s, 1, %s, %s, %s, %s, %s), (goods_id, biz_no, qty, old_qty, new_qty, round(new_cost, 4)) )这段代码有两个关键点。第一SELECT ... FOR UPDATE是必须的否则两个采购单同时入库会导致成本价算错。第二成本价保留 4 位小数因为多次加权平均后小数位会累积保留太少会导致金额对不上。出库时直接用stock.cost_price作为成本单价写入流水不需要重新计算。如果源码里用的是先进先出代码会复杂很多需要按批次记录库存。中小超市除非有明确的批次管理需求比如生鲜保质期否则不建议用先进先出维护成本太高。2.3 销售出库的库存扣减时机销售出库的库存扣减时机是个容易翻车的点。有的源码在收银时直接扣库存有的在日结时统一扣。两种做法各有适用场景但超市场景下建议收银时实时扣减因为库存不准会影响后续销售——顾客要买 10 瓶水系统显示还有 8 瓶这单就做不成。实时扣减的代码逻辑和采购入库类似只是方向相反def sale_outbound(goods_id, qty, biz_no): 销售出库扣减库存、按当前成本价写流水 qty: 出库数量正数 with db.transaction(): stock db.query_one( SELECT qty, cost_price FROM stock WHERE goods_id%s FOR UPDATE, (goods_id,) ) if stock[qty] qty: raise BizError(f库存不足当前库存 {stock[qty]}) new_qty stock[qty] - qty db.execute( UPDATE stock SET qty%s WHERE goods_id%s, (new_qty, goods_id) ) db.execute( INSERT INTO stock_flow (goods_id, biz_type, biz_no, change_qty, before_qty, after_qty, cost_price) VALUES (%s, 2, %s, %s, %s, %s, %s), (goods_id, biz_no, -qty, stock[qty], new_qty, stock[cost_price]) )注意change_qty存的是负数这样在流水表里直接 sum 就能得到当前库存方便对账。库存不足时抛异常回滚事务避免超卖。如果源码里没有这个判断一定要加上否则会出现负库存后续盘点全是坑。2.4 盘点单的差异处理逻辑盘点单是进销存系统里最容易被忽视的模块。很多源码的盘点功能只是把库存数量改成盘点数量没有记录差异原因和调整流水。正确的做法是盘点单保存时生成一条biz_type5的流水change_qty等于盘点数量减账面数量before_qty是账面数量after_qty是盘点数量。这样盘点差异就变成了库存流水的一部分可以追溯。盘点单的明细表还需要一个diff_reason字段记录差异原因如破损、丢失、录入错误。这个字段在后续做损耗分析时很有用。如果源码里没有加一个 varchar 字段的成本很低但带来的管理价值很高。3. 库存扣减的并发问题从超卖到死锁的排查库存扣减是进销存系统里并发问题最集中的地方。单机单线程跑没问题一上多收银台就出各种玄学问题。这一章把常见的并发场景和排查方法讲清楚。3.1 超卖的三种典型场景超卖是指库存扣成了负数或者多个订单同时扣同一批库存导致实际库存不够。第一种场景是两个收银台同时卖同一商品都查到库存为 1都判断库存充足然后都扣减结果库存变成 -1。第二种场景是收银和退货同时操作退货先加库存收银后扣库存但退货事务还没提交收银读到的还是旧库存。第三种场景是批量导入历史销售数据时没有加锁多线程同时更新。这三种场景的根因都一样读库存和写库存之间没有原子性保证。解决办法就是在读取库存时加行锁SELECT ... FOR UPDATE是最直接的方式。但加锁会带来性能问题如果商品数量多、并发高锁竞争会很严重。3.2 用乐观锁还是悲观锁悲观锁就是上面代码里的FOR UPDATE优点是实现简单、不容易出错缺点是并发高时锁等待时间长。乐观锁是在库存表加一个version字段更新时检查版本号UPDATE stock SET qty qty - 5, version version 1 WHERE goods_id 1001 AND version 3 AND qty 5;如果影响行数为 0说明版本号变了或者库存不足需要重试。乐观锁适合读多写少的场景但超市收银是写多读少而且重试逻辑会增加代码复杂度。我的经验是中小超市日均 500 单以内直接用悲观锁简单可靠大型超市或者线上线下一体化的场景再考虑乐观锁或者分布式锁。3.3 死锁是怎么产生的死锁通常发生在批量操作时两个事务以不同的顺序锁定多行库存。比如事务 A 先锁商品 1 再锁商品 2事务 B 先锁商品 2 再锁商品 1两者互相等待。排查死锁的方法是看数据库的死锁日志MySQL 用SHOW ENGINE INNODB STATUS可以看到最近一次死锁的详细信息。避免死锁的做法是统一加锁顺序。在批量扣减库存时先把商品 ID 排序再按顺序逐个加锁。这样所有事务的加锁顺序一致就不会出现循环等待。代码里加一行排序就能解决goods_ids sorted(set(item[goods_id] for item in items)) for gid in goods_ids: db.query_one(SELECT qty FROM stock WHERE goods_id%s FOR UPDATE, (gid,))3.4 事务隔离级别怎么选MySQL 默认的隔离级别是 RR可重复读在这个级别下FOR UPDATE会加间隙锁可能导致更多的锁等待。如果业务允许可以把隔离级别降到 RC读已提交减少间隙锁。但 RC 级别下可能出现不可重复读也就是同一个事务里两次读同一行数据结果不一样。对于库存扣减来说只要加了FOR UPDATERC 和 RR 都能保证正确性RC 的并发性能更好。设置隔离级别的命令是SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED可以在连接池初始化时统一设置。如果源码里没有显式设置默认就是 RR中小超市够用不用急着改。4. 避坑源码二次开发中最容易翻车的五个地方这一章记录的是我在改造和部署进销存系统时踩过的坑每个都按现象、原因、解决来写。如果你手里的源码有类似问题提前改掉能省很多时间。4.1 库存流水和库存表对不上现象盘点时发现库存表的数量和流水表 sum 出来的数量不一致差异不大但一直存在。原因出入库代码里更新库存表和写流水不在同一个事务里或者流水写入失败后没有回滚库存更新。还有一种情况是历史数据初始化时只写了库存表没有写初始流水。解决把所有库存变动逻辑收敛到一个统一的函数里库存更新和流水写入必须在同一个事务中。初始化时用盘点单的方式写入初始流水before_qty0after_qty实际库存。上线后定期跑对账脚本发现差异立即排查。4.2 退货后成本价算错现象顾客退货后库存数量对了但毛利报表里的成本金额不对。原因退货入库时用了销售时的成本价但移动加权平均法下退货应该按当前成本价入库而不是原销售成本价。如果源码里退货逻辑直接取原单的成本价就会导致成本价偏差。解决退货入库时重新计算移动加权平均成本和采购入库用同一套逻辑。退货单的biz_type设为 3cost_price取退货时的当前成本价。如果业务上需要按原单成本退货那成本核算方法就要改成先进先出不能混用。4.3 盘点后库存被覆盖现象盘点单审核后库存数量变成了盘点数量但盘点期间发生的出入库单据被覆盖了。原因盘点逻辑是直接UPDATE stock SET qty 盘点数量没有考虑盘点期间的新增流水。正确做法是盘点单审核时计算盘点数量与当前库存的差异生成调整流水而不是直接覆盖。解决盘点单保存时记录盘点时的账面数量审核时用盘点数量 - 当前库存作为调整量写入流水。这样盘点期间的出入库不会被覆盖差异也能追溯。4.4 并发开单时单据号重复现象两个收银台同时开单生成的单据号一样导致后续查询和退货找不到单。原因单据号生成用了SELECT MAX(biz_no) 1的方式并发时两个事务读到同一个最大值。解决单据号生成用数据库序列或者 Redis 自增不要用 max1。如果源码里用的是 max1改成时间戳加随机数或者数据库自增 ID。单据号只要求唯一不要求连续所以用 UUID 也可以只是可读性差一点。4.5 商品条码重复导致入库错乱现象扫码入库时扫 A 商品的条码系统识别成了 B 商品。原因商品表没有对条码做唯一约束或者条码字段允许为空多个商品条码为空时扫码查询返回了错误记录。解决商品表的条码字段加唯一索引允许为空但不允许重复。扫码查询时如果返回多条记录提示用户手动选择。如果源码里没有唯一索引加索引前先清理重复数据。5. 从单店到多店库存调拨和权限控制的实现要点单店跑通之后如果业务扩展到多店源码需要支持库存调拨和门店权限隔离。这一章讲两个进阶功能的实现思路和关键参数。5.1 库存调拨的单据设计调拨本质上是两次库存变动调出门店出库调入门店入库。但这两次变动不能独立发生必须在一个事务里完成否则会出现货已发出但对方没收到的情况。调拨单的主表记录调出和调入门店明细表记录商品和数量。审核时执行def transfer_approve(transfer_id): 调拨单审核调出门店扣库存调入门店加库存 items db.query(SELECT * FROM transfer_item WHERE transfer_id%s, (transfer_id,)) with db.transaction(): for item in items: # 调出门店出库 outbound(item[from_warehouse_id], item[goods_id], item[qty], transfer_id) # 调入门店入库成本价取调出门店的当前成本价 cost get_cost_price(item[from_warehouse_id], item[goods_id]) inbound(item[to_warehouse_id], item[goods_id], item[qty], cost, transfer_id)调入门店的成本价取调出门店的成本价这样调拨不会产生利润只是库存位置的转移。如果源码里调拨时重新按采购价入库会导致毛利虚高。5.2 门店权限隔离的三种方案多店场景下每个门店只能看自己的库存和单据。实现方案有三种按门店 ID 过滤、按仓库 ID 过滤、按数据权限角色过滤。最简单的是在库存表和单据表加warehouse_id字段所有查询都带上这个条件。如果源码里没有这个字段改造工作量较大需要评估。权限控制建议用角色加数据范围的方式。角色定义能操作哪些菜单数据范围定义能看哪些门店的数据。这样新增门店时只需要配置数据范围不用改代码。如果源码里权限是硬编码的建议先重构权限模块再扩展多店。5.3 调拨在途库存的处理调拨单审核后、调入方确认前这批货处于在途状态。严格来说在途库存既不属于调出门店也不属于调入门店需要单独记录。简单做法是调拨单审核时调出门店直接扣库存调入门店直接加库存不记录在途。这样账面上库存是准的但实物在途时两边都查不到。如果业务上需要跟踪在途可以在调拨单加一个状态字段审核后状态为“在途”调入方确认后状态改为“已完成”库存变动在确认时才执行。两种做法各有取舍。不记录在途的实现简单适合调拨频繁但距离近的场景记录在途的实现复杂但能准确反映实物位置适合跨城市调拨。根据实际业务选不要为了技术先进而增加复杂度。5.4 多店库存查询的性能优化多店场景下库存查询需要跨门店汇总。如果门店数量多直接 join 查询会很慢。优化方式有两种一是加汇总表定时把各门店库存汇总到一张表里查询时直接读汇总表二是用缓存把库存数据缓存到 Redis查询时先读缓存。汇总表适合对实时性要求不高的场景缓存适合对实时性要求高的场景。如果源码里没有做这些优化门店数量在 10 家以内时直接查询问题不大。超过 10 家再考虑加汇总表或缓存。不要过早优化先把业务跑通。6. 用对账脚本验证库存准确性一个可复用的排查方法库存准确性是进销存系统的生命线。不管代码写得多好上线后都要定期对账。这一章给一个可复用的对账脚本以及我平时排查库存问题的习惯。6.1 对账脚本的核心逻辑对账脚本要回答三个问题库存表的数量是否等于流水表的 sum流水表的 before_qty 和 after_qty 是否连续成本价是否在合理范围内。下面是一个 Python 脚本的骨架def reconcile_stock(): 库存对账检查库存表与流水表是否一致 返回差异列表 diffs [] # 1. 数量对账 rows db.query( SELECT s.goods_id, s.qty AS stock_qty, COALESCE(SUM(f.change_qty), 0) AS flow_qty FROM stock s LEFT JOIN stock_flow f ON s.goods_id f.goods_id GROUP BY s.goods_id, s.qty HAVING s.qty ! COALESCE(SUM(f.change_qty), 0) ) for row in rows: diffs.append({ type: qty_mismatch, goods_id: row[goods_id], stock_qty: row[stock_qty], flow_qty: row[flow_qty] }) # 2. 流水连续性检查 flows db.query( SELECT goods_id, before_qty, after_qty, change_qty FROM stock_flow ORDER BY goods_id, id ) last_after {} for f in flows: gid f[goods_id] if gid in last_after and f[before_qty] ! last_after[gid]: diffs.append({ type: flow_discontinuous, goods_id: gid, expected_before: last_after[gid], actual_before: f[before_qty] }) if f[before_qty] f[change_qty] ! f[after_qty]: diffs.append({ type: flow_calc_error, goods_id: gid, before: f[before_qty], change: f[change_qty], after: f[after_qty] }) last_after[gid] f[after_qty] return diffs这个脚本跑一次就能把大部分库存问题暴露出来。qty_mismatch说明库存表和流水表不一致通常是事务问题flow_discontinuous说明流水中间有断档可能是历史数据初始化没做flow_calc_error说明流水本身的 beforechange 不等于 after是代码 bug。6.2 对账频率和差异处理对账频率根据业务量定。日均 100 单以下每周跑一次100 到 500 单每天跑一次500 单以上建议实时对账——每笔单据完成后异步检查一次。差异处理的原则是先查原因再调整不要直接改库存表。找到差异原因后用盘点单的方式调整库存这样调整本身也会留下流水记录。如果差异金额较小比如几分钱可能是小数位精度问题可以设置一个容差范围比如 0.01 以内忽略。如果差异金额较大一定要查到具体单据不能放过。6.3 我平时排查库存问题的习惯我排查库存问题的第一步永远是看流水表不是看库存表。库存表是结果流水表是过程。过程对了结果一定对过程错了结果对了也是暂时的。看流水时重点看三样变动时间是否连续、变动数量是否合理、成本价是否突变。成本价突变通常意味着加权平均算错了或者有人手工改了库存。第二个习惯是复现问题。找到可疑单据后在测试环境用同样的数据跑一遍看能不能复现。能复现的问题都好解决不能复现的问题通常是并发导致的需要加日志或者压测。第三个习惯是留后悔药。每次调整库存前先备份库存表和流水表调整后立即对账。调整操作要记录操作人和原因方便后续追溯。这些习惯看起来麻烦但比出了问题再翻日志快得多。6.4 一个具体的排查案例某次对账发现商品 A 的库存表数量比流水 sum 多了 3 个。查流水发现三天前有一笔采购入库单流水记录的数量是 10但库存表只增加了 7。进一步查代码发现那笔入库单的明细里有三行同一个商品代码在处理时只更新了第一行的库存后两行被跳过了。原因是明细表的主键设计有问题同一个商品多行时主键冲突后两行插入失败但事务没有回滚。修复方式是给明细表加自增主键不要用商品 ID 做联合主键。同时把库存更新逻辑改成按商品汇总后更新避免同一商品多次更新。这个案例的教训是明细表的主键设计要在开发初期就定好后期改成本很高。6.5 对账脚本的自动化部署对账脚本建议做成定时任务每天凌晨跑一次结果发到工作群或者邮件。如果差异条数超过阈值比如 5 条触发告警。脚本本身要幂等重复跑不会产生副作用。日志保留至少 30 天方便回溯。如果源码里没有对账功能把这个脚本加进去是投入产出比很高的一件事。它不能防止问题发生但能让你在问题扩大之前发现它。我见过太多超市因为库存不准导致盘点时才发现亏了几万块如果有对账脚本这个损失可以降到几百块。希望帮到你。本文还有配套的精品资源点击获取