小型自选商场商品管理系统：扫码入库、库存扣减与低库存预警的轻量落地

简介：这份资源面向计算机专业学生与数据库课程设计者，提供一套小型自选商场商品管理系统的完整实现方案，重点解决进货、销售、库存与收银等环节的数据管理问题。系统要求记录每笔进货与售货并支持按月统计、日盘存与月盘存，在出入库时动态刷新库存，同时可查询供应商信息，并设计收银台程序根据商品编号与数量生成购物清单及收付款信息。数据库设计涉及库存、售货、进货、供应商四张核心表，涵盖商品ID、进价售价、折扣率、最低存量等字段，适合作为课程设计或数据库综合练习的参考。资源包共189个文件，以60个sql脚本、54个cs源码、24个resx与24个resources资源文件为主，另含config配置、exe可执行程序及mdf、ldf数据库文件，压缩包约680KB，结构完整便于直接运行与二次开发。目前已有1025人学习下载，可帮助读者快速理解商品管理系统的表结构设计、库存联动逻辑与收银流程实现。

1. 小型自选商场商品管理系统：从扫码枪到库存预警，一套能落地的轻量方案

一家三百平米的社区自选商场，老板最怕的不是没客人，而是客人拿着商品到收银台，扫码枪“滴”一声，系统里查无此货。更怕的是货架上明明显示还有二十件，实际库存早就空了，补货单却迟迟没生成。这类场景我见过太多次，问题往往不在硬件，而在商品管理系统本身——要么太重，上一套 ERP 要培训半个月；要么太轻，Excel 记到第三周就彻底乱套。小型自选商场商品管理系统要解决的，就是这种“比 Excel 强、比 ERP 轻”的中间地带：商品建档、条码扫描、库存扣减、低库存预警、简易报表，五件事做扎实，门店就能跑顺。这套方案适合单店或三五家连锁的小型自选商场，也适合刚入行的开发者拿来做第一个完整业务系统。

2. 商品建档与条码体系：为什么你的商品主数据总是对不上

商品管理系统翻车，十有八九翻在商品主数据上。条码重复、一品多码、多码一品、单位混乱，这些问题在 Excel 阶段还能靠人眼盯，一旦上了系统就会变成库存对不上的根源。我一般会把商品主数据拆成三层：商品 SPU、规格 SKU、条码映射。SPU 管“这是什么”，SKU 管“这个具体规格卖多少钱、库存多少”，条码映射管“扫到这个码该找哪个 SKU”。三层分开之后，一个商品可以有多个条码，一个条码也可以临时绑定到不同 SKU，处理起来灵活得多。

2.1 商品主数据的三层结构设计

先看表结构。下面这段 SQL 是 MySQL 建表语句，核心是三张表：product_spu、product_sku、barcode_mapping。注意barcode_mapping里我留了status字段，用来处理条码换绑的历史记录，而不是直接物理删除。

