简介这是一套面向超市运营场景的进销存管理系统提供商品进货、销售管理、库存统计、订单管理等功能模块适合超市管理人员、信息系统相关专业学生及开发者参考使用用以掌握业务流程数字化实现方式。压缩包共103个文件涵盖C#源程序、ASP.NET页面、数据库文件、CSS样式表及用例图等图片素材其中源程序对应各业务逻辑页面文件支持前端交互数据库文件保存核心业务数据整体大小仅2.03MB便于快速下载与部署。目前已有4379人学习下载常用于课程设计或毕业设计环节。资源附带的用例图清晰展示了员工、顾客、供应商与系统间的交互关系配合可运行的源码和数据库可帮助使用者理解进销存系统的设计思路了解商品进货、销售开单、库存预警、订单查询等典型流程并在此基础上进行功能扩展或撰写设计文档。1. 超市进销存管理系统到底在解决什么从理货单到用例图的距离做超市进销存管理系统的人通常带着一个很具体的诉求而来把进货、卖货、退换货、库存盘点这些每天都在发生、但一直靠纸笔和记忆运转的事情变成一套能查账、能对账、能知道哪个商品压了多少货的系统。这个标题里真正容易被低估的是「附用例图」四个字。很多人把用例图当作项目文档里的装饰画完就丢实际上用例图才是这套系统能不能少返工的关键——参与者、功能边界、角色权限在图上掰扯清楚后面写代码、设计表结构都是照着图走不需要反复推翻。这篇笔记的目标读者也很明确要么是正在做课程设计或毕设的学生要么是接了小超市管理系统外包、想快速交付的开发者。我按一套常见做法把需求分析、用例图、数据库设计、核心业务代码和踩坑记录拆开讲你照着做能在一个周末把系统从图跑到能演示、能验收。2. 用例图先于代码把参与者、用例与关系画到能落地2.1 参与者和用例识别别把按钮当功能画用例图的第一步不是打开绘图工具而是先做参与者识别。我见过不少人把用例图画成了功能菜单树——「商品管理」「供应商管理」「系统设置」各画一个大框然后往里面塞几十个小用例画完自己都说不清每个用例的价值。正确的做法是先问这个系统里有哪几类人他们各自要完成什么业务目标。超市进销存最常见的参与者有三类收银员、采购员、店长通常兼任系统管理员。收银员的目标是完成销售、处理退货采购员的目标是根据缺货情况生成采购单、对入库单做验收确认店长要的是看库存、看毛利、做盘点、管员工账号。这里有一个很实用的判断标准参与者是「人」用例是「目标」而诸如「登录」「修改密码」这类支撑性功能通常是系统的公共能力可以单独抽出来不要混在业务用例里。在实际练习里我一般会让 A 同学先在白纸上列出 8 到 10 个候选用例然后逐个问一句这个用例完成之后参与者得到了什么业务结果如果答案是「只是系统里多了一条数据业务上没有变化」那这个用例大概率是功能操作不是业务用例。比如「新增商品」就不算独立用例它只是「维护商品档案」这个目标下的子功能「录入采购入库单」才算因为它对应了「货物实际到店并验收入库」这个业务事件。这个区分直接决定了用例图的信息密度——好的用例图一张能讲清楚坏的一张图有两百个节点。用例清单可以先用表格列出来方便后面核对数据库设计和开发任务参与者核心用例业务结果收银员销售出库、退货处理、当日交班库存扣减、收款记录、销售报表数据采购员采购入库、采购退货、供应商查询库存增加、应付账款变动店长库存盘点、调价、报表查看、员工账号维护账实一致、价格更新、经营决策数据系统公共登录、权限校验、操作日志安全边界与可追溯2.2 用 PlantUML 出图用例图代码与 include / extend 的取舍工具层面常见做法是画用例图用 PlantUML因为它用纯文本描述图结构放进项目仓库里好维护改起来也比拖拽工具快。业务方要看得懂也可以用 draw.io 导成图片。PlantUML 代码并不复杂核心就是三样东西参与者、用例、关系。下面这份是我常用的超市进销存用例图 PlantUML 代码你可以直接复制保存为usecase.pumlstartuml left to right direction actor 收银员 as Cashier actor 采购员 as Purchaser actor 店长 as Manager rectangle 超市进销存管理系统 { usecase 登录 as Login usecase 销售出库 as Sale usecase 退货处理 as Refund usecase 采购入库 as StockIn usecase 采购退货 as StockOut usecase 库存盘点 as Count usecase 商品档案维护 as Product usecase 报表查看 as Report usecase 员工账号维护 as Account Login . Cashier Login . Purchaser Login . Manager Cashier -- Sale Cashier -- Refund Purchaser -- StockIn Purchaser -- StockOut Manager -- Count Manager -- Product Manager -- Report Manager -- Account StockIn . Login : include StockOut . Login : include Sale . Login : include Count . Login : include } enduml这段代码里需要注意两个点。第一所有业务用例都用include指向「登录」意思是执行这些用例之前必须完成身份验证这是 include 关系的典型用法——被包含的用例是公共步骤不是独立业务目标。第二不要滥用extend。extend 表示「在特定条件下才附加执行」的可选行为比如「销售出库」在遇到顾客退货时可以 extend 到「退货处理」但它不是每次收银都触发。如果在图里把所有关联都画成 extend业务方会误以为那些是必选流程需求和实现的偏差就是这么产生的。产出这张图之后用例图还可以直接作为模块开发清单使用。比如 StoreManager 角色对应的 Count、Product、Report、Account 四个用例开发时就可以拆成四个后端模块。图和代码的映射关系越清晰越不容易出现做完销售模块才发现库存表没设计的尴尬。在提交项目文档的时候这份.puml源码比一张截图更有说服力因为它能反推出你当时对边界的思考而截图只能看出最终结果。2.3 用例图与数据权限的映射从图到模块清单用例图不是画完就完了它要能直接指导后面的数据库权限设计。超市进销存系统里最常见的权限问题是收银员误操作进了后台改了商品价格或者采购员看到了营业毛利——这些在用例图上其实已经暴露了只是很多人没注意。回看上一节中的用例图收银员只连到「销售出库」和「退货处理」所以数据库层面他可以读写销售单、退货单、查询商品基础信息采购员连到「采购入库」和「采购退货」所以他只对采购类单据有增删改权限店长对所有用例可见自然拥有全部表的读写权限。在实现时常见做法是做一个简单的 RBAC角色-权限模型用户表挂角色角色挂权限点权限点对应到后端接口的路径或方法名。比如product:edit这个权限点只分配给店长角色收银员登录后即使猜到接口地址后端也会在拦截器里直接拒绝。这个映射关系要在用例图阶段就定下来不然等接口写完再补权限改动成本会高很多因为那时候前端路由、后端接口、按钮显隐都已经耦合在一起了。另一个实用的映射技巧是用例图到菜单树Manager 看到的菜单包含「盘点」「报表」「账号管理」而 Cashier 只有「收银台」「退货」两个菜单入口。前端路由表按角色动态生成后端接口按权限点做拦截双端配合才能保证不出现「前端隐藏了按钮、后端接口照样能调用」的安全漏洞。很多进销存项目翻车并不是功能做不出来而是这个边界没在用例图阶段划清楚导致后期反复打补丁。3. 数据库设计先行五张核心表的字段与边界参数3.1 商品与库存表价格精度、库存数量用什么类型用例图定了功能边界接下来就是数据库设计。超市进销存系统的核心不是业务逻辑多复杂而是字段类型选错导致账目对不上这在项目中非常常见。先说商品表和库存表。商品表的核心字段包括商品编码、条码、名称、规格、进价、售价、供应商ID、分类、状态。这里最容易犯的错有两个。第一个是把价格字段设计成FLOAT或DOUBLE。浮点数在计算机里是近似存储0.1 0.2 在二进制里算出来不是 0.3连续记几笔账之后库存金额、毛利这些汇总数据就会漂移对账的时候差几分钱查得人想摔键盘。正确做法是全部用DECIMAL(10,2)金额类字段固定两位小数由数据库而不是应用层保证精度。第二个常见错误是库存数量用无符号整型这会导致一旦业务上出现盘亏或者退货冲销时库存暂时变负SQL 直接报错。库存应该用有符号的INT数量在应用层做非负校验这样既允许中间态出现又能通过逻辑锁避免真正的负数库存落库。商品表的设计我一般会给出这样一份建表 SQLCREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, product_code VARCHAR(32) NOT NULL UNIQUE COMMENT 商品编码内部使用, barcode VARCHAR(32) DEFAULT NULL COMMENT 条码扫码枪输入, name VARCHAR(64) NOT NULL COMMENT 商品名称, spec VARCHAR(64) DEFAULT NULL COMMENT 规格如 500ml/瓶, purchase_price DECIMAL(10,2) NOT NULL COMMENT 进货价, sale_price DECIMAL(10,2) NOT NULL COMMENT 零售价, supplier_id BIGINT NOT NULL COMMENT 默认供应商ID, category VARCHAR(32) DEFAULT NULL COMMENT 分类, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_supplier (supplier_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品档案表;参数说明里有三个地方值得关注。product_code用于系统内部关联应当包含分类信息比如FOOD0001方便按前缀筛选barcode可以为空因为不是所有商品都有条码但一旦扫码枪扫到重复条码应用层要做合并或提示处理状态字段用TINYINT而不是字符串是为了索引效率查询上架商品只需WHERE status 1。库存表建议单独建不要和商品表混在一张表里因为盘点时要锁库存行把读写频繁的库存字段独立出来能减少锁竞争CREATE TABLE inventory ( id BIGINT AUTO_INCREMENT PRIMARY KEY, product_id BIGINT NOT NULL UNIQUE COMMENT 商品ID, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存数量允许为负的中间态, safety_stock INT NOT NULL DEFAULT 0 COMMENT 安全库存低于此值提示补货, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_quantity (quantity) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存表;这里的UNIQUE约束很重要——它确保一个商品只有一行库存记录并发更新时不会产生多行脏数据。safety_stock字段是给采购员的补货提醒用的低于阈值时报表页标红。很多项目把安全库存逻辑写在代码里但代码改起来比改字段麻烦而且多个模块要重复判断放在表里更利于一致性。3.2 单据表与明细表为什么主从表结构能保账实一致进销存系统里最难设计也最容易翻车的是单据类表。无论是采购入库单还是销售出库单都要遵循「主表 明细表」的主从结构。主表记录这次业务事件本身的信息比如单据号、操作人、总金额、时间明细表记录这个单据下每一件商品的详情比如商品ID、数量、当时的单价、小计金额。这样设计的原因很直接一张销售单可能包含十几种商品如果把商品明细直接拼在主表的一个字段里后续对账、退货、按商品维度统计全都做不了。主从表还能保持历史快照——明细表里的单价记录的是「成交那一刻的价格」即便后来商品调价了这张单子的金额也不受影响。这是进销存系统账实一致的根基。销售出库主表和明细表的建表 SQL 如下CREATE TABLE sale_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 销售单号格式如 S202501010001, cashier_id BIGINT NOT NULL COMMENT 收银员用户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 应收总额, status TINYINT NOT NULL DEFAULT 0 COMMENT 0进行中 1已完成 2已作废, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_cashier_time (cashier_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT销售主表; CREATE TABLE sale_order_item ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT 主表ID, product_id BIGINT NOT NULL, quantity INT NOT NULL COMMENT 销售数量, unit_price DECIMAL(10,2) NOT NULL COMMENT 成交单价快照字段, subtotal DECIMAL(10,2) NOT NULL COMMENT 小计金额, KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT销售明细表;注意sale_order_item里没有单独设置order_no冗余字段这是有意的设计。查询某一单的明细时通过order_id关联主表即可避免冗余存储导致的数据不一致。但在超市场景里还有一种查询很常见顾客拿小票来退货小票上只有order_no而没有内部 ID。实际项目里这种情况怎么办我一般会在主表的order_no上建立唯一索引因为它是业务自然键退货时先按order_no查主表拿到id再按id查明细。这样做索引占用很小且语义清晰。主从表还有一个细节是状态管理。主表的status字段必须支持「作废」状态而不是直接删除记录原因在于财务审计要求操作留痕。一旦删除了作废单据库存流水就会出现空洞月末对账时无法解释某次扣减是从哪来的。作废单在报表里可以显示为灰色并计入异常单统计但数据必须保留。这和后面要讲的盘点逻辑是联动的。3.3 初始化数据与演示账号让系统三天内能跑起来数据库设计完成后紧接着要做的是初始化数据而不是急着写业务代码。进销存系统项目里最煞风景的演示场景就是从商品档案到供应商信息全空收银员登录后连一个商品都扫不出来。所以我在设计阶段就会顺手准备一套 seed 数据脚本至少包含 20 个典型的超市商品覆盖饮料、零食、日化、生鲜四个大类每个商品的进价、售价、库存量、安全库存都要合理——比如一瓶矿泉水的进价不能比售价还高库存量不能全是负数否则演示时被现场问一句「这个数据怎么看着不合理」就尴尬了。初始化脚本里还应包含三组演示账号收银员、采购员、店长各一个密码用 MD5 或 BCrypt 加密存储。常见的坑是直接用明文密码初始化的测试没问题但交付的时候一旦用户忘记改密码整个系统的权限边界就形同虚设。账号初始化脚本的写法如下INSERT INTO sys_user (username, password, role, nickname) VALUES (cashier01, e10adc3949ba59abbe56e057f20f883e, CASHIER, 收银员小张), (buyer01, 25f9e794323b453885f5181f1b624d0b, BUYER, 采购员小李), (manager01, e10adc3949ba59abbe56e057f20f883e, MANAGER, 店长老王);这段 SQL 里e10adc3949ba59abbe56e057f20f883e对应123456的 MD5这在项目里只是演示用途正式环境必须升级为 BCrypt 并加盐。角色字段用字符串是为了可读性但实际查询时推荐建一个sys_role表来管理因为后续大概率要扩展权限点硬编码字符串会越写越乱。初始化数据做完之后整个系统已经有一个可以演示的骨架后端的业务代码只需要在这个骨架上填充接口节奏会快很多。4. 核心业务落地入库、出库、盘点的最小可运行实现4.1 入库接口事务、锁与单据号生成数据库表结构就绪后进入业务代码实现阶段。进销存系统真正的复杂度不在增删改查而在「多个表要同时变化」的事务一致性和「并发时不能超卖」的锁控制。先看入库流程采购员在界面上选择商品、填数量、提交后端要做的事包括生成采购入库单号、插入主表记录、插入明细表记录、累加库存、写入库存流水。这四步任意一步失败整单都不能生效。常见做法是使用 Spring Boot 的事务注解标记入库方法。一个典型的最小实现如下Transactional(rollbackFor Exception.class) public Long createStockIn(StockInRequest request) { // 1. 生成单据号格式RK 日期 3位随机数如 RK20250115001 String orderNo generateOrderNo(RK); // 2. 写主表 StockInOrder order new StockInOrder(); order.setOrderNo(orderNo); order.setSupplierId(request.getSupplierId()); order.setOperatorId(request.getOperatorId()); order.setStatus(0); stockInOrderMapper.insert(order); // 3. 写明细表 累加库存 for (StockInItem item : request.getItems()) { StockInOrderItem detail new StockInOrderItem(); detail.setOrderId(order.getId()); detail.setProductId(item.getProductId()); detail.setQuantity(item.getQuantity()); detail.setPurchasePrice(item.getPurchasePrice()); stockInOrderItemMapper.insert(detail); inventoryMapper.increaseQuantity(item.getProductId(), item.getQuantity()); } return order.getId(); }逻辑说明Transactional保证了主表、明细表、库存更新要么全部成功要么全部回滚不会出现「主表写入了明细丢失」的中间状态。单据号生成放在事务开头如果事务回滚了单据号也就丢弃了这在超市场景下是可接受的因为每天的入库单量级不大不需要严谨的号段不重不漏。参数方面increaseQuantity对应如下 SQLUPDATE inventory SET quantity quantity #{delta}, update_time NOW() WHERE product_id #{productId}这里使用了数据库的行级自增而不是先在代码里查询再在代码里加目的是避免并发场景下的脏写两条入库请求同时读到一个旧库存值各自加完再写回后写的那次会覆盖先写的那次导致库存少加。直接SET quantity quantity delta由数据库的锁机制保证原子性无论并发多少条都能累加正确。这是进销存系统里最基础也最重要的一个写法。4.2 出库扣库存避免超卖的两种写法出库扣库存是进销存系统里最容易出现翻车事故的地方。想象一个场景店里只剩 3 瓶可乐两个收银员几乎同时按下收款键系统库存却是先查后减的写法——两个请求都读到 3各自减 1 后写回 2实际卖出去 2 瓶库存显示 2账实对不上。多卖几单后库存就飘了。避免超卖有两种常见写法我先说明第一种也是推荐优先使用的条件更新。在减库存的 SQL 里带上quantity delta的条件作为乐观锁约束UPDATE inventory SET quantity quantity - #{delta}, update_time NOW() WHERE product_id #{productId} AND quantity #{delta}这段 SQL 的执行结果是如果库存不足受影响行数为 0应用层通过判断返回值决定是抛异常提示「库存不足」还是进入「允许负库存」的备选流程。数据库的行锁保证了同一时间只有一个请求能成功扣减不会有任何并发请求读到旧值。这是一个很干净的做法不需要额外引入分布式锁或 Redis 预扣库存对于中小超市的数据量完全够用。第二种写法是在应用层使用 Redis 的原子减操作做预扣库存余量放一份到 Redis先扣 Redis 再扣数据库扣减成功后再异步同步数据库。这种做法的优势是抗高并发峰值适合双十一那种级别的流量。但超市收银场景的并发远到不了这个量级引入 Redis 反而增加了缓存与数据库双写一致性这个额外的维护成本——一旦 Redis 和数据库不同步对账就是一场灾难。所以我通常的建议是单体应用 条件更新的 SQL完全能覆盖收银台的并发需求不要为了架构好看而引入不必要的复杂度。出库扣库存的整个流程还必须和销售单的创建在同一个事务里。很多项目拆成「先创建订单下单后再减库存」两个操作之间一旦出现异常就会出现有单无货或者有货无单的脏数据。正确做法是创建sale_order、sale_order_item、扣减库存三个操作放在同一个事务方法里任一步失败全部回滚保证系统的每个状态都对应一个完整的业务事件。4.3 盘点差异调整盘盈盘亏怎么入账盘点这一块是小超市系统里经常被做砸的功能。很多人把盘点做成「直接改库存数量」对着数据库把数字改成实际数就完事结果库存是修正了但钱的账是乱的——因为盘亏的库存对应的是真金白银的损失必须留下可追溯的记录。正确做法是为盘点单独设计流程而不是直接改库存。一个最小可行的盘点流程包含三个动作创建盘点单 → 录入实盘数量 → 生成差异调整单并更新库存。在创建盘点单时系统先冻结当前库存快照录入实盘数量后系统自动计算差异实盘数减账面数正数为盘盈、负数为盘亏提交后生成一张inventory_adjust调整单把差异落进库存流水同时更新库存表。盘亏调整的核心 SQL 和入库类似但要注意方向-- 盘盈库存加 UPDATE inventory SET quantity quantity #{diff} WHERE product_id #{productId}; -- 盘亏库存减但用条件更新防止把库存扣成负的 UPDATE inventory SET quantity quantity - #{absDiff} WHERE product_id #{productId} AND quantity #{absDiff};这里有个参数细节值得说明盘亏扣减时如果quantity不够减比如之前已经欠库存了条件更新会返回 0 行此时不应该强扣而应该让盘点单进入「审核中」状态由店长确认是否接受负库存。这是很多课程设计里被忽略的业务边界。盘点差异完全不应该静默写入库存每一笔差异都要关联到对应的调整单号这样月末对账时每一笔库存变化都能追到源头——是销售单、入库单、退货单还是盘点调整单。5. 进销存系统避坑实录5 个让项目翻车的细节5.1 现象销售单创建成功了库存却没扣这是高发问题。代码里创建订单和扣减库存分别写在两个 Service 方法里先调了saleService.createOrder()又调inventoryService.deduct()两个方法各自带事务。当扣库存抛异常回滚时订单事务已经提交了库存就成了「只卖不扣」。原因分析事务边界没有收敛。跨 Service 调用时因为默认的传播机制是「有事务就加入」理论上应该复用同一个事务但有些项目里Transactional加在私有方法上不生效或者两个方法不在同一个代理对象上导致事务实际变成两个独立提交。解决办法把创建订单和扣库存合并到同一个事务方法中并且确认Transactional加在公开方法上。更稳妥的验证手段是在测试里写一个 mock 库存不足的用例断言sale_order表中不会残留记录。这个用例应该写进项目的基础测试集里每次改动都跑一遍防止回归。5.2 现象商品价格用FLOAT之后报表小数位离奇跳变某个晚上盘点时发现售价 9.9 的商品进价成本是 6.6账面上算出来的毛利率却带着一堆不规律的小数尾巴怎么对都对不上。原因非常简单FLOAT是浮点存储6.6在二进制里是无限循环小数存储时被截断多次运算后误差累积。很多人对「数据库字段类型无所谓」这个认知有误区进销存对精度敏感这类系统里所有金额和单价都必须是DECIMAL。解决办法全局搜索建表语句把FLOAT/DOUBLE一律换成DECIMAL(10,2)对已经是FLOAT的存量数据先写一次修正脚本来重算金额字段。这里还有一个额外提醒不仅数据库要用定点数Java 端也要用BigDecimal避免从数据库取出后转double再运算。代码里一行float total ...就足以让前面所有数据库层面的努力白费。5.3 现象用例图里画了「include 登录」实现时每个接口都要做权限判断代码重复到吐有人照着用例图画出去了实现时发现「登录」这个 include 关系真的在每个业务接口里都写了一遍重复的鉴权逻辑。原因是对 include 关系的理解太机械了。在用例图中表示「所有业务用例包含登录」到了代码层面应该是抽象出一个过滤器或拦截器而不是把相同的代码复制到每个 Controller 的方法里。解决办法用 Spring MVC 的HandlerInterceptor或 Servlet Filter在进入 Controller 之前统一做 token 校验和角色判断业务方法只负责自己的业务逻辑。这样才真正还原了 include 关系的语义——它是一个横切关注点不是业务代码的一部分。类似的还有操作日志用例图里每个用例都可能记录日志但代码里应该用 AOP 统一处理而不是在每个方法里手写。5.4 现象盘点流程能快速改库存但审计时谁也说不清那批盘亏去哪了这是初学者最容易犯的业务设计错误。把盘点和调库存做成一个接口点了「提交」库存直接变化没有调整单、没有审核、没有库存流水。月底对账发现毛利异常却找不到是哪一笔导致的。原因分析把「业务结果」和「数据写入」混为一谈。盘点这个业务事件真正关心的是「账实差异是否被合理记录和批准」而不只是「库存数字变了」。直接改库存的方法跳过了记录环节等于档案馆里偷换了一页纸内容变了但没有备份。解决办法严格按照「盘点单 → 实盘录入 → 差异调整单 → 审批 → 更新库存」五步走。数据库表结构上要有一张inventory_adjust主表加inventory_adjust_item明细表调整单的状态顺序是「草稿 → 待审核 → 已审核 → 已生效」。在盘点单尚未审核通过之前库存字段不能被修改。每一笔差异都有单据号可查整个链路才算闭环。5.5 现象前端传了字符串日期后端按时间戳存报表按天汇总时丢了数据某个项目里销售单日期在创建时报的是2025-01-15 23:59:59到了次日凌晨刚过 0 点又来了一单此时第一单已经「过了一天」当天的销售汇总就缺了前一日的最后一笔订单。这类问题排查起来特别耗时因为数据存在单子也在但统计口径不对。原因分析数据库的DATETIME存储带时间按天分组要精确处理日期边界。如果前端传的是2025-01-15这种纯日期后端在处理查询条件时默认拼了一个00:00:00而2025-01-15 23:59:59的记录就会被「今天没这一单」筛掉。解决办法查询条件统一用半开区间例如查询某一天使用 2025-01-15 00:00:00 AND 2025-01-16 00:00:00并且由后端自动补齐时间不要依赖前端传入的时间边界。同时所有时间字段在代码中统一使用同一时区避免本地开发环境与服务器时区不同导致的偏移。6. 进阶验证与资源选型从「能跑」到「敢用」6.1 正确性验证用一组测试数据对账系统开发完成后验证比功能开发更要紧。我的习惯是手工构造一组完整业务场景模拟一天的真实营业数据采购入库 3 次共 5 种商品、销售出库 10 单包含一单退货、盘点 1 次包含盘盈和盘亏各一种商品。然后在数据库里执行原生 SQL 做对账验证三组不等式的左右相等-- 库存对账期初 入库 - 出库 ± 盘点调整 期末 SELECT p.name, (SELECT initial.quantity FROM inventory_snapshot initial WHERE initial.product_id p.id AND initial.date 2025-01-15) COALESCE((SELECT SUM(quantity) FROM stock_in_item WHERE product_id p.id), 0) - COALESCE((SELECT SUM(quantity) FROM sale_order_item WHERE product_id p.id), 0) COALESCE((SELECT SUM(diff) FROM inventory_adjust_item WHERE product_id p.id), 0) AS calculated_qty FROM product p;这条 SQL 展示了进销存对账的核心思想每个商品的期末库存都能由「期初 所有入库单 - 所有销售出库 ± 盘点差异」推导出来推导结果与inventory表当前值不一致时系统内一定存在逻辑漏洞。把它作为项目的验收测试用例能有效地找出隐藏的事务问题和条件更新写错的场景。对账通过之后再验证报表的准确性销售总金额应等于所有sale_order_item.subtotal之和。这个等式的意义在于如果某次修改破坏了事务边界对账立刻就能发现「库存平了但总金额对不上」的情况。这套验证方法在项目交付时同样能打动验收方因为它不是展示界面而是证明系统在业务逻辑上是自洽的。6.2 能落地的优化缓存、批量、导出系统能用之后下一步优化是针对真实运营场景的。我用得最多的是两类优化第一类是在商品查询上做本地缓存因为收银台对同一件商品的查询频率非常高——扫码枪扫同一个条码一天能扫几百次。把商品价格和库存冗余进本地缓存可以减少数据库压力。常见的坑是缓存了库存数字导致超卖解决方案是价格类信息可以做缓存库存扣减永远走数据库的条件更新两者职责分离绝不缓存库存做扣减依据。第二类优化是批量入库。超市进货一车可能有几十上百个单品逐个调用入库接口会产生大量事务开销。常见做法是把入库接口设计成批量提交一次事务里插入所有主表和明细同时遍历扣库存。这一步需要注意事务时间不能过长超过 1 秒的单据要拆批处理否则数据库连接池容易被长事务占满。第三类是报表导出。店长需要一个「日销售明细」「库存预警表」的 Excel 导出功能。Excel 导出的实现并不复杂但要注意大数据量时的内存溢出。常见做法是使用流式写入而不是一次性把全部数据加载进内存对于中小超市的日数据量来说哪怕是十万行级别流式导出也能在两秒内完成完全满足日常运营需求。导出文件命名要带日期比如销售报表_20250115.xlsx这是用户的实际体验细节。最后分享一个习惯每次提交代码前我会花十分钟在数据库里跑一遍对账 SQL。进销存系统的可怕之处在于一个看似无害的改动——比如把某个查询从FOR UPDATE改成不加锁——可能在三天后才会通过库存差异暴露出来而那时要定位是哪一天的哪一笔操作引发的成本就非常高了。功夫花在验证上比花在排错上划算得多。希望这篇笔记能帮你在做超市进销存管理系统时少走这几段弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/20 5:53:24 · 阅读 1.2k 超市进销存管理系统设计：从用例图到数据库与代码落地
简介这是一套面向超市运营场景的进销存管理系统提供商品进货、销售管理、库存统计、订单管理等功能模块适合超市管理人员、信息系统相关专业学生及开发者参考使用用以掌握业务流程数字化实现方式。压缩包共103个文件涵盖C#源程序、ASP.NET页面、数据库文件、CSS样式表及用例图等图片素材其中源程序对应各业务逻辑页面文件支持前端交互数据库文件保存核心业务数据整体大小仅2.03MB便于快速下载与部署。目前已有4379人学习下载常用于课程设计或毕业设计环节。资源附带的用例图清晰展示了员工、顾客、供应商与系统间的交互关系配合可运行的源码和数据库可帮助使用者理解进销存系统的设计思路了解商品进货、销售开单、库存预警、订单查询等典型流程并在此基础上进行功能扩展或撰写设计文档。1. 超市进销存管理系统到底在解决什么从理货单到用例图的距离做超市进销存管理系统的人通常带着一个很具体的诉求而来把进货、卖货、退换货、库存盘点这些每天都在发生、但一直靠纸笔和记忆运转的事情变成一套能查账、能对账、能知道哪个商品压了多少货的系统。这个标题里真正容易被低估的是「附用例图」四个字。很多人把用例图当作项目文档里的装饰画完就丢实际上用例图才是这套系统能不能少返工的关键——参与者、功能边界、角色权限在图上掰扯清楚后面写代码、设计表结构都是照着图走不需要反复推翻。这篇笔记的目标读者也很明确要么是正在做课程设计或毕设的学生要么是接了小超市管理系统外包、想快速交付的开发者。我按一套常见做法把需求分析、用例图、数据库设计、核心业务代码和踩坑记录拆开讲你照着做能在一个周末把系统从图跑到能演示、能验收。2. 用例图先于代码把参与者、用例与关系画到能落地2.1 参与者和用例识别别把按钮当功能画用例图的第一步不是打开绘图工具而是先做参与者识别。我见过不少人把用例图画成了功能菜单树——「商品管理」「供应商管理」「系统设置」各画一个大框然后往里面塞几十个小用例画完自己都说不清每个用例的价值。正确的做法是先问这个系统里有哪几类人他们各自要完成什么业务目标。超市进销存最常见的参与者有三类收银员、采购员、店长通常兼任系统管理员。收银员的目标是完成销售、处理退货采购员的目标是根据缺货情况生成采购单、对入库单做验收确认店长要的是看库存、看毛利、做盘点、管员工账号。这里有一个很实用的判断标准参与者是「人」用例是「目标」而诸如「登录」「修改密码」这类支撑性功能通常是系统的公共能力可以单独抽出来不要混在业务用例里。在实际练习里我一般会让 A 同学先在白纸上列出 8 到 10 个候选用例然后逐个问一句这个用例完成之后参与者得到了什么业务结果如果答案是「只是系统里多了一条数据业务上没有变化」那这个用例大概率是功能操作不是业务用例。比如「新增商品」就不算独立用例它只是「维护商品档案」这个目标下的子功能「录入采购入库单」才算因为它对应了「货物实际到店并验收入库」这个业务事件。这个区分直接决定了用例图的信息密度——好的用例图一张能讲清楚坏的一张图有两百个节点。用例清单可以先用表格列出来方便后面核对数据库设计和开发任务参与者核心用例业务结果收银员销售出库、退货处理、当日交班库存扣减、收款记录、销售报表数据采购员采购入库、采购退货、供应商查询库存增加、应付账款变动店长库存盘点、调价、报表查看、员工账号维护账实一致、价格更新、经营决策数据系统公共登录、权限校验、操作日志安全边界与可追溯2.2 用 PlantUML 出图用例图代码与 include / extend 的取舍工具层面常见做法是画用例图用 PlantUML因为它用纯文本描述图结构放进项目仓库里好维护改起来也比拖拽工具快。业务方要看得懂也可以用 draw.io 导成图片。PlantUML 代码并不复杂核心就是三样东西参与者、用例、关系。下面这份是我常用的超市进销存用例图 PlantUML 代码你可以直接复制保存为usecase.pumlstartuml left to right direction actor 收银员 as Cashier actor 采购员 as Purchaser actor 店长 as Manager rectangle 超市进销存管理系统 { usecase 登录 as Login usecase 销售出库 as Sale usecase 退货处理 as Refund usecase 采购入库 as StockIn usecase 采购退货 as StockOut usecase 库存盘点 as Count usecase 商品档案维护 as Product usecase 报表查看 as Report usecase 员工账号维护 as Account Login . Cashier Login . Purchaser Login . Manager Cashier -- Sale Cashier -- Refund Purchaser -- StockIn Purchaser -- StockOut Manager -- Count Manager -- Product Manager -- Report Manager -- Account StockIn . Login : include StockOut . Login : include Sale . Login : include Count . Login : include } enduml这段代码里需要注意两个点。第一所有业务用例都用include指向「登录」意思是执行这些用例之前必须完成身份验证这是 include 关系的典型用法——被包含的用例是公共步骤不是独立业务目标。第二不要滥用extend。extend 表示「在特定条件下才附加执行」的可选行为比如「销售出库」在遇到顾客退货时可以 extend 到「退货处理」但它不是每次收银都触发。如果在图里把所有关联都画成 extend业务方会误以为那些是必选流程需求和实现的偏差就是这么产生的。产出这张图之后用例图还可以直接作为模块开发清单使用。比如 StoreManager 角色对应的 Count、Product、Report、Account 四个用例开发时就可以拆成四个后端模块。图和代码的映射关系越清晰越不容易出现做完销售模块才发现库存表没设计的尴尬。在提交项目文档的时候这份.puml源码比一张截图更有说服力因为它能反推出你当时对边界的思考而截图只能看出最终结果。2.3 用例图与数据权限的映射从图到模块清单用例图不是画完就完了它要能直接指导后面的数据库权限设计。超市进销存系统里最常见的权限问题是收银员误操作进了后台改了商品价格或者采购员看到了营业毛利——这些在用例图上其实已经暴露了只是很多人没注意。回看上一节中的用例图收银员只连到「销售出库」和「退货处理」所以数据库层面他可以读写销售单、退货单、查询商品基础信息采购员连到「采购入库」和「采购退货」所以他只对采购类单据有增删改权限店长对所有用例可见自然拥有全部表的读写权限。在实现时常见做法是做一个简单的 RBAC角色-权限模型用户表挂角色角色挂权限点权限点对应到后端接口的路径或方法名。比如product:edit这个权限点只分配给店长角色收银员登录后即使猜到接口地址后端也会在拦截器里直接拒绝。这个映射关系要在用例图阶段就定下来不然等接口写完再补权限改动成本会高很多因为那时候前端路由、后端接口、按钮显隐都已经耦合在一起了。另一个实用的映射技巧是用例图到菜单树Manager 看到的菜单包含「盘点」「报表」「账号管理」而 Cashier 只有「收银台」「退货」两个菜单入口。前端路由表按角色动态生成后端接口按权限点做拦截双端配合才能保证不出现「前端隐藏了按钮、后端接口照样能调用」的安全漏洞。很多进销存项目翻车并不是功能做不出来而是这个边界没在用例图阶段划清楚导致后期反复打补丁。3. 数据库设计先行五张核心表的字段与边界参数3.1 商品与库存表价格精度、库存数量用什么类型用例图定了功能边界接下来就是数据库设计。超市进销存系统的核心不是业务逻辑多复杂而是字段类型选错导致账目对不上这在项目中非常常见。先说商品表和库存表。商品表的核心字段包括商品编码、条码、名称、规格、进价、售价、供应商ID、分类、状态。这里最容易犯的错有两个。第一个是把价格字段设计成FLOAT或DOUBLE。浮点数在计算机里是近似存储0.1 0.2 在二进制里算出来不是 0.3连续记几笔账之后库存金额、毛利这些汇总数据就会漂移对账的时候差几分钱查得人想摔键盘。正确做法是全部用DECIMAL(10,2)金额类字段固定两位小数由数据库而不是应用层保证精度。第二个常见错误是库存数量用无符号整型这会导致一旦业务上出现盘亏或者退货冲销时库存暂时变负SQL 直接报错。库存应该用有符号的INT数量在应用层做非负校验这样既允许中间态出现又能通过逻辑锁避免真正的负数库存落库。商品表的设计我一般会给出这样一份建表 SQLCREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, product_code VARCHAR(32) NOT NULL UNIQUE COMMENT 商品编码内部使用, barcode VARCHAR(32) DEFAULT NULL COMMENT 条码扫码枪输入, name VARCHAR(64) NOT NULL COMMENT 商品名称, spec VARCHAR(64) DEFAULT NULL COMMENT 规格如 500ml/瓶, purchase_price DECIMAL(10,2) NOT NULL COMMENT 进货价, sale_price DECIMAL(10,2) NOT NULL COMMENT 零售价, supplier_id BIGINT NOT NULL COMMENT 默认供应商ID, category VARCHAR(32) DEFAULT NULL COMMENT 分类, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_supplier (supplier_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品档案表;参数说明里有三个地方值得关注。product_code用于系统内部关联应当包含分类信息比如FOOD0001方便按前缀筛选barcode可以为空因为不是所有商品都有条码但一旦扫码枪扫到重复条码应用层要做合并或提示处理状态字段用TINYINT而不是字符串是为了索引效率查询上架商品只需WHERE status 1。库存表建议单独建不要和商品表混在一张表里因为盘点时要锁库存行把读写频繁的库存字段独立出来能减少锁竞争CREATE TABLE inventory ( id BIGINT AUTO_INCREMENT PRIMARY KEY, product_id BIGINT NOT NULL UNIQUE COMMENT 商品ID, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存数量允许为负的中间态, safety_stock INT NOT NULL DEFAULT 0 COMMENT 安全库存低于此值提示补货, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_quantity (quantity) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存表;这里的UNIQUE约束很重要——它确保一个商品只有一行库存记录并发更新时不会产生多行脏数据。safety_stock字段是给采购员的补货提醒用的低于阈值时报表页标红。很多项目把安全库存逻辑写在代码里但代码改起来比改字段麻烦而且多个模块要重复判断放在表里更利于一致性。3.2 单据表与明细表为什么主从表结构能保账实一致进销存系统里最难设计也最容易翻车的是单据类表。无论是采购入库单还是销售出库单都要遵循「主表 明细表」的主从结构。主表记录这次业务事件本身的信息比如单据号、操作人、总金额、时间明细表记录这个单据下每一件商品的详情比如商品ID、数量、当时的单价、小计金额。这样设计的原因很直接一张销售单可能包含十几种商品如果把商品明细直接拼在主表的一个字段里后续对账、退货、按商品维度统计全都做不了。主从表还能保持历史快照——明细表里的单价记录的是「成交那一刻的价格」即便后来商品调价了这张单子的金额也不受影响。这是进销存系统账实一致的根基。销售出库主表和明细表的建表 SQL 如下CREATE TABLE sale_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 销售单号格式如 S202501010001, cashier_id BIGINT NOT NULL COMMENT 收银员用户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 应收总额, status TINYINT NOT NULL DEFAULT 0 COMMENT 0进行中 1已完成 2已作废, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_cashier_time (cashier_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT销售主表; CREATE TABLE sale_order_item ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT 主表ID, product_id BIGINT NOT NULL, quantity INT NOT NULL COMMENT 销售数量, unit_price DECIMAL(10,2) NOT NULL COMMENT 成交单价快照字段, subtotal DECIMAL(10,2) NOT NULL COMMENT 小计金额, KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT销售明细表;注意sale_order_item里没有单独设置order_no冗余字段这是有意的设计。查询某一单的明细时通过order_id关联主表即可避免冗余存储导致的数据不一致。但在超市场景里还有一种查询很常见顾客拿小票来退货小票上只有order_no而没有内部 ID。实际项目里这种情况怎么办我一般会在主表的order_no上建立唯一索引因为它是业务自然键退货时先按order_no查主表拿到id再按id查明细。这样做索引占用很小且语义清晰。主从表还有一个细节是状态管理。主表的status字段必须支持「作废」状态而不是直接删除记录原因在于财务审计要求操作留痕。一旦删除了作废单据库存流水就会出现空洞月末对账时无法解释某次扣减是从哪来的。作废单在报表里可以显示为灰色并计入异常单统计但数据必须保留。这和后面要讲的盘点逻辑是联动的。3.3 初始化数据与演示账号让系统三天内能跑起来数据库设计完成后紧接着要做的是初始化数据而不是急着写业务代码。进销存系统项目里最煞风景的演示场景就是从商品档案到供应商信息全空收银员登录后连一个商品都扫不出来。所以我在设计阶段就会顺手准备一套 seed 数据脚本至少包含 20 个典型的超市商品覆盖饮料、零食、日化、生鲜四个大类每个商品的进价、售价、库存量、安全库存都要合理——比如一瓶矿泉水的进价不能比售价还高库存量不能全是负数否则演示时被现场问一句「这个数据怎么看着不合理」就尴尬了。初始化脚本里还应包含三组演示账号收银员、采购员、店长各一个密码用 MD5 或 BCrypt 加密存储。常见的坑是直接用明文密码初始化的测试没问题但交付的时候一旦用户忘记改密码整个系统的权限边界就形同虚设。账号初始化脚本的写法如下INSERT INTO sys_user (username, password, role, nickname) VALUES (cashier01, e10adc3949ba59abbe56e057f20f883e, CASHIER, 收银员小张), (buyer01, 25f9e794323b453885f5181f1b624d0b, BUYER, 采购员小李), (manager01, e10adc3949ba59abbe56e057f20f883e, MANAGER, 店长老王);这段 SQL 里e10adc3949ba59abbe56e057f20f883e对应123456的 MD5这在项目里只是演示用途正式环境必须升级为 BCrypt 并加盐。角色字段用字符串是为了可读性但实际查询时推荐建一个sys_role表来管理因为后续大概率要扩展权限点硬编码字符串会越写越乱。初始化数据做完之后整个系统已经有一个可以演示的骨架后端的业务代码只需要在这个骨架上填充接口节奏会快很多。4. 核心业务落地入库、出库、盘点的最小可运行实现4.1 入库接口事务、锁与单据号生成数据库表结构就绪后进入业务代码实现阶段。进销存系统真正的复杂度不在增删改查而在「多个表要同时变化」的事务一致性和「并发时不能超卖」的锁控制。先看入库流程采购员在界面上选择商品、填数量、提交后端要做的事包括生成采购入库单号、插入主表记录、插入明细表记录、累加库存、写入库存流水。这四步任意一步失败整单都不能生效。常见做法是使用 Spring Boot 的事务注解标记入库方法。一个典型的最小实现如下Transactional(rollbackFor Exception.class) public Long createStockIn(StockInRequest request) { // 1. 生成单据号格式RK 日期 3位随机数如 RK20250115001 String orderNo generateOrderNo(RK); // 2. 写主表 StockInOrder order new StockInOrder(); order.setOrderNo(orderNo); order.setSupplierId(request.getSupplierId()); order.setOperatorId(request.getOperatorId()); order.setStatus(0); stockInOrderMapper.insert(order); // 3. 写明细表 累加库存 for (StockInItem item : request.getItems()) { StockInOrderItem detail new StockInOrderItem(); detail.setOrderId(order.getId()); detail.setProductId(item.getProductId()); detail.setQuantity(item.getQuantity()); detail.setPurchasePrice(item.getPurchasePrice()); stockInOrderItemMapper.insert(detail); inventoryMapper.increaseQuantity(item.getProductId(), item.getQuantity()); } return order.getId(); }逻辑说明Transactional保证了主表、明细表、库存更新要么全部成功要么全部回滚不会出现「主表写入了明细丢失」的中间状态。单据号生成放在事务开头如果事务回滚了单据号也就丢弃了这在超市场景下是可接受的因为每天的入库单量级不大不需要严谨的号段不重不漏。参数方面increaseQuantity对应如下 SQLUPDATE inventory SET quantity quantity #{delta}, update_time NOW() WHERE product_id #{productId}这里使用了数据库的行级自增而不是先在代码里查询再在代码里加目的是避免并发场景下的脏写两条入库请求同时读到一个旧库存值各自加完再写回后写的那次会覆盖先写的那次导致库存少加。直接SET quantity quantity delta由数据库的锁机制保证原子性无论并发多少条都能累加正确。这是进销存系统里最基础也最重要的一个写法。4.2 出库扣库存避免超卖的两种写法出库扣库存是进销存系统里最容易出现翻车事故的地方。想象一个场景店里只剩 3 瓶可乐两个收银员几乎同时按下收款键系统库存却是先查后减的写法——两个请求都读到 3各自减 1 后写回 2实际卖出去 2 瓶库存显示 2账实对不上。多卖几单后库存就飘了。避免超卖有两种常见写法我先说明第一种也是推荐优先使用的条件更新。在减库存的 SQL 里带上quantity delta的条件作为乐观锁约束UPDATE inventory SET quantity quantity - #{delta}, update_time NOW() WHERE product_id #{productId} AND quantity #{delta}这段 SQL 的执行结果是如果库存不足受影响行数为 0应用层通过判断返回值决定是抛异常提示「库存不足」还是进入「允许负库存」的备选流程。数据库的行锁保证了同一时间只有一个请求能成功扣减不会有任何并发请求读到旧值。这是一个很干净的做法不需要额外引入分布式锁或 Redis 预扣库存对于中小超市的数据量完全够用。第二种写法是在应用层使用 Redis 的原子减操作做预扣库存余量放一份到 Redis先扣 Redis 再扣数据库扣减成功后再异步同步数据库。这种做法的优势是抗高并发峰值适合双十一那种级别的流量。但超市收银场景的并发远到不了这个量级引入 Redis 反而增加了缓存与数据库双写一致性这个额外的维护成本——一旦 Redis 和数据库不同步对账就是一场灾难。所以我通常的建议是单体应用 条件更新的 SQL完全能覆盖收银台的并发需求不要为了架构好看而引入不必要的复杂度。出库扣库存的整个流程还必须和销售单的创建在同一个事务里。很多项目拆成「先创建订单下单后再减库存」两个操作之间一旦出现异常就会出现有单无货或者有货无单的脏数据。正确做法是创建sale_order、sale_order_item、扣减库存三个操作放在同一个事务方法里任一步失败全部回滚保证系统的每个状态都对应一个完整的业务事件。4.3 盘点差异调整盘盈盘亏怎么入账盘点这一块是小超市系统里经常被做砸的功能。很多人把盘点做成「直接改库存数量」对着数据库把数字改成实际数就完事结果库存是修正了但钱的账是乱的——因为盘亏的库存对应的是真金白银的损失必须留下可追溯的记录。正确做法是为盘点单独设计流程而不是直接改库存。一个最小可行的盘点流程包含三个动作创建盘点单 → 录入实盘数量 → 生成差异调整单并更新库存。在创建盘点单时系统先冻结当前库存快照录入实盘数量后系统自动计算差异实盘数减账面数正数为盘盈、负数为盘亏提交后生成一张inventory_adjust调整单把差异落进库存流水同时更新库存表。盘亏调整的核心 SQL 和入库类似但要注意方向-- 盘盈库存加 UPDATE inventory SET quantity quantity #{diff} WHERE product_id #{productId}; -- 盘亏库存减但用条件更新防止把库存扣成负的 UPDATE inventory SET quantity quantity - #{absDiff} WHERE product_id #{productId} AND quantity #{absDiff};这里有个参数细节值得说明盘亏扣减时如果quantity不够减比如之前已经欠库存了条件更新会返回 0 行此时不应该强扣而应该让盘点单进入「审核中」状态由店长确认是否接受负库存。这是很多课程设计里被忽略的业务边界。盘点差异完全不应该静默写入库存每一笔差异都要关联到对应的调整单号这样月末对账时每一笔库存变化都能追到源头——是销售单、入库单、退货单还是盘点调整单。5. 进销存系统避坑实录5 个让项目翻车的细节5.1 现象销售单创建成功了库存却没扣这是高发问题。代码里创建订单和扣减库存分别写在两个 Service 方法里先调了saleService.createOrder()又调inventoryService.deduct()两个方法各自带事务。当扣库存抛异常回滚时订单事务已经提交了库存就成了「只卖不扣」。原因分析事务边界没有收敛。跨 Service 调用时因为默认的传播机制是「有事务就加入」理论上应该复用同一个事务但有些项目里Transactional加在私有方法上不生效或者两个方法不在同一个代理对象上导致事务实际变成两个独立提交。解决办法把创建订单和扣库存合并到同一个事务方法中并且确认Transactional加在公开方法上。更稳妥的验证手段是在测试里写一个 mock 库存不足的用例断言sale_order表中不会残留记录。这个用例应该写进项目的基础测试集里每次改动都跑一遍防止回归。5.2 现象商品价格用FLOAT之后报表小数位离奇跳变某个晚上盘点时发现售价 9.9 的商品进价成本是 6.6账面上算出来的毛利率却带着一堆不规律的小数尾巴怎么对都对不上。原因非常简单FLOAT是浮点存储6.6在二进制里是无限循环小数存储时被截断多次运算后误差累积。很多人对「数据库字段类型无所谓」这个认知有误区进销存对精度敏感这类系统里所有金额和单价都必须是DECIMAL。解决办法全局搜索建表语句把FLOAT/DOUBLE一律换成DECIMAL(10,2)对已经是FLOAT的存量数据先写一次修正脚本来重算金额字段。这里还有一个额外提醒不仅数据库要用定点数Java 端也要用BigDecimal避免从数据库取出后转double再运算。代码里一行float total ...就足以让前面所有数据库层面的努力白费。5.3 现象用例图里画了「include 登录」实现时每个接口都要做权限判断代码重复到吐有人照着用例图画出去了实现时发现「登录」这个 include 关系真的在每个业务接口里都写了一遍重复的鉴权逻辑。原因是对 include 关系的理解太机械了。在用例图中表示「所有业务用例包含登录」到了代码层面应该是抽象出一个过滤器或拦截器而不是把相同的代码复制到每个 Controller 的方法里。解决办法用 Spring MVC 的HandlerInterceptor或 Servlet Filter在进入 Controller 之前统一做 token 校验和角色判断业务方法只负责自己的业务逻辑。这样才真正还原了 include 关系的语义——它是一个横切关注点不是业务代码的一部分。类似的还有操作日志用例图里每个用例都可能记录日志但代码里应该用 AOP 统一处理而不是在每个方法里手写。5.4 现象盘点流程能快速改库存但审计时谁也说不清那批盘亏去哪了这是初学者最容易犯的业务设计错误。把盘点和调库存做成一个接口点了「提交」库存直接变化没有调整单、没有审核、没有库存流水。月底对账发现毛利异常却找不到是哪一笔导致的。原因分析把「业务结果」和「数据写入」混为一谈。盘点这个业务事件真正关心的是「账实差异是否被合理记录和批准」而不只是「库存数字变了」。直接改库存的方法跳过了记录环节等于档案馆里偷换了一页纸内容变了但没有备份。解决办法严格按照「盘点单 → 实盘录入 → 差异调整单 → 审批 → 更新库存」五步走。数据库表结构上要有一张inventory_adjust主表加inventory_adjust_item明细表调整单的状态顺序是「草稿 → 待审核 → 已审核 → 已生效」。在盘点单尚未审核通过之前库存字段不能被修改。每一笔差异都有单据号可查整个链路才算闭环。5.5 现象前端传了字符串日期后端按时间戳存报表按天汇总时丢了数据某个项目里销售单日期在创建时报的是2025-01-15 23:59:59到了次日凌晨刚过 0 点又来了一单此时第一单已经「过了一天」当天的销售汇总就缺了前一日的最后一笔订单。这类问题排查起来特别耗时因为数据存在单子也在但统计口径不对。原因分析数据库的DATETIME存储带时间按天分组要精确处理日期边界。如果前端传的是2025-01-15这种纯日期后端在处理查询条件时默认拼了一个00:00:00而2025-01-15 23:59:59的记录就会被「今天没这一单」筛掉。解决办法查询条件统一用半开区间例如查询某一天使用 2025-01-15 00:00:00 AND 2025-01-16 00:00:00并且由后端自动补齐时间不要依赖前端传入的时间边界。同时所有时间字段在代码中统一使用同一时区避免本地开发环境与服务器时区不同导致的偏移。6. 进阶验证与资源选型从「能跑」到「敢用」6.1 正确性验证用一组测试数据对账系统开发完成后验证比功能开发更要紧。我的习惯是手工构造一组完整业务场景模拟一天的真实营业数据采购入库 3 次共 5 种商品、销售出库 10 单包含一单退货、盘点 1 次包含盘盈和盘亏各一种商品。然后在数据库里执行原生 SQL 做对账验证三组不等式的左右相等-- 库存对账期初 入库 - 出库 ± 盘点调整 期末 SELECT p.name, (SELECT initial.quantity FROM inventory_snapshot initial WHERE initial.product_id p.id AND initial.date 2025-01-15) COALESCE((SELECT SUM(quantity) FROM stock_in_item WHERE product_id p.id), 0) - COALESCE((SELECT SUM(quantity) FROM sale_order_item WHERE product_id p.id), 0) COALESCE((SELECT SUM(diff) FROM inventory_adjust_item WHERE product_id p.id), 0) AS calculated_qty FROM product p;这条 SQL 展示了进销存对账的核心思想每个商品的期末库存都能由「期初 所有入库单 - 所有销售出库 ± 盘点差异」推导出来推导结果与inventory表当前值不一致时系统内一定存在逻辑漏洞。把它作为项目的验收测试用例能有效地找出隐藏的事务问题和条件更新写错的场景。对账通过之后再验证报表的准确性销售总金额应等于所有sale_order_item.subtotal之和。这个等式的意义在于如果某次修改破坏了事务边界对账立刻就能发现「库存平了但总金额对不上」的情况。这套验证方法在项目交付时同样能打动验收方因为它不是展示界面而是证明系统在业务逻辑上是自洽的。6.2 能落地的优化缓存、批量、导出系统能用之后下一步优化是针对真实运营场景的。我用得最多的是两类优化第一类是在商品查询上做本地缓存因为收银台对同一件商品的查询频率非常高——扫码枪扫同一个条码一天能扫几百次。把商品价格和库存冗余进本地缓存可以减少数据库压力。常见的坑是缓存了库存数字导致超卖解决方案是价格类信息可以做缓存库存扣减永远走数据库的条件更新两者职责分离绝不缓存库存做扣减依据。第二类优化是批量入库。超市进货一车可能有几十上百个单品逐个调用入库接口会产生大量事务开销。常见做法是把入库接口设计成批量提交一次事务里插入所有主表和明细同时遍历扣库存。这一步需要注意事务时间不能过长超过 1 秒的单据要拆批处理否则数据库连接池容易被长事务占满。第三类是报表导出。店长需要一个「日销售明细」「库存预警表」的 Excel 导出功能。Excel 导出的实现并不复杂但要注意大数据量时的内存溢出。常见做法是使用流式写入而不是一次性把全部数据加载进内存对于中小超市的日数据量来说哪怕是十万行级别流式导出也能在两秒内完成完全满足日常运营需求。导出文件命名要带日期比如销售报表_20250115.xlsx这是用户的实际体验细节。最后分享一个习惯每次提交代码前我会花十分钟在数据库里跑一遍对账 SQL。进销存系统的可怕之处在于一个看似无害的改动——比如把某个查询从FOR UPDATE改成不加锁——可能在三天后才会通过库存差异暴露出来而那时要定位是哪一天的哪一笔操作引发的成本就非常高了。功夫花在验证上比花在排错上划算得多。希望这篇笔记能帮你在做超市进销存管理系统时少走这几段弯路。本文还有配套的精品资源点击获取