简介这是一套面向计算机专业学生与Java Web开发初学者的仓库管理系统毕业设计完整资料基于B/S架构采用JavaEE、MyBatis与Oracle技术栈实现覆盖入库、出库、商品查看、用户注册及个人信息管理等核心业务模块适合作为课程设计、毕业设计参考或Web项目练手素材。资源包共12个文件约60.02MB包含png项目截图、txt说明文档、mp4项目辅导视频、pptx答辩演示、doc任务书、docx论文、sql数据库脚本及zip源码压缩包从需求分析到部署运行形成完整闭环。其中视频演示了数据库创建、项目启动及各功能模块操作流程论文与任务书可直接作为写作模板源码与SQL脚本便于二次开发与调试。目前已有54人学习下载适合需要快速搭建可运行Web项目、理解MyBatis与Oracle整合开发及准备答辩材料的读者参考使用。1. 从一张 Excel 台账说起为什么仓库管理系统的核心不是增删改查很多团队做仓库管理系统的起点是一张被反复另存的 Excel 台账。入库加一行出库减一行月底对不上就翻聊天记录。表面看是工具问题实际是三个约束没被系统化库存数量必须可追溯、同一物料不能超卖、操作记录要能定位到人和时间。基于 WEB 的仓库管理系统要解决的正是这三件事而不是把表格搬到浏览器里。它适合两类人一类是中小团队里被库存对账折磨的开发者需要一套能自己部署、自己改字段的轻量系统另一类是要把仓库模块嵌进现有业务系统的工程师关心的是数据模型和并发扣减怎么做。本文按「先立数据模型再跑通最小闭环最后处理并发和权限」的顺序展开代码用 Python Flask SQLite 演示换成其他语言和数据库思路一致。库存扣减的并发问题是这类系统里最容易翻车的地方后面会单独拆。2. 数据模型先立住物料、库存、流水三张表怎么分2.1 为什么不能只用一张库存表新手最常见的做法是一张stock表字段是物料名、数量、更新时间。入库就UPDATE stock SET qty qty 10出库就减。这个模型在单人在线时没问题一旦要回答「这批货是谁在什么时候入的」「上个月盘点差异出在哪」就彻底抓瞎因为历史被覆盖了。正确的拆法是三张表物料表material存静态属性库存表inventory存当前结存流水表stock_record存每一次变动。库存表是流水表按物料聚合的结果可以随时用流水重算。这样设计的好处是任何时刻的库存都能被解释盘点差异能顺着流水倒查。表名作用关键字段material物料主数据id, code, name, unit, specinventory当前结存material_id, qty, warehouse_idstock_record出入库流水material_id, change_qty, type, operator, created_at物料编码code要加唯一索引因为实际业务里同名物料很常见靠名称去重一定会出问题。inventory表用material_id warehouse_id做联合唯一约束支持多仓库场景。2.2 建表 SQL 与索引设计-- 物料主数据表 CREATE TABLE material ( id INTEGER PRIMARY KEY AUTOINCREMENT, code VARCHAR(64) NOT NULL UNIQUE, -- 物料编码业务唯一键 name VARCHAR(128) NOT NULL, unit VARCHAR(16) DEFAULT 件, spec VARCHAR(128), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 库存结存表按物料仓库维度唯一 CREATE TABLE inventory ( id INTEGER PRIMARY KEY AUTOINCREMENT, material_id INTEGER NOT NULL, warehouse_id INTEGER NOT NULL DEFAULT 1, qty INTEGER NOT NULL DEFAULT 0, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE (material_id, warehouse_id) ); -- 出入库流水表只增不改 CREATE TABLE stock_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, material_id INTEGER NOT NULL, change_qty INTEGER NOT NULL, -- 入库为正出库为负 type VARCHAR(16) NOT NULL, -- in / out / adjust operator VARCHAR(64) NOT NULL, remark VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 流水查询按物料和时间走建联合索引 CREATE INDEX idx_record_material_time ON stock_record (material_id, created_at);逻辑说明stock_record.change_qty用正负号区分出入库而不是用两个字段这样聚合时直接SUM(change_qty)就是净变动省掉分支判断。inventory上的联合唯一约束是并发安全的基础后面扣减时会用到。索引建在(material_id, created_at)上是因为最高频的查询是「某物料最近的流水」这个组合能直接命中。参数说明qty用 INTEGER 而非 FLOAT库存场景下小数计量比如按公斤建议统一换算成最小单位存整数避免浮点误差累积。warehouse_id给了默认值 1单仓库场景可以先不建仓库表需要时再扩展。3. 用 Flask 跑通入库出库最小闭环3.1 项目结构与依赖最小可运行的结构不需要复杂分层四个文件足够app.py放路由db.py管连接service.py放业务逻辑schema.sql是上面的建表语句。依赖只有 Flask数据库用 Python 自带的 sqlite3不引入 ORM目的是让库存扣减的 SQL 完全可见。pip install flask# db.py连接管理注意开启外键和行级锁相关配置 import sqlite3 def get_conn(): conn sqlite3.connect(wms.db, timeout10) # timeout 避免锁等待直接报错 conn.row_factory sqlite3.Row conn.execute(PRAGMA foreign_keys ON) return conntimeout10是关键参数。SQLite 默认在遇到写锁时立刻抛database is locked设成 10 秒会让它在锁释放前重试低并发下能挡掉大部分偶发报错。row_factory设成sqlite3.Row后查询结果能按列名取值比下标可读。3.2 入库与出库的核心逻辑# service.py出入库业务逻辑 from db import get_conn def stock_in(material_id, qty, operator, remark): 入库写流水 更新结存同一事务内完成 if qty 0: raise ValueError(入库数量必须为正) conn get_conn() try: with conn: # with 块自动提交或回滚 conn.execute( INSERT INTO stock_record (material_id, change_qty, type, operator, remark) VALUES (?, ?, ?, ?, ?), (material_id, qty, in, operator, remark) ) # UPSERT存在则加不存在则插入 conn.execute( INSERT INTO inventory (material_id, qty) VALUES (?, ?) ON CONFLICT(material_id, warehouse_id) DO UPDATE SET qty qty ?, updated_at CURRENT_TIMESTAMP, (material_id, qty, qty) ) finally: conn.close() def stock_out(material_id, qty, operator, remark): 出库先校验库存再扣减防止负库存 if qty 0: raise ValueError(出库数量必须为正) conn get_conn() try: with conn: row conn.execute( SELECT qty FROM inventory WHERE material_id ?, (material_id,) ).fetchone() if row is None or row[qty] qty: raise ValueError(库存不足当前可用%s % (row[qty] if row else 0)) conn.execute( INSERT INTO stock_record (material_id, change_qty, type, operator, remark) VALUES (?, ?, ?, ?, ?), (material_id, -qty, out, operator, remark) ) conn.execute( UPDATE inventory SET qty qty - ?, updated_at CURRENT_TIMESTAMP WHERE material_id ?, (qty, material_id) ) finally: conn.close()逻辑说明入库用ON CONFLICT ... DO UPDATE一条语句完成「有则加、无则插」避免先查后写的竞态。出库先SELECT校验再UPDATE在单连接串行下没问题但多线程下这个「查-改」之间可能被插入这就是后面要处理的超卖问题。with conn保证流水和结存要么都成功要么都回滚不会出现流水写了结存没更新的脏数据。参数说明change_qty出库时传负数和表设计一致。operator目前是字符串接入登录后应换成用户 ID 并加外键。remark建议在出库时强制填写用途方便后续追溯。3.3 用 curl 验证闭环# 启动服务后先建一个物料 curl -X POST http://127.0.0.1:5000/material \ -H Content-Type: application/json \ -d {code:M001,name:螺丝,unit:盒} # 入库 100 curl -X POST http://127.0.0.1:5000/stock/in \ -H Content-Type: application/json \ -d {material_id:1,qty:100,operator:A同学} # 出库 30 curl -X POST http://127.0.0.1:5000/stock/out \ -H Content-Type: application/json \ -d {material_id:1,qty:30,operator:A同学} # 查结存应为 70 curl http://127.0.0.1:5000/inventory/1跑完这三步结存应该是 70流水表里两条记录。如果出库时故意传 200应该收到「库存不足」的报错而不是负库存。这个最小闭环跑通后再往上加功能才有地基。4. 并发扣减与权限两个最容易翻车的地方4.1 超卖是怎么发生的怎么用事务隔离挡住上面stock_out的「先查后改」在并发下会超卖。两个请求同时读到库存 70各自判断 70 50 通过然后都执行扣减最终库存变成 -30。这不是玄学是典型的竞态条件。修法有两种。第一种是把校验和扣减合并成一条带条件的 UPDATEdef stock_out_safe(material_id, qty, operator, remark): 并发安全的出库用条件 UPDATE 的受影响行数判断是否成功 conn get_conn() try: with conn: cur conn.execute( UPDATE inventory SET qty qty - ?, updated_at CURRENT_TIMESTAMP WHERE material_id ? AND qty ?, (qty, material_id, qty) ) if cur.rowcount 0: # 没有行被更新说明库存不足 raise ValueError(库存不足或物料不存在) conn.execute( INSERT INTO stock_record (material_id, change_qty, type, operator, remark) VALUES (?, ?, ?, ?, ?), (material_id, -qty, out, operator, remark) ) finally: conn.close()逻辑说明WHERE qty ?把库存校验下推到数据库UPDATE 和判断在一条语句里原子完成。rowcount 0就说明条件不满足直接抛错。这样无论多少并发请求数据库层面保证不会扣成负数。参数说明这种写法依赖数据库的行锁SQLite 在写事务里会锁库MySQL 的 InnoDB 会锁行都成立。如果用的是最终一致性的分布式库存就得引入版本号或分布式锁复杂度上一个台阶中小系统不建议一上来就搞。4.2 权限别做成装饰要落到数据层很多系统的权限只做在菜单上隐藏了按钮但接口没拦直接调 API 照样能改。正确做法是在 service 层入口校验角色并且把「谁能操作哪个仓库」也纳入判断。角色可查看可入库可出库可改物料管理员全部是是是仓管员本仓库是是否只读本仓库否否否实现上用一个装饰器包住路由从 session 取角色和所属仓库和请求里的warehouse_id比对。别把角色判断散落在各个路由里集中一处改规则时只动一个地方。5. 避坑与排查五条血泪经验现象出库偶发报database is locked。原因SQLite 同一时刻只允许一个写事务多个请求同时写就排队超过 timeout 就报错。解决把timeout调大写操作尽量短别在事务里做网络请求或复杂计算并发再高就换 PostgreSQL 或 MySQL。现象库存和流水对不上结存比流水汇总多。原因早期代码先更新结存再写流水中间报错导致流水缺失。解决统一在同一个with conn事务里先写流水再更新结存任何一步失败整体回滚上线前用SELECT SUM(change_qty) FROM stock_record GROUP BY material_id和inventory.qty做一次全量对账。现象物料编码重复插入报错但用户看不懂。原因唯一约束触发的是数据库异常直接抛给前端。解决在 service 层先捕获IntegrityError转成「编码已存在」的业务提示别把 SQL 报错暴露出去。现象盘点调整后历史流水被改乱。原因有人图省事直接 UPDATE 流水表。解决流水表只增不改盘点差异用一条typeadjust的新流水表达正负都行历史永远可查。现象分页查询越翻越慢。原因用了LIMIT offset, sizeoffset 很大时数据库要扫描并丢弃前面所有行。解决改成基于游标的分页用WHERE id last_id ORDER BY id DESC LIMIT size配合主键索引翻到第几万页也不掉速。6. 进阶用流水重算库存做对账以及一个查询技巧系统跑一段时间后最该做的不是加功能而是验证数据自洽。写一个对账脚本把流水按物料聚合和结存表逐条比对差异超过阈值就告警。这个脚本我一般挂在定时任务里每天凌晨跑一次比事后人工翻账省太多事。# reconcile.py流水与结存对账 from db import get_conn def reconcile(): conn get_conn() # 流水汇总 flow {r[material_id]: r[total] for r in conn.execute( SELECT material_id, SUM(change_qty) AS total FROM stock_record GROUP BY material_id )} # 结存 stock {r[material_id]: r[qty] for r in conn.execute( SELECT material_id, qty FROM inventory )} diff [] for mid in set(flow) | set(stock): f, s flow.get(mid, 0), stock.get(mid, 0) if f ! s: diff.append((mid, f, s)) conn.close() return diff if __name__ __main__: for mid, f, s in reconcile(): print(物料 %s 流水汇总 %s结存 %s差异 %s % (mid, f, s, f - s))逻辑说明用两个字典分别装流水汇总和结存取并集遍历任何一边缺失都能发现。差异不为零就说明有事务没走完整或者有人绕过 service 直接改了表。这个脚本的价值在于把「数据对不对」从主观感觉变成可量化的检查。查询技巧上流水表数据量大之后按物料查最近记录要善用覆盖索引。如果只查material_id和created_at可以建(material_id, created_at)的联合索引让查询走索引不回表。另外别在流水表上做LIKE %关键词%的模糊搜索全表扫描在百万行级别会让页面卡死需要搜索就单独建检索表或用全文索引。我自己踩过最深的一个坑是早期为了「性能」把流水和结存合并成一张表结果三个月后盘点差异查不出来只能全量重建。从那以后我定了个习惯任何涉及数量变动的系统流水表永远独立、只增不改结存只是缓存。这个习惯帮我省下的排查时间远比多写一张表多花的功夫值。希望帮到你。本文还有配套的精品资源点击获取