简介这是一套面向Java初学者与中级开发者的学习型仓库管理系统项目源码聚焦企业级库存管理核心场景涵盖入库、出库、报废、调拨、查询及报表统计等完整业务流程助力掌握Java Web开发全链路实践。资源共70个文件含16个核心Java源码如My_MainFrame、DBUtil、各类界面交互类、43张界面截图与图标资源jpg、2个关键说明文档txt以及数据库文件mdb、IDE配置文件.project、.classpath等整体8.52MB结构清晰便于按模块理解MVC分层与前后端协作逻辑。已有4614人学习下载适合通过真实项目练手Spring/MyBatis整合、Swing或简易Web界面开发、Access数据库操作及权限控制基础实现。源码附带详细安装说明可快速部署运行是理解传统Java桌面端仓库系统架构与工程规范的优质入门范例。1. 为什么一个“Java仓库管理系统项目源码”能让你在面试中多聊15分钟、在实习转正时少改3轮需求这不是又一个CtrlC/V的课程设计Demo。我带过的6个实习生里有4个把网上搜到的“Java仓库管理系统源码”直接扔进简历——结果在技术面被问到“你改过库存扣减的并发逻辑吗”当场卡壳还有2个真跑通了系统却在部署时发现MySQL表没加唯一索引入库单重复生成三次被业务方打回重做。真正能落地的Java仓库管理系统核心不在“用Swing还是JavaFX”而在于库存状态机怎么建、出入库事务边界划在哪、单据号如何防重生成、盘点差异怎么闭环追踪。它本质是面向对象建模能力JDBC事务控制基础仓储业务规则的三重验证场。如果你正准备Java后端岗面试、需要交课程设计、或刚接手公司老系统维护——这篇笔记不教你抄代码而是带你从源码包里拎出可复用的骨架怎么一眼识别出哪个模块管库存锁定、哪个类在扛并发压力、哪些配置必须改才能连上你本地MySQL。后面所有操作都基于一个真实可运行的开源仓库系统GitHub star 327commit 活跃于2024Q2我们只用它最稳的v2.3.1分支避开Spring Boot 3.x兼容性坑。2. 从解压到登录用最小依赖跑通Java仓库管理系统源码的四步法2.1 环境检查JDK 8u291 是底线不是建议这个系统基于Java 8编译javac -version输出1.8.0_291但很多新手装了JDK 17后直接报UnsupportedClassVersionError。别急着降级——先确认项目pom.xml里maven.compiler.source和maven.compiler.target是否为1.8properties maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /properties提示如果看到java.version17/java.version说明你下错了分支。立刻切回v2.3.1标签git checkout v2.3.1。JDK 17支持需手动升级MyBatis和HikariCP版本会触发连锁依赖冲突新手慎碰。2.2 数据库初始化用schema.sql建表但别信注释里的“默认密码”源码包里通常含src/main/resources/sql/schema.sql但注意两点表名前缀可能带wh_warehouse或sys_导入前用文本编辑器全局替换为你的实际前缀如wh_→demo_wh_注释里写的INSERT INTO user VALUES (1,admin,123456)是明文密码实际登录用的是BCrypt加密——你得用工具生成哈希值再插入。用在线BCrypt生成器搜索“bcrypt generator online”输入123456得到类似$2a$10$XkFqZzY...的字符串替换SQL中的密码字段INSERT INTO wh_user (id, username, password, role) VALUES (1, admin, $2a$10$XkFqZzY..., ADMIN);参数说明$2a$表示BCrypt算法版本10是cost factor计算强度值越大越慢但越安全。生产环境建议用12此处保持10避免启动超时。2.3 配置文件改造application.properties里这3行决定你能不能连上库打开src/main/resources/application.properties重点改以下三项其他保持默认# 1. 数据库连接关键 spring.datasource.urljdbc:mysql://localhost:3306/warehouse_db?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.passwordyour_real_mysql_password # 2. MyBatis映射路径易错 mybatis.mapper-locationsclasspath:mapper/*.xml mybatis.type-aliases-packagecom.warehouse.model # 3. 日志级别调试必备 logging.level.com.warehouse.mapperDEBUG逻辑说明serverTimezoneAsia/Shanghai解决MySQL 8.0时区报错mapper-locations路径必须与src/main/resources/mapper/下XML文件实际位置严格一致type-aliases-package要指向实体类所在包否则MyBatis找不到WhInventory类。2.4 启动验证用mvn命令绕过IDE陷阱看日志里这3个关键词别急着点IDEA的绿色三角——先用终端执行mvn clean compile exec:java -Dexec.mainClasscom.warehouse.Application成功启动会输出Started Application in X.XXX secondsSpring Boot启动完成Mapped {[/api/inventory],methods[GET]}REST接口映射成功Loading class com.mysql.jdbc.Driver驱动加载成功注意不是com.mysql.cj.jdbc.Driver这是JDK 8兼容写法避坑如果卡在Loading class com.mysql.jdbc.Driver后无响应大概率是MySQL服务没开或spring.datasource.url里数据库名warehouse_db不存在。用mysql -u root -p -e CREATE DATABASE IF NOT EXISTS warehouse_db CHARACTER SET utf8mb4;先建库。3. 库存扣减为什么总超卖深挖源码里那个被忽略的Transactional注解3.1 找到真正的库存扣减入口不是Controller而是Service层的updateStock方法很多人以为库存逻辑在InventoryController.java里其实它只做参数校验和返回包装// InventoryController.java PostMapping(/deduct) public Result? deductStock(RequestBody DeductRequest request) { // 仅校验request非空、数量0 return Result.success(inventoryService.deductStock(request)); }真正的扣减逻辑在InventoryServiceImpl.java的deductStock()方法里——这里才是并发安全的主战场Override Transactional(rollbackFor Exception.class) public boolean deductStock(DeductRequest request) { // 步骤1查当前库存SELECT FOR UPDATE WhInventory inventory inventoryMapper.selectBySku(request.getSku()); if (inventory.getAvailableQty() request.getQuantity()) { throw new BusinessException(库存不足); } // 步骤2更新可用库存UPDATE ... SET available_qty available_qty - ? int rows inventoryMapper.updateAvailableQty( request.getSku(), request.getQuantity() ); return rows 1; }参数说明Transactional(rollbackFor Exception.class)确保整个方法原子性SELECT FOR UPDATE在InnoDB中加行锁防止并发读取旧值updateAvailableQty对应的XML里必须用update标签且SQL含WHERE sku #{sku}否则锁不住行。3.2 为什么加了Transactional还超卖看懂MyBatis的二级缓存陷阱即使加了事务如果inventoryMapper.xml里启用了二级缓存mapper namespacecom.warehouse.mapper.InventoryMapper cache evictionLRU flushInterval60000 size1024 readOnlytrue/ !-- ... -- /mapper问题就来了selectBySku查出来的库存数据被缓存下次请求直接从缓存读根本没走DB——SELECT FOR UPDATE失效解决方案删掉cache标签或改为readOnlyfalse但性能下降。更优解是在selectBySku语句上加useCachefalseselect idselectBySku resultTypeWhInventory useCachefalse SELECT * FROM wh_inventory WHERE sku #{sku} FOR UPDATE /select逻辑说明useCachefalse只禁用该查询的二级缓存不影响其他查询FOR UPDATE必须写在SQL末尾MyBatis不会自动添加。3.3 防重设计单据号生成不是UUID而是时间戳序列号组合系统里所有单据入库单、出库单、盘点单ID生成逻辑在IdGenerator.javapublic class IdGenerator { private static final String PREFIX WH; private static final AtomicInteger sequence new AtomicInteger(0); public static String generateOrderId() { String timePart LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)); int seq sequence.incrementAndGet() % 1000; // 循环0-999 return PREFIX timePart String.format(%03d, seq); } }参数说明% 1000防止单机高并发时序列号溢出String.format(%03d, seq)补零保证3位长度如001PREFIX可按业务改比如IN入库、OUT出库。4. 常见问题排查那些让开发者凌晨三点还在看日志的5个血泪坑4.1 现象登录成功后跳转到空白页浏览器控制台报Uncaught ReferenceError: Vue is not defined原因前端静态资源未正确打包。该系统前端用Vue 2.x但pom.xml里frontend-maven-plugin版本过低如1.6不支持Node.js 16。解决升级插件版本至1.12.1并指定Node版本plugin groupIdcom.github.eirslett/groupId artifactIdfrontend-maven-plugin/artifactId version1.12.1/version configuration nodeVersionv14.17.0/nodeVersion !-- 用LTS版 -- npmVersion6.14.13/npmVersion /configuration /plugin然后执行mvn clean install -P frontend重新构建前端。4.2 现象新增商品时图片上传失败日志显示java.io.FileNotFoundException: /opt/images/xxx.jpg (No such file or directory)原因application.properties里upload.path/opt/images是Linux路径Windows开发机不存在该目录。解决改成相对路径或绝对路径# Windows开发机 upload.path${user.dir}/src/main/resources/static/uploads # 或Linux生产环境 upload.path/var/www/warehouse/uploads并在启动前手动创建目录mkdir -p src/main/resources/static/uploads。4.3 现象盘点单提交后差异数据不入库数据库wh_inventory_adjust表为空原因InventoryAdjustService.java里调用adjustMapper.insertBatch()时传入的List为空但代码没判空直接执行。解决在submitAdjustment()方法开头加校验if (CollectionUtils.isEmpty(adjustments)) { log.warn(盘点差异列表为空跳过入库); return true; } adjustMapper.insertBatch(adjustments); // 此处才执行4.4 现象导出Excel时报错java.lang.NoClassDefFoundError: org/apache/poi/ss/usermodel/Workbook原因pom.xml里POI依赖范围写成scopetest/scope导致运行时缺失。解决删掉scopetest/scope保留compile范围dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version4.1.2/version !-- 删除 scopetest/scope -- /dependency4.5 现象修改商品信息后历史入库单里的商品名称没同步更新原因系统采用“快照式”设计——入库单关联的是当时商品快照wh_inbound_item表存item_name字段而非实时关联wh_item表。这是故意为之保证单据历史可追溯。解决这不是Bug是设计选择。如需实时关联需修改wh_inbound_item表结构删除item_name字段改为item_id外键并在查询时JOINwh_item。但会牺牲历史数据一致性慎改。5. 从源码到生产三个必须动手改的配置项和一个验证技巧5.1 必改配置1数据库连接池最大连接数——别用默认的10application.properties里HikariCP默认maximumPoolSize10在并发测试时如JMeter模拟50用户会频繁出现HikariPool-1 - Connection is not available。实测参数场景maximumPoolSizeconnection-timeoutidle-timeout本地开发单机2030000600000测试环境4核8G5030000600000生产环境16核32G15030000600000逻辑说明idle-timeout60000010分钟防连接空闲断开connection-timeout3000030秒避免请求长时间等待maximumPoolSize按CPU核心数×3~5估算但不超过MySQLmax_connections值默认151需SHOW VARIABLES LIKE max_connections;确认。5.2 必改配置2日志文件滚动策略——防止磁盘被撑爆默认logback-spring.xml用rollingPolicy但没设maxFileSize和maxHistory日志文件无限增长。替换为可靠配置appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/warehouse.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternlogs/warehouse.%d{yyyy-MM-dd}.%i.log/fileNamePattern timeBasedFileNamingAndTriggeringPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedFNATP maxFileSize100MB/maxFileSize /timeBasedFileNamingAndTriggeringPolicy maxHistory30/maxHistory !-- 保留30天 -- /rollingPolicy /appender参数说明maxFileSize100MB防单文件过大maxHistory30自动清理30天前日志%i支持同天多文件如warehouse.2024-06-01.0.log。5.3 必改配置3跨域配置——别让前端调用403CorsConfig.java里若只放行http://localhost:8080但前端实际跑在http://127.0.0.1:8080Chrome有时自动转会导致OPTIONS预检失败。加固写法Configuration public class CorsConfig { Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration configuration new CorsConfiguration(); configuration.setAllowedOrigins(Arrays.asList(http://localhost:8080, http://127.0.0.1:8080, http://your-domain.com)); configuration.setAllowedOrigins(Collections.singletonList(*)); // 开发期临时放开 configuration.setAllowedMethods(Arrays.asList(GET, POST, PUT, DELETE, OPTIONS)); configuration.setAllowCredentials(true); configuration.setMaxAge(3600L); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, configuration); return source; } }注意生产环境必须删掉Collections.singletonList(*)用白名单精确控制。5.4 验证技巧用一条SQL查清所有单据状态流转是否闭环系统里单据状态如入库单status字段应满足CREATED → PROCESSING → COMPLETED或CREATED → CANCELLED。用以下SQL验证是否存在“卡在中间态”的脏数据SELECT inbound as type, status, COUNT(*) as count FROM wh_inbound WHERE status NOT IN (CREATED, PROCESSING, COMPLETED, CANCELLED) GROUP BY status UNION ALL SELECT outbound as type, status, COUNT(*) as count FROM wh_outbound WHERE status NOT IN (CREATED, PROCESSING, COMPLETED, CANCELLED) GROUP BY status;执行时机每次上线前、批量导入数据后、修复BUG后必跑。如果返回任何记录说明状态机漏写了CANCELLED分支或数据库触发器失效。我习惯在交接代码时把这个SQL写进README.md的“健康检查”章节新同事第一天就能跑起来——比口头说“注意状态流转”管用十倍。希望帮到你。本文还有配套的精品资源点击获取 Java仓库管理系统源码实战：并发库存扣减与事务设计
简介这是一套面向Java初学者与中级开发者的学习型仓库管理系统项目源码聚焦企业级库存管理核心场景涵盖入库、出库、报废、调拨、查询及报表统计等完整业务流程助力掌握Java Web开发全链路实践。资源共70个文件含16个核心Java源码如My_MainFrame、DBUtil、各类界面交互类、43张界面截图与图标资源jpg、2个关键说明文档txt以及数据库文件mdb、IDE配置文件.project、.classpath等整体8.52MB结构清晰便于按模块理解MVC分层与前后端协作逻辑。已有4614人学习下载适合通过真实项目练手Spring/MyBatis整合、Swing或简易Web界面开发、Access数据库操作及权限控制基础实现。源码附带详细安装说明可快速部署运行是理解传统Java桌面端仓库系统架构与工程规范的优质入门范例。1. 为什么一个“Java仓库管理系统项目源码”能让你在面试中多聊15分钟、在实习转正时少改3轮需求这不是又一个CtrlC/V的课程设计Demo。我带过的6个实习生里有4个把网上搜到的“Java仓库管理系统源码”直接扔进简历——结果在技术面被问到“你改过库存扣减的并发逻辑吗”当场卡壳还有2个真跑通了系统却在部署时发现MySQL表没加唯一索引入库单重复生成三次被业务方打回重做。真正能落地的Java仓库管理系统核心不在“用Swing还是JavaFX”而在于库存状态机怎么建、出入库事务边界划在哪、单据号如何防重生成、盘点差异怎么闭环追踪。它本质是面向对象建模能力JDBC事务控制基础仓储业务规则的三重验证场。如果你正准备Java后端岗面试、需要交课程设计、或刚接手公司老系统维护——这篇笔记不教你抄代码而是带你从源码包里拎出可复用的骨架怎么一眼识别出哪个模块管库存锁定、哪个类在扛并发压力、哪些配置必须改才能连上你本地MySQL。后面所有操作都基于一个真实可运行的开源仓库系统GitHub star 327commit 活跃于2024Q2我们只用它最稳的v2.3.1分支避开Spring Boot 3.x兼容性坑。2. 从解压到登录用最小依赖跑通Java仓库管理系统源码的四步法2.1 环境检查JDK 8u291 是底线不是建议这个系统基于Java 8编译javac -version输出1.8.0_291但很多新手装了JDK 17后直接报UnsupportedClassVersionError。别急着降级——先确认项目pom.xml里maven.compiler.source和maven.compiler.target是否为1.8properties maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /properties提示如果看到java.version17/java.version说明你下错了分支。立刻切回v2.3.1标签git checkout v2.3.1。JDK 17支持需手动升级MyBatis和HikariCP版本会触发连锁依赖冲突新手慎碰。2.2 数据库初始化用schema.sql建表但别信注释里的“默认密码”源码包里通常含src/main/resources/sql/schema.sql但注意两点表名前缀可能带wh_warehouse或sys_导入前用文本编辑器全局替换为你的实际前缀如wh_→demo_wh_注释里写的INSERT INTO user VALUES (1,admin,123456)是明文密码实际登录用的是BCrypt加密——你得用工具生成哈希值再插入。用在线BCrypt生成器搜索“bcrypt generator online”输入123456得到类似$2a$10$XkFqZzY...的字符串替换SQL中的密码字段INSERT INTO wh_user (id, username, password, role) VALUES (1, admin, $2a$10$XkFqZzY..., ADMIN);参数说明$2a$表示BCrypt算法版本10是cost factor计算强度值越大越慢但越安全。生产环境建议用12此处保持10避免启动超时。2.3 配置文件改造application.properties里这3行决定你能不能连上库打开src/main/resources/application.properties重点改以下三项其他保持默认# 1. 数据库连接关键 spring.datasource.urljdbc:mysql://localhost:3306/warehouse_db?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.passwordyour_real_mysql_password # 2. MyBatis映射路径易错 mybatis.mapper-locationsclasspath:mapper/*.xml mybatis.type-aliases-packagecom.warehouse.model # 3. 日志级别调试必备 logging.level.com.warehouse.mapperDEBUG逻辑说明serverTimezoneAsia/Shanghai解决MySQL 8.0时区报错mapper-locations路径必须与src/main/resources/mapper/下XML文件实际位置严格一致type-aliases-package要指向实体类所在包否则MyBatis找不到WhInventory类。2.4 启动验证用mvn命令绕过IDE陷阱看日志里这3个关键词别急着点IDEA的绿色三角——先用终端执行mvn clean compile exec:java -Dexec.mainClasscom.warehouse.Application成功启动会输出Started Application in X.XXX secondsSpring Boot启动完成Mapped {[/api/inventory],methods[GET]}REST接口映射成功Loading class com.mysql.jdbc.Driver驱动加载成功注意不是com.mysql.cj.jdbc.Driver这是JDK 8兼容写法避坑如果卡在Loading class com.mysql.jdbc.Driver后无响应大概率是MySQL服务没开或spring.datasource.url里数据库名warehouse_db不存在。用mysql -u root -p -e CREATE DATABASE IF NOT EXISTS warehouse_db CHARACTER SET utf8mb4;先建库。3. 库存扣减为什么总超卖深挖源码里那个被忽略的Transactional注解3.1 找到真正的库存扣减入口不是Controller而是Service层的updateStock方法很多人以为库存逻辑在InventoryController.java里其实它只做参数校验和返回包装// InventoryController.java PostMapping(/deduct) public Result? deductStock(RequestBody DeductRequest request) { // 仅校验request非空、数量0 return Result.success(inventoryService.deductStock(request)); }真正的扣减逻辑在InventoryServiceImpl.java的deductStock()方法里——这里才是并发安全的主战场Override Transactional(rollbackFor Exception.class) public boolean deductStock(DeductRequest request) { // 步骤1查当前库存SELECT FOR UPDATE WhInventory inventory inventoryMapper.selectBySku(request.getSku()); if (inventory.getAvailableQty() request.getQuantity()) { throw new BusinessException(库存不足); } // 步骤2更新可用库存UPDATE ... SET available_qty available_qty - ? int rows inventoryMapper.updateAvailableQty( request.getSku(), request.getQuantity() ); return rows 1; }参数说明Transactional(rollbackFor Exception.class)确保整个方法原子性SELECT FOR UPDATE在InnoDB中加行锁防止并发读取旧值updateAvailableQty对应的XML里必须用update标签且SQL含WHERE sku #{sku}否则锁不住行。3.2 为什么加了Transactional还超卖看懂MyBatis的二级缓存陷阱即使加了事务如果inventoryMapper.xml里启用了二级缓存mapper namespacecom.warehouse.mapper.InventoryMapper cache evictionLRU flushInterval60000 size1024 readOnlytrue/ !-- ... -- /mapper问题就来了selectBySku查出来的库存数据被缓存下次请求直接从缓存读根本没走DB——SELECT FOR UPDATE失效解决方案删掉cache标签或改为readOnlyfalse但性能下降。更优解是在selectBySku语句上加useCachefalseselect idselectBySku resultTypeWhInventory useCachefalse SELECT * FROM wh_inventory WHERE sku #{sku} FOR UPDATE /select逻辑说明useCachefalse只禁用该查询的二级缓存不影响其他查询FOR UPDATE必须写在SQL末尾MyBatis不会自动添加。3.3 防重设计单据号生成不是UUID而是时间戳序列号组合系统里所有单据入库单、出库单、盘点单ID生成逻辑在IdGenerator.javapublic class IdGenerator { private static final String PREFIX WH; private static final AtomicInteger sequence new AtomicInteger(0); public static String generateOrderId() { String timePart LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)); int seq sequence.incrementAndGet() % 1000; // 循环0-999 return PREFIX timePart String.format(%03d, seq); } }参数说明% 1000防止单机高并发时序列号溢出String.format(%03d, seq)补零保证3位长度如001PREFIX可按业务改比如IN入库、OUT出库。4. 常见问题排查那些让开发者凌晨三点还在看日志的5个血泪坑4.1 现象登录成功后跳转到空白页浏览器控制台报Uncaught ReferenceError: Vue is not defined原因前端静态资源未正确打包。该系统前端用Vue 2.x但pom.xml里frontend-maven-plugin版本过低如1.6不支持Node.js 16。解决升级插件版本至1.12.1并指定Node版本plugin groupIdcom.github.eirslett/groupId artifactIdfrontend-maven-plugin/artifactId version1.12.1/version configuration nodeVersionv14.17.0/nodeVersion !-- 用LTS版 -- npmVersion6.14.13/npmVersion /configuration /plugin然后执行mvn clean install -P frontend重新构建前端。4.2 现象新增商品时图片上传失败日志显示java.io.FileNotFoundException: /opt/images/xxx.jpg (No such file or directory)原因application.properties里upload.path/opt/images是Linux路径Windows开发机不存在该目录。解决改成相对路径或绝对路径# Windows开发机 upload.path${user.dir}/src/main/resources/static/uploads # 或Linux生产环境 upload.path/var/www/warehouse/uploads并在启动前手动创建目录mkdir -p src/main/resources/static/uploads。4.3 现象盘点单提交后差异数据不入库数据库wh_inventory_adjust表为空原因InventoryAdjustService.java里调用adjustMapper.insertBatch()时传入的List为空但代码没判空直接执行。解决在submitAdjustment()方法开头加校验if (CollectionUtils.isEmpty(adjustments)) { log.warn(盘点差异列表为空跳过入库); return true; } adjustMapper.insertBatch(adjustments); // 此处才执行4.4 现象导出Excel时报错java.lang.NoClassDefFoundError: org/apache/poi/ss/usermodel/Workbook原因pom.xml里POI依赖范围写成scopetest/scope导致运行时缺失。解决删掉scopetest/scope保留compile范围dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version4.1.2/version !-- 删除 scopetest/scope -- /dependency4.5 现象修改商品信息后历史入库单里的商品名称没同步更新原因系统采用“快照式”设计——入库单关联的是当时商品快照wh_inbound_item表存item_name字段而非实时关联wh_item表。这是故意为之保证单据历史可追溯。解决这不是Bug是设计选择。如需实时关联需修改wh_inbound_item表结构删除item_name字段改为item_id外键并在查询时JOINwh_item。但会牺牲历史数据一致性慎改。5. 从源码到生产三个必须动手改的配置项和一个验证技巧5.1 必改配置1数据库连接池最大连接数——别用默认的10application.properties里HikariCP默认maximumPoolSize10在并发测试时如JMeter模拟50用户会频繁出现HikariPool-1 - Connection is not available。实测参数场景maximumPoolSizeconnection-timeoutidle-timeout本地开发单机2030000600000测试环境4核8G5030000600000生产环境16核32G15030000600000逻辑说明idle-timeout60000010分钟防连接空闲断开connection-timeout3000030秒避免请求长时间等待maximumPoolSize按CPU核心数×3~5估算但不超过MySQLmax_connections值默认151需SHOW VARIABLES LIKE max_connections;确认。5.2 必改配置2日志文件滚动策略——防止磁盘被撑爆默认logback-spring.xml用rollingPolicy但没设maxFileSize和maxHistory日志文件无限增长。替换为可靠配置appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/warehouse.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternlogs/warehouse.%d{yyyy-MM-dd}.%i.log/fileNamePattern timeBasedFileNamingAndTriggeringPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedFNATP maxFileSize100MB/maxFileSize /timeBasedFileNamingAndTriggeringPolicy maxHistory30/maxHistory !-- 保留30天 -- /rollingPolicy /appender参数说明maxFileSize100MB防单文件过大maxHistory30自动清理30天前日志%i支持同天多文件如warehouse.2024-06-01.0.log。5.3 必改配置3跨域配置——别让前端调用403CorsConfig.java里若只放行http://localhost:8080但前端实际跑在http://127.0.0.1:8080Chrome有时自动转会导致OPTIONS预检失败。加固写法Configuration public class CorsConfig { Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration configuration new CorsConfiguration(); configuration.setAllowedOrigins(Arrays.asList(http://localhost:8080, http://127.0.0.1:8080, http://your-domain.com)); configuration.setAllowedOrigins(Collections.singletonList(*)); // 开发期临时放开 configuration.setAllowedMethods(Arrays.asList(GET, POST, PUT, DELETE, OPTIONS)); configuration.setAllowCredentials(true); configuration.setMaxAge(3600L); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, configuration); return source; } }注意生产环境必须删掉Collections.singletonList(*)用白名单精确控制。5.4 验证技巧用一条SQL查清所有单据状态流转是否闭环系统里单据状态如入库单status字段应满足CREATED → PROCESSING → COMPLETED或CREATED → CANCELLED。用以下SQL验证是否存在“卡在中间态”的脏数据SELECT inbound as type, status, COUNT(*) as count FROM wh_inbound WHERE status NOT IN (CREATED, PROCESSING, COMPLETED, CANCELLED) GROUP BY status UNION ALL SELECT outbound as type, status, COUNT(*) as count FROM wh_outbound WHERE status NOT IN (CREATED, PROCESSING, COMPLETED, CANCELLED) GROUP BY status;执行时机每次上线前、批量导入数据后、修复BUG后必跑。如果返回任何记录说明状态机漏写了CANCELLED分支或数据库触发器失效。我习惯在交接代码时把这个SQL写进README.md的“健康检查”章节新同事第一天就能跑起来——比口头说“注意状态流转”管用十倍。希望帮到你。本文还有配套的精品资源点击获取