简介：进销存系统是中小企业数字化管理库存、采购与销售的核心工具，服装行业因款号、颜色、尺码组合成多维SKU，库存管理比通用商品更复杂。基于Java的Spring Boot技术栈凭借成熟的生态与分层架构，成为构建此类系统的常见选择，通过统一管理进货、出货与盘点单据，结合MySQL数据库的联合唯一键设计，能有效避免重复数据与超卖问题。本内容围绕一套基于Java的服装进销存系统源码，详解从技术栈识别、环境配置、数据库初始化到启动验证的完整流程，并梳理部署与二次开发中常见的端口占用、MySQL 8连接、中文乱码等避坑要点，帮助开发者快速将源码跑通并改造为可用系统。
1. 拿到「基于Java的服装进销存系统源码.zip」后，先搞清楚它到底能干什么
服装行业的库存管理比标准商品复杂一个维度：同款T恤有黑白色、S到XXL五个尺码，每个颜色尺码组合都是独立库存项，但采购、定价、吊牌又都挂在“款号”下面。基于Java的服装进销存系统源码.zip，解决的就是这种款号、颜色、尺码三维SKU下的采购入库、销售出库、盘点调拨和库存台账问题。它适合三类人：一是课程设计需要完整业务代码的在校生，二是想对照真实业务理解Spring Boot/SSM分层的Java新手，三是准备低成本管理门店库存的小团队。下面从解压开始，把这套源码从拿到手到跑起来、再改造成自用系统的完整路径拆一遍，包括那些容易让人翻车的坑。
2. 先看压包里是哪一代Java技术栈：目录结构和依赖识别
2.1 老式JSP/Servlet和Spring Boot的肉眼分辨法
这类源码包市面上常见两代技术栈，处理方式完全不同，拿到手第一步必须分辨清楚。第一代是JSP + Servlet + JDBC，多见于java课程设计案例源码，特征是项目里有webapp目录或WebContent目录，堆着一排.jsp页面，数据库连接代码写在某个工具类里，JDBC驱动jar直接放在WEB-INF/lib下。第二代是Spring Boot + MyBatis（或MyBatis-Plus）+ MySQL，特征是根目录有pom.xml，依赖由Maven集中管理，启动方式是java -jar而不是把war包丢进Tomcat。
分辨方法很简单：解压后看根目录。有pom.xml且没有webapp目录，基本是Maven工程；再打开pom.xml看有没有spring-boot-starter-parent，有就是Spring Boot。只有WebContent和.settings这类Eclipse工程文件、没有pom.xml的，是老式JSP项目。这个判断直接决定后面装什么：Spring Boot一般JDK 8起步、不用单独装Tomcat；JSP老项目除了JDK 8还要装Tomcat 8，并且要手动配置Artifacts才能导出war包。这一步做错，后面所有步骤都白费。拿到包先花三分钟看结构，别急着配环境，这是踩过一遍后的血泪经验。
老式项目连数据库的方式也值得提一句。很多课程设计源码把驱动类名写成com.mysql.jdbc.Driver，对应MySQL 5.x；如果本地装的是MySQL 8，启动时多半报“Public Key Retrieval is not allowed”或SSL连接错误，这问题在第五章单独展开。判断技术栈的意义就在于提前知道该准备哪个版本的JDK、MySQL和Tomcat，避免环境装到一半才发现不匹配。
2.2 pom.xml里的关键依赖和版本陷阱
确定是Maven工程后，pom.xml要重点看四个地方。第一是spring-boot-starter-parent版本号。Spring Boot 2.x配JDK 8最稳，3.x要求JDK 17，并且javax.servlet包迁移成了jakarta.servlet，老代码可能直接编译不过。如果机器只有JDK 17而源码是2.x，一般还能跑；反过来源码3.x用JDK 8会立刻报错。
第二是ORM选型。mybatis-spring-boot-starter和mybatis-plus-boot-starter二者写法差异很大：前者mapper XML要自己写完整SQL，后者内置单表CRUD，改代码时思路完全不一样。如果源码用的是MyBatis-Plus，实体类上通常有@TableName注解，一眼就能认出。
第三是MySQL驱动坐标。mysql-connector-java 5.x对应MySQL 5.7，8.x对应MySQL 8.0，版本不匹配会在启动阶段抛奇怪的连接异常。第四是lombok。如果pom里有lombok依赖而IDE没装插件，实体类全部报红，很多人误以为源码坏了，其实是插件问题，装完就好。
另一个版本陷阱值得单独说：Spring Boot 2.4之后配置文件加载方式有调整，有些老源码在application.yml里用的是spring.datasource.url，有些是自定义前缀如erp.datasource.url，后者改了spring前缀的配置根本不生效。改配置前先把application.yml从头读一遍，确认读取配置的类是@Value注入还是@ConfigurationProperties前缀绑定，再动手改，否则改完重启还是一样报错。
2.3 从src目录反推业务模块划分
业务模块通常能从包结构直接看出来。常见布局是com.xxx.erp下分controller、service、mapper（或dao）、entity、common。entity层的表对应关系是核心：Goods/Product/Spu是商品主档，Sku是颜色尺码明细，Stock/Inventory是库存，PurchaseOrder是采购单，SaleOrder是销售单，StockCheck是盘点单。看到这几个实体，整个系统业务边界就清晰了。
反过来，如果entity里只有一个Goods表和一张库存表、没有Sku实体，那这份源码其实是通用进销存硬贴上“服装”标签，只能管到款号级别，管不到颜色尺码。这种源码不建议投入，后面改造成本比你重新写一套还高。我一般会先点开entity目录确认有没有sku或近似结构，再决定是否继续部署，这一步花两分钟，能省掉一整天的无效劳动。
mybatis的mapper XML一般在resources/mapper或resources/mybatis下，命名与Dao接口一一对应。看库存扣减的SQL是UPDATE还是先SELECT再UPDATE，能判断并发处理水平。进销存是高频读写场景，直接UPDATE stock SET quantity = quantity - #{qty}比先读后写安全得多，后面二次开发时保持这个习惯就行。
3. 从zip到跑起来：环境配置、数据库初始化和启动命令
3.1 解压阶段的两个小事：中文乱码和zip伪加密
解压源码包，优先用7-Zip或Bandizip，别用Windows系统自带的“全部解压”。压缩包里的文件目录、注释信息很多是GBK编码，Windows自带解压对中文文件名的处理容易解出一堆乱码文件名。虽然不影响.java文件内容，但后面看日志、找路径时对不上会非常痛苦。
zip伪加密这个坑，在论坛和网盘转手的源码包里很常见：解压时提示要密码，但发布者其实没设密；或者压缩包打开时右侧显示加密标志，文件列表里名字却没有星号。这种是zip伪加密，通过修改加密标志位骗过解压软件。判断方法是用7-Zip打开看文件列表属性，名称带星号是真加密，不带星号却要求密码的，换Bandizip打开一般能直接进去。这比去找各种“zip密码移除”工具可靠得多，因为伪加密根本不需要破解——工具还没识别出来，人先看出来了。
解压后的路径也要注意：整个源码目录不要放在带空格或中文目录下，比如“C:\Users\张三 下载\新建文件夹 (2)”这种路径。Maven在编译时偶尔会因为路径编码抛些莫名其妙的错误，放到D:\erp\fashion这种纯英文短路径，能省掉好多没必要的玄学问题。
3.2 JDK与MySQL环境：版本对不上，启动必翻车
这类基于Java的源码绝大多数要求JDK 8，少数用到新特性才要JDK 11+。装好JDK后必须配java环境变量配置：JAVA_HOME指向JDK安装根目录，PATH里加%JAVA_HOME%\bin，CLASSPATH不是必须的（JDK 1.5以后不用手动配）。配完在命令行执行java -version验证。遇到“不是内部或外部命令”，多半是PATH没加上去或者没重开命令行窗口——环境变量改了必须新开终端才生效。如果想在IDEA里跑，还要在Project Structure里把SDK路径指到对应的JDK安装目录，不然IDEA会用自带JRE，版本可能不对。
MySQL这边要明确版本。源码里驱动是5.x，本地装MySQL 8，启动时大概率报SSL或认证插件相关错误；驱动8.x连MySQL 5.7基本兼容但要注意时区参数。建议按源码自带驱动版本来选数据库：驱动5.x用MySQL 5.7，驱动8.x用MySQL 8.0。数据库安装完成后，建库必须指定utf8mb4字符集，否则后面存中文全是问号。命令行操作如下：
# 建库：字符集统一用 utf8mb4，排序规则用通用不区分大小写 mysql -uroot -p > CREATE DATABASE fashion_erp DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; > exit; # 导入源码包自带的初始化脚本，脚本一般在 db/ 或 sql/ 目录下 mysql -uroot -p fashion_erp < db/fashion_erp.sql参数说明：utf8mb4是MySQL 8的默认字符集，比utf8多支持emoji和生僻字，服装商品名称里带特殊符号不会乱码；fashion_erp是数据库名，要和后面配置文件里的库名保持一致。导入脚本时如果包里只有表结构没有测试数据，后面登录系统看到空页面不要慌，先进数据库手插一条商品再验证界面。
3.3 改数据库连接配置：以Spring Boot为例
Spring Boot项目改一处地方：src/main/resources/application.yml（或application.properties）。把数据库名称、用户名、密码改成你自己的，其他保持源码原样。下面这段是最常见的配置样式：
spring: datasource: url: jdbc:mysql://localhost:3306/fashion_erp?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver逐个参数说明：jdbc:mysql://localhost:3306/fashion_erp是数据库地址和库名；useUnicode=true和characterEncoding=utf8是防中文乱码的关键参数，加了这两项页面和存储层的中文才能对齐；serverTimezone=Asia/Shanghai解决MySQL 8的时区报错，不写的话驱动拿服务器默认时区和数据库时区比对，轻则数据差8小时，重则直接连不上；useSSL=false关掉SSL握手，本地开发能明显加快连接速度；driver-class-name在MySQL 5.x驱动下要写成com.mysql.jdbc.Driver（不带cj），8.x下写成com.mysql.cj.jdbc.Driver，这两个类名不能混用。
老式JSP项目不在这里改，而是在连接工具类（通常叫DBUtil或JDBCUtil）里改Connection字符串，或者在一个db.properties文件里。改完编译前留意一件事：密码里如果包含@、#、&这类字符，在JDBC URL里要转义，@写成%40，否则驱动会把@后面的内容当主机名解析，报“Unknown host”错误。这个坑帮人排错时见过不下三次，每次都卡半小时起步。
3.4 打包运行与浏览器验证
依赖由Maven自动下载，第一次打包时间会很长，要把所有依赖jar从中央仓库拉到本地仓库，遇到网络慢就按第五章的办法处理。打包和启动命令如下：
# 跳过单元测试打包，产物在 target/ 下 mvn clean package -DskipTests # 启动，控制台看到 Tomcat started 表示成功 java -jar target/fashion-erp-1.0.0.jar # 指定端口启动，适合8080被占的情况 java -jar target/fashion-erp-1.0.0.jar --server.port=8081-DskipTests会同时跳过测试编译和运行，节省不少时间；fashion-erp是打包生成的jar名，具体名字看target目录里实际产物，源码没配finalName的话默认是“项目名-版本号.jar”。如果源码是war包结构，部署方式不同：把war文件丢进Tomcat的webapps目录，启动Tomcat后自动解压，访问路径要带项目名，比如http://localhost:8080/fashion-erp/。
验证是否跑通，打开浏览器访问http://localhost:8080，能看到登录页基本成了。如果页面打不开，先去控制台看启动日志，找到“Tomcat started on port(s): 8080”这行说明应用已经起来，打不开是端口或访问路径问题；没有这行说明启动中途报错，把异常栈第一行贴到搜索引擎，比盯着代码猜快得多。常见问题集中在数据库连接、端口占用、MyBatis映射缺失三类，下一章单独列避坑清单。
4. 服装进销存的核心业务模型：款号、颜色、尺码三维库存
4.1 为什么通用进销存的商品表在服装行业不够用
通用进销存系统里，商品表一行就是一个库存单位：商品名称、条码、进价、售价、库存量。这套模型管螺丝、管标准件没问题，但管服装立刻出问题。同一款T恤有黑白色、五个尺码，按通用模型要么建十行重复商品记录，要么一行库存里放个总数。前者让采购和销售单据操作极度繁琐，后者的后果是系统显示“这款T恤还有80件”，实际黑色M码早断货了，货全积压在白色XXL上。
服装行业必须把“款”和“SKU”分开建模。款是展示和采购单位，对应吊牌价、图片、厚薄信息，挂在商品主档下面；SKU是款号+颜色+尺码组合出来的叶子节点，每次进销存都对着SKU的库存数量做增减。基于Java的服装进销存系统源码，只要entity层有spu、sku、stock三层面的表，模型就是对的，后面做报表、扩展多仓库都有基础。
4.2 SKU表设计：唯一键怎么建
到数据库层，多色多码不再用一张宽表做列，而是用行记录加联合索引：
CREATE TABLE `product_sku` ( `sku_id` bigint NOT NULL AUTO_INCREMENT COMMENT 'SKU主键', `style_no` varchar(50) NOT NULL COMMENT '款号，如 FS-2024-001', `color_name` varchar(30) NOT NULL COMMENT '颜色名，如 黑色', `size_code` varchar(10) NOT NULL COMMENT '尺码，如 M', `barcode` varchar(32) DEFAULT NULL COMMENT '条码，可按款色码规则生成', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1启用 0停用', PRIMARY KEY (`sku_id`), UNIQUE KEY `uk_style_color_size` (`style_no`, `color_name`, `size_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='服装SKU表';唯一键建在三列联合上，这是整张表最关键的设计：同一款、同一色、同一码物理上只允许一条记录。开单时按款号往明细里加颜色尺码，程序通过唯一键查到对应sku_id再做库存增减。如果没有这个唯一键，数据录入一重复库存账立刻对不上，两个SKU各记一半库存，查半天也查不出错在哪里。
库存表围绕sku_id和仓库维度展开：每条记录是“某仓库里某SKU的一堆数量”，字段最少要有sku_id、warehouse_id、quantity（账面库存）、locked_quantity（锁定/占用）四件套。锁定数是电商订单生成时先占库存、付款后正式扣库存的常见做法，只有quantity减locked_quantity得到的可用量才参与可售判断。源码里如果只有quantity没有locked_column，后续接电商订单时优先补上这个字段。
4.3 单据流：采购单、销售单、盘点单怎么走
进销存不是直接改库存表，而是通过单据驱动库存变动。采购入库单流程：创建采购单、审核、把每条明细的SKU库存加上；销售出库单流程：创建销售单、校验库存充足、扣减SKU库存、记录销售流水。每条库存变动都能追溯到一张单据，查账时“为什么库存对不上”才能顺着单据找到业务操作的时间和操作人。
如果没有单据只有库存流水，查账会非常痛苦：你只知道库存少了十件，但不知道是卖了、盘亏了还是录错单。所以哪怕源码里能用，也建议保留“单据-明细-库存变动”三层结构。很多收录的源码把库存扣减写在Service层，逻辑类似这样：
// 销售出库：先更新库存，再写流水，保证两步在同一事务里 @Transactional(rollbackFor = Exception.class) public void saleOut(List<SaleItem> items) { for (SaleItem item : items) { // 条件更新：quantity >= 扣减数才更新成功，天然防超卖 int rows = stockMapper.deduct(item.getSkuId(), item.getWarehouseId(), item.getQty()); if (rows == 0) { throw new BizException("库存不足：" + item.getSkuId()); } saleRecordMapper.insert(item); } }这段代码有三点值得学：@Transactional保证扣库存和写流水在同一事务，中间抛异常整个回滚，不会出现流水写了库存没扣；deduct用条件更新，比先SELECT再判断再UPDATE少了竞态窗口，两个人同时下单买最后一件不会超卖；库存不足直接抛业务异常结束事务，调用方收到明确错误。这三个习惯二次开发时务必保留，很多粗暴改法把这三件套拆了，账永远对不平。
对应的SQL长这样，注意WHERE条件里的quantity >= #{qty}：
UPDATE stock SET quantity = quantity - #{qty} WHERE sku_id = #{skuId} AND warehouse_id = #{warehouseId} AND quantity >= #{qty}如果影响行数为0，说明库存不足，这个判断不能省略。有些源码把这里写成先SELECT再UPDATE，单机跑没问题，一上并发就超卖，属于必改点。盘点单的逻辑则是反着来：盘点数减去账面数得到差异，走盘盈盘亏两条分支，把库存调平，同时生成差异记录，方便后续追责。
5. 部署与改代码时最常踩的五个坑：现象、原因、解决
5.1 端口被占用：启动一半报 Address already in use
现象：启动日志打到一半，出现APPLICATION FAILED TO START，下面跟着Port 8080 was already in use，然后进程退出。
原因：本机已有程序占用8080。最常见的是之前跑过的Java进程没杀掉，或者IDE的嵌入式Tomcat在后台挂着。
解决：先查占用再决定杀进程还是换端口。Windows下用netstat -ano | findstr 8080查PID，taskkill /F /PID 杀掉；也可以不改代码直接换端口启动：java -jar xxx.jar --server.port=8081。选后者要留意：如果前端页面写死了8080的API地址，换端口后前端请求会失败，这种情况还是杀进程干净。macOS/Linux下用lsof -i:8080查进程，kill -9 收尾。
5.2 MySQL 8连接报 Public Key Retrieval is not allowed
现象：启动时数据源初始化失败，日志关键字是Public Key Retrieval is not allowed for user，后面跟一串SSL/认证相关异常。
原因：MySQL 8默认认证插件是caching_sha2_password，驱动在非SSL连接下首次连接需要从服务器拿公钥加密密码，而驱动8.x默认allowPublicKeyRetrieval=false，拒绝执行公钥获取，于是连接失败。
解决：两种方案。一是在JDBC URL后加参数allowPublicKeyRetrieval=true，本地开发最省事；二是把数据库用户认证插件改回mysql_native_password：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';。线上环境我更倾向改用户插件，避免每次连接都多一次公钥交换；本地开发用第一种，改一行配置就能起来。
5.3 页面和导出文件中文乱码：三处编码要统一
现象：页面商品名称显示问号或方格，导出的CSV/Excel打开乱码；后台菜单英文正常、中文数据乱。
原因：乱码几乎都是编码不一致导致，常见有四种组合——数据库建库不是utf8mb4、JDBC URL没带characterEncoding=utf8、页面HTTP响应头没指定UTF-8、过滤器没对请求体设置编码。任何一个环节断掉，中文就过不来。
解决：按顺序统一。数据库和表都改用utf8mb4；连接串加characterEncoding；检查web.xml或配置类里有没有CharacterEncodingFilter，没有就补一个setEncoding("UTF-8")；页面是JSP的话，确保pageEncoding="UTF-8"和Content-Type="text/html; charset=UTF-8"同时存在。改完重启还乱，逐步排查：先看数据库里存的对不对，再看传到页面的数据对不对，哪一层断了修哪层，别一来就到处改。
5.4 Maven依赖拉不下来：中央仓库太慢或直接超时
现象：mvn package卡在Downloading处很长时间，最后报Could not resolve dependencies或transfer failed，CPU空转、进度条不走。
原因：Maven默认指向中央仓库repo.maven.apache.org，这个地址在部分网络环境下速度不稳定，不是源码问题，是网络问题。
解决：修改Maven安装目录conf下的settings.xml，加入阿里云镜像。注意先确认Maven是不是IDEA自带的——IDEA自带Maven时settings.xml在IDEA安装目录或用户目录.m2下，改的是那份才生效。配置如下：
<mirrors> <mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/central</url> </mirror> </mirrors>mirrorOf写central表示只对中央仓库生效，公司有Nexus私服的话写*并把URL换成私服地址。改完重新执行mvn clean package，第一次拉取还是慢，但比之前稳定。同时把IDEA的Maven设置里“Always update snapshots”关掉，否则每次构建都强制联网检查快照版本，整个耗时会被拖长。
5.5 驱动的类名写错：ClassNotFoundException 与 NoClassDefFoundError
现象：运行阶段报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver，或连带一堆NoClassDefFoundError堆栈。
原因：项目里MySQL驱动版本和配置里的driver-class-name不匹配。5.x驱动类名是com.mysql.jdbc.Driver，8.x是com.mysql.cj.jdbc.Driver。源码pom升级过驱动但配置没同步改，或者配置写了新版类名但实际依赖还是老驱动，都会出现这种错位。
解决：打开pom.xml确认mysql-connector版本，再用对应类名。快速判断法：在本地仓库jar包的META-INF/services/java.sql.Driver文件里，写的类名就是当前版本要用的。我每次迁移老项目都先查这个，比看日志猜省时间。改完配置重启，连接日志不报ClassNotFound就过了。
6. 从demo改成能用的系统：三个低成本进阶方向
源码跑起来只是起点，真正的价值在于按自己门店或仓库的流程改造成可用系统。我给三个性价比最高的方向。
第一是加条码和扫码录入。给product_sku表补barcode字段，用款号+颜色+尺码拼规则生成，比如FS2024-001-BK-M，采购入库和销售开单页各加一个输入框监听回车事件，扫码枪扫一下自动带出SKU。扫码枪本质是键盘输入设备，前端不用接额外硬件SDK，一个监听键盘事件就能兼容绝大多数型号。改完录单速度能翻倍，这是服装门店最直观的提效点。
第二是库存预警报表。在报表模块加一个低于安全库存的查询，SQL是按款色码分组统计当前库存，再和预警阈值对比：
SELECT s.style_no, s.color_name, s.size_code, st.quantity, p.safety_stock FROM stock st JOIN product_sku s ON st.sku_id = s.sku_id JOIN product_spu p ON s.style_no = p.style_no WHERE st.warehouse_id = #{warehouseId} AND st.quantity < p.safety_stock ORDER BY st.quantity ASC这个报表配合每天早上跑一次，断码补货的节奏就出来了。safety_stock字段如果原表没有，ALTER TABLE product_spu ADD COLUMN safety_stock int DEFAULT 10补上，迁移成本很低。注意这里的JOIN关系要和你源码里的实际表名对上，字段对不齐就改列名。
第三个方向是多仓库支持。服装批发常有总仓加门店仓，库存表加warehouse_id，进出库单加调拨类型，调拨单实现在两个仓库之间先减后加。这个改动涉及表和单据类型两块，工作量中等，但做完整个系统适用面就广了，后面接电商、接线下店都在这套框架上扩展。
验证改造是否成功，我的习惯是造一批能对得上账的测试数据：手工录入三个款式、每款两个颜色、五个尺码，共30个SKU，然后做10笔采购入库、30笔销售出库、3笔盘点，每天晚上对一遍库存台账与实际剩余数量。连续跑一周数据不差，这套改造才算稳了。做这类系统的教训就一句话：先让库存账对得上，再谈报表和优化，账对不上的进销存比没有系统还可怕。希望这篇拆解能帮你少填几个坑，把源码尽快变成能用、敢用的系统。
本文还有配套的精品资源，点击获取