-- 商品SPU表：管商品是什么 CREATE TABLE product_spu ( spu_id BIGINT PRIMARY KEY AUTO_INCREMENT, spu_name VARCHAR(128) NOT NULL COMMENT '商品名称', category_id INT NOT NULL COMMENT '分类ID', brand VARCHAR(64) DEFAULT '' COMMENT '品牌', unit VARCHAR(16) NOT NULL DEFAULT '件' COMMENT '基本单位', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 商品SKU表：管具体规格、价格、库存 CREATE TABLE product_sku ( sku_id BIGINT PRIMARY KEY AUTO_INCREMENT, spu_id BIGINT NOT NULL, sku_name VARCHAR(128) NOT NULL COMMENT '规格名，如500ml', sale_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, cost_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, stock INT NOT NULL DEFAULT 0, stock_warn INT NOT NULL DEFAULT 10 COMMENT '低库存预警阈值', status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', INDEX idx_spu (spu_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 条码映射表：管扫到这个码找哪个SKU CREATE TABLE barcode_mapping ( id BIGINT PRIMARY KEY AUTO_INCREMENT, barcode VARCHAR(64) NOT NULL, sku_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1有效 0失效', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_barcode_active (barcode, status), INDEX idx_sku (sku_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：product_spu和product_sku是一对多关系，一个 SPU 下可以有多个规格。barcode_mapping用(barcode, status)做联合唯一索引，这样同一个条码在有效状态下只能绑定一个 SKU，但失效记录可以保留多条，方便追溯。参数上，stock_warn默认给 10，实际按品类调整，生鲜类可以设 5，日化类可以设 20。

2.2 条码扫描入库的完整流程与代码实现

建档之后，日常操作就是扫码入库。下面这段 Python 代码模拟扫码枪输入后的处理逻辑：先查条码映射，找到 SKU 后更新库存，同时写一条库存流水。注意我用了SELECT ... FOR UPDATE来避免并发扫码时的库存覆盖问题。

import pymysql def handle_scan_in(barcode: str, qty: int, operator: str): """ 扫码入库：条码 -> SKU -> 增加库存 -> 写流水 barcode: 扫码枪读到的条码 qty: 入库数量 operator: 操作员标识 """ conn = pymysql.connect(host='127.0.0.1', user='shop', password='shop123', database='shop_db', charset='utf8mb4') try: with conn.cursor() as cur: conn.begin() # 1. 查有效条码映射 cur.execute( "SELECT sku_id FROM barcode_mapping WHERE barcode=%s AND status=1", (barcode,) ) row = cur.fetchone() if not row: raise ValueError(f"条码 {barcode} 未绑定任何SKU") sku_id = row[0] # 2. 锁定SKU行，避免并发覆盖 cur.execute( "SELECT stock FROM product_sku WHERE sku_id=%s FOR UPDATE", (sku_id,) ) old_stock = cur.fetchone()[0] # 3. 更新库存 cur.execute( "UPDATE product_sku SET stock=stock+%s WHERE sku_id=%s", (qty, sku_id) ) # 4. 写库存流水 cur.execute( "INSERT INTO stock_log (sku_id, change_type, change_qty, " "before_stock, after_stock, operator) VALUES (%s,'IN',%s,%s,%s,%s)", (sku_id, qty, old_stock, old_stock + qty, operator) ) conn.commit() return {"sku_id": sku_id, "before": old_stock, "after": old_stock + qty} except Exception as e: conn.rollback() raise e finally: conn.close()

逻辑说明：整个流程分四步——查映射、锁库存、改库存、写流水。FOR UPDATE是关键，没有它，两个收银台同时扫同一个商品时，后提交的事务会覆盖前一个的库存变化。参数上，qty支持负数表示退货入库，operator建议用收银员工号而不是姓名，避免重名问题。库存流水表stock_log我建议至少保留change_type、before_stock、after_stock三个字段，对账时能直接看出每一笔变化。

2.3 一品多码与多码一品的处理策略

实际门店里，同一个商品可能有多个条码：厂家原码、店内自编码、促销临时码。我的做法是在barcode_mapping里允许多条记录指向同一个sku_id，但同一时刻只有一个条码是status=1。换绑时先把旧记录置为status=0，再插入新记录。这样既保证扫码唯一性，又保留历史。反过来，多码一品的情况，比如不同供应商送来的同款商品条码不同，就建多个映射指向同一个 SKU，库存合并计算。这里有个坑：如果两个条码指向不同 SKU 但实际是同一个商品，库存就会分裂，所以建档时一定要先确认条码归属。

3. 库存扣减与低库存预警：并发场景下怎么保证不超卖

库存扣减是商品管理系统里最容易出玄学问题的地方。收银台扫码、线上订单、手工出库，三个入口同时改库存，稍不注意就超卖或者库存对不上。我一般会把库存扣减统一到一个服务里，所有入口都调这个服务，内部用数据库行锁或者乐观锁保证一致性。低库存预警则是在每次扣减后检查stock <= stock_warn，触发补货提醒。

3.1 收银台扫码扣减库存的事务边界

收银台扫码扣减和入库逻辑类似，但方向相反，而且通常一次交易涉及多个商品。下面这段代码展示了一个事务内处理多个商品扣减的写法，注意每个 SKU 都要单独锁行，锁的顺序按sku_id升序，避免死锁。

def checkout(cart_items: list, operator: str): """ 收银结算：批量扣减库存 cart_items: [{"sku_id": 1, "qty": 2, "price": 5.00}, ...] """ conn = pymysql.connect(host='127.0.0.1', user='shop', password='shop123', database='shop_db', charset='utf8mb4') try: with conn.cursor() as cur: conn.begin() # 按sku_id排序，避免死锁 items = sorted(cart_items, key=lambda x: x['sku_id']) for item in items: sku_id, qty = item['sku_id'], item['qty'] cur.execute( "SELECT stock, stock_warn FROM product_sku " "WHERE sku_id=%s FOR UPDATE", (sku_id,) ) row = cur.fetchone() if not row: raise ValueError(f"SKU {sku_id} 不存在") stock, warn = row if stock < qty: raise ValueError(f"SKU {sku_id} 库存不足，当前{stock}，需要{qty}") cur.execute( "UPDATE product_sku SET stock=stock-%s WHERE sku_id=%s", (qty, sku_id) ) cur.execute( "INSERT INTO stock_log (sku_id, change_type, change_qty, " "before_stock, after_stock, operator) VALUES (%s,'OUT',%s,%s,%s,%s)", (sku_id, -qty, stock, stock - qty, operator) ) # 低库存预警检查 if stock - qty <= warn: cur.execute( "INSERT INTO stock_warn_log (sku_id, current_stock, warn_threshold) " "VALUES (%s,%s,%s)", (sku_id, stock - qty, warn) ) conn.commit() except Exception as e: conn.rollback() raise e finally: conn.close()

逻辑说明：事务内先按sku_id排序再逐个锁行，这是避免死锁的标准做法。库存不足时直接抛异常回滚，保证不会出现负库存。低库存预警在扣减后立即检查，写入stock_warn_log表，后续可以用定时任务或者消息通知补货。参数上，stock_warn是每个 SKU 独立配置的，生鲜类可以设 5，日化类设 20，这个值需要根据日均销量动态调整。

3.2 低库存预警的触发条件与通知方式

预警触发条件我一般设两个：一是stock <= stock_warn，二是连续 N 天销量超过阈值但库存没补。第二个条件需要结合销售流水做统计，适合用定时任务每天跑一次。通知方式看门店习惯，简单点就写一张stock_warn_log表，收银台开机时弹窗提醒；复杂点可以对接企业微信或者短信，但小型商场一般用不上。下面这段 SQL 是每天凌晨统计需要补货的 SKU：

-- 低库存预警查询：当前库存低于阈值，且最近7天有销售 SELECT s.sku_id, p.spu_name, s.sku_name, s.stock, s.stock_warn, COALESCE(SUM(sl.change_qty), 0) AS sales_7d FROM product_sku s JOIN product_spu p ON s.spu_id = p.spu_id LEFT JOIN stock_log sl ON s.sku_id = sl.sku_id AND sl.change_type = 'OUT' AND sl.create_time >= DATE_SUB(NOW(), INTERVAL 7 DAY) WHERE s.status = 1 AND s.stock <= s.stock_warn GROUP BY s.sku_id ORDER BY sales_7d DESC;

逻辑说明：这个查询把低库存和近 7 天销量结合起来，销量高的排前面，补货优先级更明确。COALESCE处理没有销售记录的情况，避免 NULL 影响排序。参数上，INTERVAL 7 DAY可以按门店补货周期调整，一周补两次的店可以改成 3 天。

3.3 盘点差异调整与库存流水追溯

盘点发现账实不符时，不要直接改stock字段，而是走一笔“盘点调整”流水。下面这段代码展示调整逻辑，change_type用'ADJ'，change_qty是差异值，正数表示盘盈，负数表示盘亏。

def adjust_stock(sku_id: int, actual_stock: int, operator: str, reason: str): """盘点调整：按实际库存修正，写调整流水""" conn = pymysql.connect(host='127.0.0.1', user='shop', password='shop123', database='shop_db', charset='utf8mb4') try: with conn.cursor() as cur: conn.begin() cur.execute("SELECT stock FROM product_sku WHERE sku_id=%s FOR UPDATE", (sku_id,)) old_stock = cur.fetchone()[0] diff = actual_stock - old_stock if diff == 0: conn.commit() return cur.execute("UPDATE product_sku SET stock=%s WHERE sku_id=%s", (actual_stock, sku_id)) cur.execute( "INSERT INTO stock_log (sku_id, change_type, change_qty, " "before_stock, after_stock, operator, remark) VALUES (%s,'ADJ',%s,%s,%s,%s,%s)", (sku_id, diff, old_stock, actual_stock, operator, reason) ) conn.commit() except Exception as e: conn.rollback() raise e finally: conn.close()

逻辑说明：调整流水里change_qty记录差异值，before_stock和after_stock记录调整前后库存，remark写调整原因。这样任何时候都能通过stock_log追溯库存变化历史，对账时直接查流水就行，不用猜。

4. 避坑与排查：商品管理系统上线后最容易翻车的五个点

4.1 条码重复导致库存分裂

现象：同一个商品扫不同条码，库存分别扣在不同 SKU 上，盘点时发现两个 SKU 库存都不对。原因：建档时没做条码唯一性校验，或者换绑时旧映射没置为失效。解决：barcode_mapping表加(barcode, status)联合唯一索引，换绑时先UPDATE status=0再插入新记录。上线前跑一遍全量条码查重 SQL，把重复的挑出来人工确认。

4.2 并发扣减导致超卖

现象：两个收银台同时卖最后一个商品，系统都显示扣减成功，实际库存变成 -1。原因：扣减时没加行锁，或者用了SELECT之后UPDATE但中间没有FOR UPDATE。解决：所有库存扣减走同一个事务，SELECT ... FOR UPDATE锁行，扣减前检查库存是否足够。如果并发量不大，也可以用乐观锁版本号，但小型商场用行锁更简单直接。

4.3 低库存预警不触发

现象：库存已经降到 3，但预警阈值设的是 10，系统没提醒。原因：预警检查只在入库时做了，扣减时漏了；或者stock_warn字段默认值是 0，建档时没改。解决：扣减和入库后都检查stock <= stock_warn，建档时强制填写预警阈值，给一个合理默认值比如 10。另外注意stock_warn是 SKU 级别的，不是 SPU 级别，别设错地方。

4.4 盘点调整直接改库存字段

现象：盘点后直接UPDATE product_sku SET stock=实际值，过几天发现库存对不上，但查不到谁改的。原因：没写调整流水，库存变化没有追溯记录。解决：所有库存变化必须走stock_log，包括盘点调整。调整时记录before_stock、after_stock、change_qty、operator、remark，对账时直接查流水。

4.5 商品下架后条码仍可扫描

现象：商品已经下架，但收银台扫码还能扫出来，导致误卖。原因：下架时只改了product_sku.status=0，没同步失效barcode_mapping。解决：下架 SKU 时，同步把对应条码映射置为status=0。或者扫码查询时加一层JOIN product_sku ON status=1，但这样索引效率会低一些，建议还是同步失效。

5. 从单店到多店：商品管理系统的扩展边界与一个实用技巧

单店跑顺之后，如果开第二家店，商品管理系统就要面对多店库存的问题。我的建议是不要急着上分布式，先把“门店”作为一个维度加进现有表结构。具体做法：product_sku表里的stock字段拆成store_stock表，按store_id + sku_id存库存，stock_log也加store_id。这样单店逻辑不变，多店只是多了一个过滤条件。下面这张表是扩展后的库存表结构：

主键用(store_id, sku_id)联合主键，查询时带上store_id就能隔离各店库存。调拨场景再加一张stock_transfer表，记录从 A 店到 B 店的调拨流水，调拨时 A 店扣减、B 店增加，两边都写流水。

一个实用技巧：库存对账不要每天全量跑，只跑“有变动的 SKU”。具体做法是每天凌晨查stock_log里create_time在昨天的sku_id去重列表，只对这些 SKU 做账实核对。这样对账 SQL 从全表扫描变成索引范围扫描，几百个 SKU 的店几秒钟就跑完。我自己的习惯是每周做一次全量对账，每天做增量对账，增量对账发现异常再触发全量。这个习惯帮我提前发现过好几次条码换绑没同步的问题，省了不少事后翻账的麻烦。希望帮到你。

本文还有配套的精品资源，点击获取