简介基于JavaMySQL的Web企业仓库存储管理系统是一套面向高校课程设计或毕业设计的B/S架构完整项目。系统采用Spring BootJavaMavenMyBatis搭建覆盖客户、仓库、产品三类基本信息管理以及入库、出库记录和库存管理附带用户权限与系统日志功能适用于仓库管理场景的入门学习与二次开发。资源包共221个文件压缩后约6.95MB。其中42个Java源码文件构成业务逻辑主体28个HTML与JS/CSS文件为前端管理界面另含SQL数据库脚本、XML映射配置及1份说明文档75个GIF演示图可直观展示各模块操作流程辅助快速上手。资源已有568人学习浏览。完整的前后端代码、数据库初始化脚本与演示素材打包在一起目录层级清晰既能对照演示图理解业务流程也可直接导入IDEA运行调试是课程设计或仓库系统开发的有力参考。1. 企业仓库存储管理系统为什么 Java MySQL 的 Web 方案不过时仓库里堆着几百个 SKU每天十几张入库单、出库单来回传靠 Excel 台账硬撑两个人同时改一个单元格月底盘库对不上数几乎成了例行公事。基于 Java MySQL 实现 Web 企业仓库存储管理系统就是为了解决这个最朴素的问题把入库、出库、库存查询、盘点和流水追查全部搬到浏览器里谁在什么时间动了哪件货数据库里一查便知。这套技术组合看着传统却正是中小型仓库场景里稳定性最高、人才最好招、后续最好改的起步方案。对正在做课设或毕设的 Java 学习者来说这类系统覆盖了 Servlet、JDBC、事务、SQL 设计、部署上线几乎所有核心考点对想低成本上信息化的运维人员来说它不需要微服务不需要分布式一台普通服务器加一个 Tomcat 就能跑。下面按“数据模型先行、业务代码跟上、部署排障收尾”的节奏展开尽量把每步的坑都填平。2. 先立规矩仓库系统的表结构设计与 MySQL 建库脚本2.1 入出库的数据流为什么先写流水再改库存很多第一次做仓库系统的人会把库存当成唯一核心写一个goods表里面放一个qty字段入库就qty 1出库就qty - 1。系统刚上线时挺好用跑一个月就暴露问题了某天库存对不上你想查出是哪张单据导致的发现数据库里只有当前数量没有任何历史记录。想复盘只能靠出库单纸质底根去翻这等于把 Excel 台账又搬回数据库里。常见的可靠做法是拆成“两张表”一张stock只存当前数量一张stock_flow存每一笔业务流水。入库时先查当前库存写一条change_type1的流水再更新库存表的数量出库则写change_type2的流水同时把库存减掉。核心原则是先写流水、再改库存而且两个动作必须在同一个事务里完成否则会出现“流水有了但库存没变”或者反过来库存变了却没记录的对账缺口。盘点动作也走同一套逻辑只是change_type3数量按“盘点实存数量 - 账面数量”的差值入账。这样任何时候想查“某件商品从入库到现在一共进出多少”直接对stock_flow做聚合就行不需要去翻历史快照。这个设计虽然多一张表、多一步操作但它是整个系统能长期对得上账的地基。2.2 核心表结构设计用户表、商品表、库存表、流水表以最小可用系统为例四张表足够覆盖核心业务再按需扩展。第一张是sys_user用户表字段要包含用户名、密码、真实姓名和角色角色用TINYINT区分管理员和库管员比用字符串省空间也更好扩展。第二张是goods商品表核心字段是商品编码、名称、规格、单位和库存预警下限注意商品编码要加唯一约束因为实际业务里编码才是业务主键。第三张是stock库存表goods_id与商品表一对一用UNIQUE约束保证一个商品只有一行库存记录。这里有一个新手容易忽略的点库存表不要放冗余的商品名称字段查询时再去 JOIN 商品表否则商品改名后库存表里的历史名称会变成脏数据。第四张是stock_flow流水表字段包含唯一流水号、商品 ID、变动类型、变动数量、变动前数量、变动后数量、操作人 ID、备注和创建时间。下面是这四张表的字段设计对比照着建表前先想清楚每列的含义。表名关键字段约束说明sys_userusername, password, roleusername 唯一role 用 TINYINTgoodscode, name, spec, unit, min_stockcode 唯一min_stock 用于预警stockgoods_id, qty, update_timegoods_id 唯一且外键引用 goodsstock_flowflow_no, goods_id, change_type, qty, before_qty, after_qtyflow_no 唯一qty 一律存正数方向靠 change_type 区分两个容易踩的设计细节一是流水表的qty字段不要存负数入库出库都存正数用change_type表达方向否则以后做统计SUM(qty)时逻辑会绕二是必须存before_qty和after_qty两个快照值这是以后核对“那笔操作前后库存到底是多少”的后悔药没有这两个字段事务回滚后很难从流水反推现场。2.3 建库建表脚本utf8mb4 与 InnoDB 的取舍建库脚本直接决定后面排障的难易程度。字符集我一律用utf8mb4不是utf8这能兼容生僻字和特殊符号存储引擎用InnoDB因为要依赖它的事务能力MyISAM 在这个场景下没有任何优势。下面是一份可以直接执行的 MySQL 8 建库建表脚本。-- 建库字符集必须用 utf8mb4排序规则选 unicode_ci CREATE DATABASE IF NOT EXISTS depot_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE depot_db; CREATE TABLE sys_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, real_name VARCHAR(30), role TINYINT NOT NULL DEFAULT 2 COMMENT 1管理员 2库管员, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE goods ( id INT AUTO_INCREMENT PRIMARY KEY, code VARCHAR(30) NOT NULL UNIQUE COMMENT 商品编码业务唯一, name VARCHAR(100) NOT NULL, spec VARCHAR(100), unit VARCHAR(10) DEFAULT 件, min_stock INT NOT NULL DEFAULT 0 COMMENT 库存预警下限, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE stock ( id INT AUTO_INCREMENT PRIMARY KEY, goods_id INT NOT NULL UNIQUE, qty INT NOT NULL DEFAULT 0, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_stock_goods FOREIGN KEY (goods_id) REFERENCES goods(id) ) ENGINEInnoDB; CREATE TABLE stock_flow ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flow_no VARCHAR(32) NOT NULL UNIQUE, goods_id INT NOT NULL, change_type TINYINT NOT NULL COMMENT 1入库 2出库 3盘点, qty INT NOT NULL, before_qty INT NOT NULL, after_qty INT NOT NULL, operator_id INT NOT NULL, remark VARCHAR(200), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_flow_goods FOREIGN KEY (goods_id) REFERENCES goods(id) ) ENGINEInnoDB;这份脚本里有几个参数值得单独说明。NOT NULL用在所有业务关键字段上避免代码里因为NULL判断写出一堆分支UNIQUE用在username、code、flow_no三个业务唯一键上比在代码里先查再插更可靠外键约束在这个规模下开着没问题能防止删除商品时留下孤儿库存数据但如果以后分库分表外键就得去掉。数量字段全部用INT别用VARCHAR存数字MySQL 对字符串排序会按字典序排9会排在10后面。如果系统涉及金额记住DECIMAL(10,2)禁止用FLOAT。3. 用 Java JDBC 打通入库出库事务代码与参数细节3.1 Servlet JDBC 的选型理由课设与小型项目最稳的路径标题只写了 Java MySQL Web框架层面其实有很多选择Spring Boot MyBatis、Spring MVC JPA、Servlet JDBC。我一般会建议课程设计和快速落地的小型仓库系统优先考虑 Servlet JDBC 这条朴素路径原因不是它新而是它把 Java Web 的核心链路全部暴露出来请求怎么进 Servlet、SQL 怎么拼、事务怎么控制、连接怎么关。用 Spring Boot 虽然开发快但很多初学者调一个依赖冲突就要折腾一晚上反而不容易看清问题本质。JDBC 的部分很多人觉得低级其实它就是所有框架的地基。MyBatis 帮你生成的PreparedStatement、帮你管理的事务本质和手写 JDBC 是一样的逻辑只是封装了。如果你先把 JDBC 版本跑通再去看 MyBatis 源码很多“玄学”问题会一下想通。这一章就以 JDBC 为主把入库、出库两个最核心的 Service 方法完整走一遍。3.2 JdbcUtils 与连接池参数先把数据库连接管好写 JDBC 最容易翻车的位置就是连接管理拿到连接不关、ResultSet不释放跑半天后连接池被打满系统假死。常见做法是封装一个JdbcUtils工具类统一负责获取连接和关闭资源连接池用 Druid 或 HikariCP 都行。下面这段是完整可用的工具类骨架。public class JdbcUtils { private static DataSource dataSource; static { try (InputStream in JdbcUtils.class.getClassLoader() .getResourceAsStream(jdbc.properties)) { Properties props new Properties(); props.load(in); dataSource DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } public static void close(Connection conn, Statement stmt, ResultSet rs) { if (rs ! null) { try { rs.close(); } catch (SQLException ignored) {} } if (stmt ! null) { try { stmt.close(); } catch (SQLException ignored) {} } if (conn ! null) { try { conn.close(); } catch (SQLException ignored) {} } } }关键点有两个。一是静态代码块里初始化数据源类加载时只执行一次避免每个请求都去读配置文件。二是关闭顺序必须从里往外先关ResultSet再关Statement最后关Connection顺序反了会导致某些数据库驱动报错。连接池的jdbc.properties放到src/main/resources下驱动类名在 MySQL 8 里必须写com.mysql.cj.jdbc.Driver这是很多人从 5.x 升级后翻车的头号原因后面避坑章节还会专门讲。3.3 入库出库的事务代码先锁行再更新库存再写流水入库操作的业务逻辑不复杂但必须是一个原子操作。下面代码展示的是完整事务写法不用Transactional注解手写commit和rollback这样能清楚看到事务边界在哪里。public void inbound(StockFlowDTO dto) throws Exception { Connection conn null; PreparedStatement psLock null; PreparedStatement psUpdate null; PreparedStatement psFlow null; ResultSet rs null; try { conn JdbcUtils.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 锁定商品对应的库存行防止并发下算错库存 psLock conn.prepareStatement( SELECT id, qty FROM stock WHERE goods_id ? FOR UPDATE); psLock.setInt(1, dto.getGoodsId()); rs psLock.executeQuery(); int oldQty 0; int stockId 0; if (rs.next()) { stockId rs.getInt(id); oldQty rs.getInt(qty); } // 2. 更新库存表 int newQty oldQty dto.getQty(); psUpdate conn.prepareStatement( UPDATE stock SET qty ? WHERE id ?); psUpdate.setInt(1, newQty); psUpdate.setInt(2, stockId); psUpdate.executeUpdate(); // 3. 写流水表 psFlow conn.prepareStatement( INSERT INTO stock_flow (flow_no, goods_id, change_type, qty, before_qty, after_qty, operator_id, remark) VALUES (?, ?, ?, ?, ?, ?, ?, ?)); psFlow.setString(1, generateFlowNo()); // 全局唯一流水号 psFlow.setInt(2, dto.getGoodsId()); psFlow.setInt(3, 1); // 1代表入库 psFlow.setInt(4, dto.getQty()); psFlow.setInt(5, oldQty); psFlow.setInt(6, newQty); psFlow.setInt(7, dto.getOperatorId()); psFlow.setString(8, dto.getRemark()); psFlow.executeUpdate(); conn.commit(); } catch (Exception e) { if (conn ! null) conn.rollback(); throw e; } finally { if (conn ! null) conn.setAutoCommit(true); JdbcUtils.close(conn, psUpdate, rs); try { if (psFlow ! null) psFlow.close(); } catch (SQLException ignored) {} try { if (psLock ! null) psLock.close(); } catch (SQLException ignored) {} } }这段代码里最重要的不是UPDATE而是FOR UPDATE这一句。它把stock表的对应行锁住直到事务提交或回滚才释放这样两个用户同时对同一商品入库时第二个请求会等第一个提交后再读取不会出现“两个人都读到库存是 100分别加 10最后库存变成 110 而不是 120”的经典并发问题。加锁会牺牲一点性能但在仓库业务这种低频高正确的场景下非常值得。generateFlowNo()需要你自己实现我一般用yyyyMMddHHmmss 三位随机数或者直接用数据库主键替代。现实里更严谨的做法是独立一张流水号序列表用SELECT ... FOR UPDATE取号但这种小系统里时间戳加随机数已经够用。注意UPDATE stock之前一定要先SELECT ... FOR UPDATE拿到旧值否则before_qty和after_qty没数据可填流水就失去了快照意义。3.4 防止出库成负数条件更新是最后一道防线出库和入库的代码结构一样唯一不同的是更新语句必须带上qty ?条件这是防止库存扣成负数的最后一道防线。有些同学只在 Service 里先查一下数量判断够不够再执行更新这在并发场景下是挡不住的两个请求同时查出库存 10都判断够出 8然后一起执行更新最后库存变成 -6。// 出库把 WHERE qty ? 作为第二道保险 psUpdate conn.prepareStatement( UPDATE stock SET qty qty - ? WHERE id ? AND qty ?); psUpdate.setInt(1, dto.getQty()); psUpdate.setInt(2, stockId); psUpdate.setInt(3, dto.getQty()); int rows psUpdate.executeUpdate(); if (rows 0) { throw new BusinessException(库存不足出库失败); }executeUpdate()返回 0 表示没有匹配的更新也就是库存不足这时候直接抛异常让事务回滚流水也不会写进去。这里我再强调一次判断库存是否充足不能只靠SELECT要以UPDATE的影响行数为准数据库的条件更新才是最可靠的判断。这种“先乐观尝试、失败再回滚”的思路比先查再更新的 check-then-act 模式要结实得多。登录和权限部分不用展开讲太多做一个简单的Filter检查session里有没有用户对象没有就重定向到登录页有就放行。仓库系统不像电商平台需要复杂权限模型sys_user表里的role字段配合一套页面按钮的显隐控制基本就够用了。4. 部署上线JDK、MySQL 连通性与 Tomcat 运行参数4.1 环境准备JDK 环境变量、MySQL 安装配置与 Tomcat 版本对照代码写完只是第一步真正让系统跑起来还要过部署这一关。先从基础环境说起JDK 装好后JAVA_HOME环境变量指向 JDK 根目录PATH里加上%JAVA_HOME%\bin在命令行执行java -version能输出版本号才算配好。这里有个容易踩的细节如果系统里同时装了 JRE 和 JDKPATH里排在前面的那个会被优先执行导致javac命令找不到。MySQL 的安装建议用 msyql-installer 或各系统的包管理工具装完记得确认服务已启动。MySQL 8 默认的认证插件是caching_sha2_password老版本驱动不支持时还会额外踩坑后面避坑章节展开。Tomcat 版本要和 JDK 对应Tomcat 9 对应 JDK 8 及以上Tomcat 10 对应 JDK 11 及以上而且 Tomcat 10 把包名从javax.*改成了jakarta.*如果代码是按老规范写的直接用 Tomcat 10 会编译报错。我一般稳妥选择 Tomcat 9。4.2 jdbc.properties 的正确写法那些一眼看不懂的参数数据库连接配置是部署前最容易出错的地方下面是一份经过实测可用的 MySQL 8 配置每个参数我都标注了含义。driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/depot_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue usernameroot passwordyour_password initialSize5 maxActive20 maxWait10000serverTimezoneAsia/Shanghai是必须的MySQL 8 不设时区时会报一个标准的时区错误错误信息里全是一串乱码第五章细说。useSSLfalse是本地开发必备不然连接时会有一串证书告警甚至握手失败。allowPublicKeyRetrievaltrue解决的是某些 MySQL 8 版本下连接报Public Key Retrieval is not allowed的问题如果不用这个参数也可以把密码认证改成mysql_native_password。characterEncodingutf8保证中文写入数据库不乱码注意和建库时的utf8mb4不冲突一个管连接层一个管存储层。连接池的三个参数initialSize、maxActive、maxWait里maxWait是获取连接的最大等待毫秒数设太短高峰期会大量报获取连接超时设太长用户操作会卡死毫无反馈。仓库系统并发不高maxWait10000是常见取值真到了不够用的时候先看监控再调。4.3 从源码到 war 包Tomcat 部署的完整命令链路把项目打包成 war 包并部署到 Tomcat整个过程可以全部用命令完成不依赖 IDE 导出。先用 Maven 清理并打包然后停掉 Tomcat把旧包清掉再拷贝新包启动。# 1. 项目根目录执行跳过测试能省几分钟 mvn clean package -DskipTests # 2. 把 war 拷贝到 Tomcat 的 webapps 目录 cp target/depot-web.war /opt/apache-tomcat-9/webapps/ # 3. 启动 Tomcatcatalina.out 里能看到启动日志 /opt/apache-tomcat-9/bin/startup.sh tail -f /opt/apache-tomcat-9/logs/catalina.out部署完成后访问http://localhost:8080/depot-web/Tomcat 会自动解压 war 包。如果访问报 404先看webapps目录下有没有生成解压后的文件夹如果报 403多半是目录索引被禁用了或者 Web 应用没有欢迎页。这里有个经常被忽略的坑重复部署时 Tomcat 可能因为 war 包更新而自动解压但老版本会保留旧文件多次迭代后容易混进陈旧 class我习惯每次部署前手动删除解压目录再启动。4.4 生产环境的最小改动端口、数据库账号与日志开发环境跑通后部署到服务器前最值得改的三件事是端口、数据库账号和日志级别。Tomcat 默认端口8080想改就编辑conf/server.xml里的Connector portroot账号直接连生产库是安全大忌建一个最小权限账号只授权depot_db库。日志级别至少把项目的日志框架设为INFO不然出问题的时候抓不到细节。Connector port8088 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 /在这段配置里connectionTimeout如果设太短客户端慢网速下传个大文件就会被掐断设太长则会被耗死线程。acceptCount是等待队列长度小并发场景默认 100 够用。改完server.xml必须重启 Tomcat 才生效这步常有人忘记然后各种找问题属于典型的人为操作遗漏。5. 高频避坑从时区报错到库存负数五个必查位置5.1 时区报错一串乱码背后的真相现象启动项目后第一次访问数据库就抛异常报错信息类似The server time zone value Öйú±ê׼ʱ¼ä is unrecognized后面还跟着一串看不懂的字符。没经验的人会以为编码坏了其实这是 MySQL 8 和 JDBC 驱动对时区认知不一致导致的。原因MySQL 8 的时区默认取系统时区而连接参数里没指定服务器时区驱动不知道按哪个时区解释时间。解决方法是连接 URL 里显式加上serverTimezoneAsia/Shanghai。如果服务器本身时区是 UTC也可以在 MySQL 里执行SET GLOBAL time_zone 08:00但改代码里的 URL 是最快最不容易影响其他人的做法。改完记得重启应用连接池里旧的连接不会自动拿到新参数。5.2 驱动类名找不到MySQL 8 的兼容性陷阱现象启动时抛ClassNotFoundException: com.mysql.jdbc.Driver或者执行 SQL 时报Failed to load driver class。原因MySQL 8 的驱动包把主类从com.mysql.jdbc.Driver改名成了com.mysql.cj.jdbc.Driver旧类名在驱动包里已经不在了。网上很多老教程还在教 5.x 的写法照着抄就容易中招。解决方法是把驱动配置改成com.mysql.cj.jdbc.Driver同时确认pom.xml里的版本是 8.x。还有一个小坑如果你的项目里同时存在老驱动和新驱动的依赖冲突Maven 会挑一个加载排查时直接看依赖树mvn dependency:tree比瞎猜快得多。5.3 中文乱码三层字符集必须一致现象页面上传的商品名称存到数据库里变成???或者从数据库查出来到页面上是乱码。排查一圈发现字符集配置到处都对了还是乱。原因字符集链路上有三个环节缺一不可。第一是数据库和表结构用utf8mb4第二是 JDBC URL 里带characterEncodingutf8第三是 Web 层的请求和响应编码一致。只调其一没用三个必须同时到位。我常用的做法是写一个CharacterEncodingFilter强制所有请求和响应都用UTF-8在web.xml里配置并让它最先执行这样至少能保证入站参数不乱。如果还是乱用SHOW CREATE TABLE goods;看表的 charset 是不是utf8mb4很多老库建表时默认沿用了latin1这种只能改表结构。5.4 库存变负数查不到原因时先看是不是并发现象系统用了一阵某件商品的库存突然变成负数但你翻流水记录发现每一笔出库当时库存都是够的。原因这是最典型的并发问题。两个出库请求同时读取库存为 10都判断可以出 8先后执行更新结果就是先减后减最终变成负数。解决要分两层第一层是事务里用SELECT ... FOR UPDATE锁行第二层是UPDATE stock SET qty qty - ? WHERE id ? AND qty ?做条件防御。前者保证读的时候不被别人改后者保证写的时候不会越界。如果这两层都做了还出现负数就去查应用日志里有没有异常后未回滚的连接那种情况会让事务失效。5.5 连接被拒先分清 MySQL 还是防火墙的锅现象应用部署在服务器上本地连不上数据库报Communications link failure或Cant connect to MySQL server。新手第一反应是改防火墙但很多时候问题根本不在防火墙。原因常见的可能有三种MySQL 服务没启动监听地址是127.0.0.1外部访问不到账号权限不允许远程连接。排查顺序我一般这样走先在本机执行mysql -u root -p确认服务正常再用netstat -an | grep 3306看监听地址最后用SHOW GRANTS FOR root%;检查远程权限。都确认没问题再碰防火墙规则否则容易把防火墙壁垒越改越松系统安全性也一起下降了。6. 进阶技巧库存预警、流水追查与慢查询优化6.1 库存预警一条 SQL 找到要补货的商品给goods表加了min_stock字段后库存预警就变得很简单。写一个定时任务或者直接在库存查询页加一个“预警列表”按钮执行下面这条 SQL把当前库存低于下限的商品一次性捞出来。SELECT g.code, g.name, s.qty, g.min_stock FROM stock s JOIN goods g ON s.goods_id g.id WHERE s.qty g.min_stock ORDER BY (g.min_stock - s.qty) DESC;核心逻辑是在查询阶段统一判断不用在 Java 代码里遍历每条商品的库存再做 if 判断。如果预警数量需要频繁查可以给min_stock和qty的差值建一个虚拟列以后直接按虚拟列排序效果一样但 SQL 更清晰。6.2 流水表越查越慢复合索引怎么加系统跑了大半年流水表数据破百万后按商品查历史进出明细明显变慢页面转圈几秒钟。原因很直接流水表的索引只有主键id和唯一键flow_no按goods_id查时全表扫描。用EXPLAIN看一下执行计划rows字段几十万索引优化方向就很明确了。ALTER TABLE stock_flow ADD INDEX idx_goods_time (goods_id, created_at);加完索引后再用EXPLAIN验证key列会从NULL变成idx_goods_time。这个复合索引既支持按商品查也支持按商品加时间范围查比单独给goods_id建一个索引更高效因为查询条件里最常见的组合就是“某商品某段时间的流水”。注意索引不是越多越好流水表的核心查询就这几个够用即可无脑加索引会让插入变慢日志量大时会拖累整个系统。这套系统我自己从头写过不止一次最大的教训是库存能对上账比功能花哨重要得多。着一开始我也犯过“只更新库存不写流水”的错月底盘库对不上时翻遍代码也找不到问题后来老老实实把流水表补齐对账才变成一件十分钟的事。希望这份从表设计到部署排障的实践笔记能帮到你让你少走我走过的弯路。本文还有配套的精品资源点击获取 Java+MySQL实现仓库存储管理系统：表结构、事务与部署实战
简介基于JavaMySQL的Web企业仓库存储管理系统是一套面向高校课程设计或毕业设计的B/S架构完整项目。系统采用Spring BootJavaMavenMyBatis搭建覆盖客户、仓库、产品三类基本信息管理以及入库、出库记录和库存管理附带用户权限与系统日志功能适用于仓库管理场景的入门学习与二次开发。资源包共221个文件压缩后约6.95MB。其中42个Java源码文件构成业务逻辑主体28个HTML与JS/CSS文件为前端管理界面另含SQL数据库脚本、XML映射配置及1份说明文档75个GIF演示图可直观展示各模块操作流程辅助快速上手。资源已有568人学习浏览。完整的前后端代码、数据库初始化脚本与演示素材打包在一起目录层级清晰既能对照演示图理解业务流程也可直接导入IDEA运行调试是课程设计或仓库系统开发的有力参考。1. 企业仓库存储管理系统为什么 Java MySQL 的 Web 方案不过时仓库里堆着几百个 SKU每天十几张入库单、出库单来回传靠 Excel 台账硬撑两个人同时改一个单元格月底盘库对不上数几乎成了例行公事。基于 Java MySQL 实现 Web 企业仓库存储管理系统就是为了解决这个最朴素的问题把入库、出库、库存查询、盘点和流水追查全部搬到浏览器里谁在什么时间动了哪件货数据库里一查便知。这套技术组合看着传统却正是中小型仓库场景里稳定性最高、人才最好招、后续最好改的起步方案。对正在做课设或毕设的 Java 学习者来说这类系统覆盖了 Servlet、JDBC、事务、SQL 设计、部署上线几乎所有核心考点对想低成本上信息化的运维人员来说它不需要微服务不需要分布式一台普通服务器加一个 Tomcat 就能跑。下面按“数据模型先行、业务代码跟上、部署排障收尾”的节奏展开尽量把每步的坑都填平。2. 先立规矩仓库系统的表结构设计与 MySQL 建库脚本2.1 入出库的数据流为什么先写流水再改库存很多第一次做仓库系统的人会把库存当成唯一核心写一个goods表里面放一个qty字段入库就qty 1出库就qty - 1。系统刚上线时挺好用跑一个月就暴露问题了某天库存对不上你想查出是哪张单据导致的发现数据库里只有当前数量没有任何历史记录。想复盘只能靠出库单纸质底根去翻这等于把 Excel 台账又搬回数据库里。常见的可靠做法是拆成“两张表”一张stock只存当前数量一张stock_flow存每一笔业务流水。入库时先查当前库存写一条change_type1的流水再更新库存表的数量出库则写change_type2的流水同时把库存减掉。核心原则是先写流水、再改库存而且两个动作必须在同一个事务里完成否则会出现“流水有了但库存没变”或者反过来库存变了却没记录的对账缺口。盘点动作也走同一套逻辑只是change_type3数量按“盘点实存数量 - 账面数量”的差值入账。这样任何时候想查“某件商品从入库到现在一共进出多少”直接对stock_flow做聚合就行不需要去翻历史快照。这个设计虽然多一张表、多一步操作但它是整个系统能长期对得上账的地基。2.2 核心表结构设计用户表、商品表、库存表、流水表以最小可用系统为例四张表足够覆盖核心业务再按需扩展。第一张是sys_user用户表字段要包含用户名、密码、真实姓名和角色角色用TINYINT区分管理员和库管员比用字符串省空间也更好扩展。第二张是goods商品表核心字段是商品编码、名称、规格、单位和库存预警下限注意商品编码要加唯一约束因为实际业务里编码才是业务主键。第三张是stock库存表goods_id与商品表一对一用UNIQUE约束保证一个商品只有一行库存记录。这里有一个新手容易忽略的点库存表不要放冗余的商品名称字段查询时再去 JOIN 商品表否则商品改名后库存表里的历史名称会变成脏数据。第四张是stock_flow流水表字段包含唯一流水号、商品 ID、变动类型、变动数量、变动前数量、变动后数量、操作人 ID、备注和创建时间。下面是这四张表的字段设计对比照着建表前先想清楚每列的含义。表名关键字段约束说明sys_userusername, password, roleusername 唯一role 用 TINYINTgoodscode, name, spec, unit, min_stockcode 唯一min_stock 用于预警stockgoods_id, qty, update_timegoods_id 唯一且外键引用 goodsstock_flowflow_no, goods_id, change_type, qty, before_qty, after_qtyflow_no 唯一qty 一律存正数方向靠 change_type 区分两个容易踩的设计细节一是流水表的qty字段不要存负数入库出库都存正数用change_type表达方向否则以后做统计SUM(qty)时逻辑会绕二是必须存before_qty和after_qty两个快照值这是以后核对“那笔操作前后库存到底是多少”的后悔药没有这两个字段事务回滚后很难从流水反推现场。2.3 建库建表脚本utf8mb4 与 InnoDB 的取舍建库脚本直接决定后面排障的难易程度。字符集我一律用utf8mb4不是utf8这能兼容生僻字和特殊符号存储引擎用InnoDB因为要依赖它的事务能力MyISAM 在这个场景下没有任何优势。下面是一份可以直接执行的 MySQL 8 建库建表脚本。-- 建库字符集必须用 utf8mb4排序规则选 unicode_ci CREATE DATABASE IF NOT EXISTS depot_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE depot_db; CREATE TABLE sys_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, real_name VARCHAR(30), role TINYINT NOT NULL DEFAULT 2 COMMENT 1管理员 2库管员, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE goods ( id INT AUTO_INCREMENT PRIMARY KEY, code VARCHAR(30) NOT NULL UNIQUE COMMENT 商品编码业务唯一, name VARCHAR(100) NOT NULL, spec VARCHAR(100), unit VARCHAR(10) DEFAULT 件, min_stock INT NOT NULL DEFAULT 0 COMMENT 库存预警下限, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE stock ( id INT AUTO_INCREMENT PRIMARY KEY, goods_id INT NOT NULL UNIQUE, qty INT NOT NULL DEFAULT 0, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_stock_goods FOREIGN KEY (goods_id) REFERENCES goods(id) ) ENGINEInnoDB; CREATE TABLE stock_flow ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flow_no VARCHAR(32) NOT NULL UNIQUE, goods_id INT NOT NULL, change_type TINYINT NOT NULL COMMENT 1入库 2出库 3盘点, qty INT NOT NULL, before_qty INT NOT NULL, after_qty INT NOT NULL, operator_id INT NOT NULL, remark VARCHAR(200), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_flow_goods FOREIGN KEY (goods_id) REFERENCES goods(id) ) ENGINEInnoDB;这份脚本里有几个参数值得单独说明。NOT NULL用在所有业务关键字段上避免代码里因为NULL判断写出一堆分支UNIQUE用在username、code、flow_no三个业务唯一键上比在代码里先查再插更可靠外键约束在这个规模下开着没问题能防止删除商品时留下孤儿库存数据但如果以后分库分表外键就得去掉。数量字段全部用INT别用VARCHAR存数字MySQL 对字符串排序会按字典序排9会排在10后面。如果系统涉及金额记住DECIMAL(10,2)禁止用FLOAT。3. 用 Java JDBC 打通入库出库事务代码与参数细节3.1 Servlet JDBC 的选型理由课设与小型项目最稳的路径标题只写了 Java MySQL Web框架层面其实有很多选择Spring Boot MyBatis、Spring MVC JPA、Servlet JDBC。我一般会建议课程设计和快速落地的小型仓库系统优先考虑 Servlet JDBC 这条朴素路径原因不是它新而是它把 Java Web 的核心链路全部暴露出来请求怎么进 Servlet、SQL 怎么拼、事务怎么控制、连接怎么关。用 Spring Boot 虽然开发快但很多初学者调一个依赖冲突就要折腾一晚上反而不容易看清问题本质。JDBC 的部分很多人觉得低级其实它就是所有框架的地基。MyBatis 帮你生成的PreparedStatement、帮你管理的事务本质和手写 JDBC 是一样的逻辑只是封装了。如果你先把 JDBC 版本跑通再去看 MyBatis 源码很多“玄学”问题会一下想通。这一章就以 JDBC 为主把入库、出库两个最核心的 Service 方法完整走一遍。3.2 JdbcUtils 与连接池参数先把数据库连接管好写 JDBC 最容易翻车的位置就是连接管理拿到连接不关、ResultSet不释放跑半天后连接池被打满系统假死。常见做法是封装一个JdbcUtils工具类统一负责获取连接和关闭资源连接池用 Druid 或 HikariCP 都行。下面这段是完整可用的工具类骨架。public class JdbcUtils { private static DataSource dataSource; static { try (InputStream in JdbcUtils.class.getClassLoader() .getResourceAsStream(jdbc.properties)) { Properties props new Properties(); props.load(in); dataSource DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } public static void close(Connection conn, Statement stmt, ResultSet rs) { if (rs ! null) { try { rs.close(); } catch (SQLException ignored) {} } if (stmt ! null) { try { stmt.close(); } catch (SQLException ignored) {} } if (conn ! null) { try { conn.close(); } catch (SQLException ignored) {} } } }关键点有两个。一是静态代码块里初始化数据源类加载时只执行一次避免每个请求都去读配置文件。二是关闭顺序必须从里往外先关ResultSet再关Statement最后关Connection顺序反了会导致某些数据库驱动报错。连接池的jdbc.properties放到src/main/resources下驱动类名在 MySQL 8 里必须写com.mysql.cj.jdbc.Driver这是很多人从 5.x 升级后翻车的头号原因后面避坑章节还会专门讲。3.3 入库出库的事务代码先锁行再更新库存再写流水入库操作的业务逻辑不复杂但必须是一个原子操作。下面代码展示的是完整事务写法不用Transactional注解手写commit和rollback这样能清楚看到事务边界在哪里。public void inbound(StockFlowDTO dto) throws Exception { Connection conn null; PreparedStatement psLock null; PreparedStatement psUpdate null; PreparedStatement psFlow null; ResultSet rs null; try { conn JdbcUtils.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 锁定商品对应的库存行防止并发下算错库存 psLock conn.prepareStatement( SELECT id, qty FROM stock WHERE goods_id ? FOR UPDATE); psLock.setInt(1, dto.getGoodsId()); rs psLock.executeQuery(); int oldQty 0; int stockId 0; if (rs.next()) { stockId rs.getInt(id); oldQty rs.getInt(qty); } // 2. 更新库存表 int newQty oldQty dto.getQty(); psUpdate conn.prepareStatement( UPDATE stock SET qty ? WHERE id ?); psUpdate.setInt(1, newQty); psUpdate.setInt(2, stockId); psUpdate.executeUpdate(); // 3. 写流水表 psFlow conn.prepareStatement( INSERT INTO stock_flow (flow_no, goods_id, change_type, qty, before_qty, after_qty, operator_id, remark) VALUES (?, ?, ?, ?, ?, ?, ?, ?)); psFlow.setString(1, generateFlowNo()); // 全局唯一流水号 psFlow.setInt(2, dto.getGoodsId()); psFlow.setInt(3, 1); // 1代表入库 psFlow.setInt(4, dto.getQty()); psFlow.setInt(5, oldQty); psFlow.setInt(6, newQty); psFlow.setInt(7, dto.getOperatorId()); psFlow.setString(8, dto.getRemark()); psFlow.executeUpdate(); conn.commit(); } catch (Exception e) { if (conn ! null) conn.rollback(); throw e; } finally { if (conn ! null) conn.setAutoCommit(true); JdbcUtils.close(conn, psUpdate, rs); try { if (psFlow ! null) psFlow.close(); } catch (SQLException ignored) {} try { if (psLock ! null) psLock.close(); } catch (SQLException ignored) {} } }这段代码里最重要的不是UPDATE而是FOR UPDATE这一句。它把stock表的对应行锁住直到事务提交或回滚才释放这样两个用户同时对同一商品入库时第二个请求会等第一个提交后再读取不会出现“两个人都读到库存是 100分别加 10最后库存变成 110 而不是 120”的经典并发问题。加锁会牺牲一点性能但在仓库业务这种低频高正确的场景下非常值得。generateFlowNo()需要你自己实现我一般用yyyyMMddHHmmss 三位随机数或者直接用数据库主键替代。现实里更严谨的做法是独立一张流水号序列表用SELECT ... FOR UPDATE取号但这种小系统里时间戳加随机数已经够用。注意UPDATE stock之前一定要先SELECT ... FOR UPDATE拿到旧值否则before_qty和after_qty没数据可填流水就失去了快照意义。3.4 防止出库成负数条件更新是最后一道防线出库和入库的代码结构一样唯一不同的是更新语句必须带上qty ?条件这是防止库存扣成负数的最后一道防线。有些同学只在 Service 里先查一下数量判断够不够再执行更新这在并发场景下是挡不住的两个请求同时查出库存 10都判断够出 8然后一起执行更新最后库存变成 -6。// 出库把 WHERE qty ? 作为第二道保险 psUpdate conn.prepareStatement( UPDATE stock SET qty qty - ? WHERE id ? AND qty ?); psUpdate.setInt(1, dto.getQty()); psUpdate.setInt(2, stockId); psUpdate.setInt(3, dto.getQty()); int rows psUpdate.executeUpdate(); if (rows 0) { throw new BusinessException(库存不足出库失败); }executeUpdate()返回 0 表示没有匹配的更新也就是库存不足这时候直接抛异常让事务回滚流水也不会写进去。这里我再强调一次判断库存是否充足不能只靠SELECT要以UPDATE的影响行数为准数据库的条件更新才是最可靠的判断。这种“先乐观尝试、失败再回滚”的思路比先查再更新的 check-then-act 模式要结实得多。登录和权限部分不用展开讲太多做一个简单的Filter检查session里有没有用户对象没有就重定向到登录页有就放行。仓库系统不像电商平台需要复杂权限模型sys_user表里的role字段配合一套页面按钮的显隐控制基本就够用了。4. 部署上线JDK、MySQL 连通性与 Tomcat 运行参数4.1 环境准备JDK 环境变量、MySQL 安装配置与 Tomcat 版本对照代码写完只是第一步真正让系统跑起来还要过部署这一关。先从基础环境说起JDK 装好后JAVA_HOME环境变量指向 JDK 根目录PATH里加上%JAVA_HOME%\bin在命令行执行java -version能输出版本号才算配好。这里有个容易踩的细节如果系统里同时装了 JRE 和 JDKPATH里排在前面的那个会被优先执行导致javac命令找不到。MySQL 的安装建议用 msyql-installer 或各系统的包管理工具装完记得确认服务已启动。MySQL 8 默认的认证插件是caching_sha2_password老版本驱动不支持时还会额外踩坑后面避坑章节展开。Tomcat 版本要和 JDK 对应Tomcat 9 对应 JDK 8 及以上Tomcat 10 对应 JDK 11 及以上而且 Tomcat 10 把包名从javax.*改成了jakarta.*如果代码是按老规范写的直接用 Tomcat 10 会编译报错。我一般稳妥选择 Tomcat 9。4.2 jdbc.properties 的正确写法那些一眼看不懂的参数数据库连接配置是部署前最容易出错的地方下面是一份经过实测可用的 MySQL 8 配置每个参数我都标注了含义。driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/depot_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue usernameroot passwordyour_password initialSize5 maxActive20 maxWait10000serverTimezoneAsia/Shanghai是必须的MySQL 8 不设时区时会报一个标准的时区错误错误信息里全是一串乱码第五章细说。useSSLfalse是本地开发必备不然连接时会有一串证书告警甚至握手失败。allowPublicKeyRetrievaltrue解决的是某些 MySQL 8 版本下连接报Public Key Retrieval is not allowed的问题如果不用这个参数也可以把密码认证改成mysql_native_password。characterEncodingutf8保证中文写入数据库不乱码注意和建库时的utf8mb4不冲突一个管连接层一个管存储层。连接池的三个参数initialSize、maxActive、maxWait里maxWait是获取连接的最大等待毫秒数设太短高峰期会大量报获取连接超时设太长用户操作会卡死毫无反馈。仓库系统并发不高maxWait10000是常见取值真到了不够用的时候先看监控再调。4.3 从源码到 war 包Tomcat 部署的完整命令链路把项目打包成 war 包并部署到 Tomcat整个过程可以全部用命令完成不依赖 IDE 导出。先用 Maven 清理并打包然后停掉 Tomcat把旧包清掉再拷贝新包启动。# 1. 项目根目录执行跳过测试能省几分钟 mvn clean package -DskipTests # 2. 把 war 拷贝到 Tomcat 的 webapps 目录 cp target/depot-web.war /opt/apache-tomcat-9/webapps/ # 3. 启动 Tomcatcatalina.out 里能看到启动日志 /opt/apache-tomcat-9/bin/startup.sh tail -f /opt/apache-tomcat-9/logs/catalina.out部署完成后访问http://localhost:8080/depot-web/Tomcat 会自动解压 war 包。如果访问报 404先看webapps目录下有没有生成解压后的文件夹如果报 403多半是目录索引被禁用了或者 Web 应用没有欢迎页。这里有个经常被忽略的坑重复部署时 Tomcat 可能因为 war 包更新而自动解压但老版本会保留旧文件多次迭代后容易混进陈旧 class我习惯每次部署前手动删除解压目录再启动。4.4 生产环境的最小改动端口、数据库账号与日志开发环境跑通后部署到服务器前最值得改的三件事是端口、数据库账号和日志级别。Tomcat 默认端口8080想改就编辑conf/server.xml里的Connector portroot账号直接连生产库是安全大忌建一个最小权限账号只授权depot_db库。日志级别至少把项目的日志框架设为INFO不然出问题的时候抓不到细节。Connector port8088 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 /在这段配置里connectionTimeout如果设太短客户端慢网速下传个大文件就会被掐断设太长则会被耗死线程。acceptCount是等待队列长度小并发场景默认 100 够用。改完server.xml必须重启 Tomcat 才生效这步常有人忘记然后各种找问题属于典型的人为操作遗漏。5. 高频避坑从时区报错到库存负数五个必查位置5.1 时区报错一串乱码背后的真相现象启动项目后第一次访问数据库就抛异常报错信息类似The server time zone value Öйú±ê׼ʱ¼ä is unrecognized后面还跟着一串看不懂的字符。没经验的人会以为编码坏了其实这是 MySQL 8 和 JDBC 驱动对时区认知不一致导致的。原因MySQL 8 的时区默认取系统时区而连接参数里没指定服务器时区驱动不知道按哪个时区解释时间。解决方法是连接 URL 里显式加上serverTimezoneAsia/Shanghai。如果服务器本身时区是 UTC也可以在 MySQL 里执行SET GLOBAL time_zone 08:00但改代码里的 URL 是最快最不容易影响其他人的做法。改完记得重启应用连接池里旧的连接不会自动拿到新参数。5.2 驱动类名找不到MySQL 8 的兼容性陷阱现象启动时抛ClassNotFoundException: com.mysql.jdbc.Driver或者执行 SQL 时报Failed to load driver class。原因MySQL 8 的驱动包把主类从com.mysql.jdbc.Driver改名成了com.mysql.cj.jdbc.Driver旧类名在驱动包里已经不在了。网上很多老教程还在教 5.x 的写法照着抄就容易中招。解决方法是把驱动配置改成com.mysql.cj.jdbc.Driver同时确认pom.xml里的版本是 8.x。还有一个小坑如果你的项目里同时存在老驱动和新驱动的依赖冲突Maven 会挑一个加载排查时直接看依赖树mvn dependency:tree比瞎猜快得多。5.3 中文乱码三层字符集必须一致现象页面上传的商品名称存到数据库里变成???或者从数据库查出来到页面上是乱码。排查一圈发现字符集配置到处都对了还是乱。原因字符集链路上有三个环节缺一不可。第一是数据库和表结构用utf8mb4第二是 JDBC URL 里带characterEncodingutf8第三是 Web 层的请求和响应编码一致。只调其一没用三个必须同时到位。我常用的做法是写一个CharacterEncodingFilter强制所有请求和响应都用UTF-8在web.xml里配置并让它最先执行这样至少能保证入站参数不乱。如果还是乱用SHOW CREATE TABLE goods;看表的 charset 是不是utf8mb4很多老库建表时默认沿用了latin1这种只能改表结构。5.4 库存变负数查不到原因时先看是不是并发现象系统用了一阵某件商品的库存突然变成负数但你翻流水记录发现每一笔出库当时库存都是够的。原因这是最典型的并发问题。两个出库请求同时读取库存为 10都判断可以出 8先后执行更新结果就是先减后减最终变成负数。解决要分两层第一层是事务里用SELECT ... FOR UPDATE锁行第二层是UPDATE stock SET qty qty - ? WHERE id ? AND qty ?做条件防御。前者保证读的时候不被别人改后者保证写的时候不会越界。如果这两层都做了还出现负数就去查应用日志里有没有异常后未回滚的连接那种情况会让事务失效。5.5 连接被拒先分清 MySQL 还是防火墙的锅现象应用部署在服务器上本地连不上数据库报Communications link failure或Cant connect to MySQL server。新手第一反应是改防火墙但很多时候问题根本不在防火墙。原因常见的可能有三种MySQL 服务没启动监听地址是127.0.0.1外部访问不到账号权限不允许远程连接。排查顺序我一般这样走先在本机执行mysql -u root -p确认服务正常再用netstat -an | grep 3306看监听地址最后用SHOW GRANTS FOR root%;检查远程权限。都确认没问题再碰防火墙规则否则容易把防火墙壁垒越改越松系统安全性也一起下降了。6. 进阶技巧库存预警、流水追查与慢查询优化6.1 库存预警一条 SQL 找到要补货的商品给goods表加了min_stock字段后库存预警就变得很简单。写一个定时任务或者直接在库存查询页加一个“预警列表”按钮执行下面这条 SQL把当前库存低于下限的商品一次性捞出来。SELECT g.code, g.name, s.qty, g.min_stock FROM stock s JOIN goods g ON s.goods_id g.id WHERE s.qty g.min_stock ORDER BY (g.min_stock - s.qty) DESC;核心逻辑是在查询阶段统一判断不用在 Java 代码里遍历每条商品的库存再做 if 判断。如果预警数量需要频繁查可以给min_stock和qty的差值建一个虚拟列以后直接按虚拟列排序效果一样但 SQL 更清晰。6.2 流水表越查越慢复合索引怎么加系统跑了大半年流水表数据破百万后按商品查历史进出明细明显变慢页面转圈几秒钟。原因很直接流水表的索引只有主键id和唯一键flow_no按goods_id查时全表扫描。用EXPLAIN看一下执行计划rows字段几十万索引优化方向就很明确了。ALTER TABLE stock_flow ADD INDEX idx_goods_time (goods_id, created_at);加完索引后再用EXPLAIN验证key列会从NULL变成idx_goods_time。这个复合索引既支持按商品查也支持按商品加时间范围查比单独给goods_id建一个索引更高效因为查询条件里最常见的组合就是“某商品某段时间的流水”。注意索引不是越多越好流水表的核心查询就这几个够用即可无脑加索引会让插入变慢日志量大时会拖累整个系统。这套系统我自己从头写过不止一次最大的教训是库存能对上账比功能花哨重要得多。着一开始我也犯过“只更新库存不写流水”的错月底盘库对不上时翻遍代码也找不到问题后来老老实实把流水表补齐对账才变成一件十分钟的事。希望这份从表设计到部署排障的实践笔记能帮到你让你少走我走过的弯路。本文还有配套的精品资源点击获取