基于SpringBoot+Vue+MyBatis+MySQL的服装生产管理系统

前阵子整理了一套基于SpringBoot+Vue的服装生产管理系统源码，春节前刚好利用这套骨架给一家做针织衫的中小型服装厂做过信息化改造摸底。整套系统跑下来，我觉得它特别适合两类人：一类是刚入行Java后端、想找一个能完整跑通的实战项目练手的朋友；另一类是正在准备毕业设计、需要一套前后端分离管理系统作为基础再二次开发的同学。服装生产管理这个方向，市面上能直接跑的源码本来就少，能覆盖从订单、面料库存、生产计划到成品交付全链条的更少，这套系统恰好把这条业务线串了起来。

技术栈就是标题里那四样：SpringBoot做后端服务，Vue做管理后台页面，MyBatis负责数据库操作，MySQL存储业务数据。我见过不少人一听到“管理系统”就觉得千篇一律，无非是CRUD。但放到服装生产这个场景里，情况完全不同：一个款号下面有多个颜色，每个颜色又分S/M/L/XL多个尺码，订单明细天然就是三维结构；面料有米数、匹数两种计量单位，辅料有纽扣、拉链、洗唛，库存台账得按物料类别分开管；生产排产要兼顾交期和产能。这些业务细节决定了它不是一个普通的增删改查项目，而是一个有真实建模难度的管理系统。下面我会从技术选型、模块设计、数据库建模、MyBatis使用、Vue前端实现、本地部署验证到二次开发，逐层把这套系统讲透。

1. 这套系统到底解决了服装厂的哪些实际痛点

1.1 服装生产的业务链条与信息化难点

在聊代码之前，先得明白服装厂日常是怎么运转的。一家典型的中小型服装厂，接单之后要做的第一件事不是直接排产，而是先“拆单”：业务员把客户下的订单拆成款号、颜色、尺码三个维度，不同颜色不同尺码的数量都不同。接下来是查面料库存，面料够不够，辅料缺不缺，如果不够就要下采购单。然后车间排产，裁剪、车缝、后整包装，每道工序都可能涉及不同班组。最后成品入库，按客户交期发货。

这个链条里最痛的点有三个：一是订单拆解靠Excel，款式多的时候一个订单拆出几十上百行，容易错；二是面料辅料的库存全靠老员工脑子记，经常出现面料都发出去了才发现不够用；三是生产进度不透明，业务员问交期，车间主任只能凭经验说“大概下周”。信息化要解决的，就是把这张业务网落到数据库表里，让每个环节的状态都能被跟踪。这套系统的价值就在于此，它不是只做一个订单登记表，而是把订单、BOM、库存、工单、报工、出货串成了完整闭环。

1.2 为什么选前后端分离而不是传统JSP

早些年做这类管理系统，常见方案是Spring MVC + JSP模板，页面由后端渲染。但如果你做过真正的工厂项目就会发现，传统JSP方案在权限控制、页面交互、多人协作开发上都很别扭。比如订单拆解页面要频繁联动选择“款号确认颜色、颜色确认尺码”，这种动态交互用JSP写，要么疯狂刷新页面，要么堆大量jQuery代码，后期维护成本极高。而Vue这种前后端分离的做法，页面交互在前端独立完成，后端只提供JSON接口，天然适合管理后台这种多表单、多联动的场景。

对学习者来说，前后端分离还有一个实际好处：调试时后端可以用Postman单独测接口，前端可以单独调样式，不用每次改个按钮颜色都要把整个项目重启一遍。这也是我把前端独立成一个工程的原因。

1.3 这套源码适合谁，能学到什么

如果你去看这套源码的完整目录，会发现它覆盖了一个商用级管理系统的标配：统一返回结果封装、全局异常处理、角色权限校验、分页查询、批量插入、事务管理、多条件组合查询、前端动态路由、axios请求封装、SKU联动选择组件。这些东西单独拆出来，每一个都是面试常问的点，组合在一起又是一个能直接演示的项目。

我特别建议刚学完SpringBoot基础的人，不要急着去啃微服务和分布式，先把这种单体管理系统吃透。因为管理系统的本质是“业务建模 + 数据流转”，你把服装生产这条线彻底理解清楚，以后不管换什么行业的管理系统，思路都是相通的。

2. 技术选型背后的取舍：SpringBoot+Vue+MyBatis+MySQL四个组件怎么搭才不别扭

2.1 SpringBoot选型：启动即用的微服务底座

SpringBoot在2025年依然是中小型企业后端项目的首选，没有之一。它最大的价值是解决了Spring框架最烦人的配置问题，内嵌Tomcat、自动装配、约定大于配置这三板斧，让开发者把精力集中在业务代码上。这套系统用的Spring Boot 2.7.x版本，属于2.x系列里最成熟的版本，兼容性极好，不会出现高版本因Spring Security配置变化带来的无谓折腾。

关于版本我要多说一句。热词里我看到很多人搜“springboot版本太高”的问题，这个确实很常见。很多开源项目是基于Spring Boot 2.x写的，如果你直接换成Spring Boot 3.x，依赖里涉及javax包名的类会全部报错，因为3.x把javax换成了jakarta。所以我自己在部署老项目或者二次开发别人的源码时，第一件事就是确认Spring Boot版本，除非必要，绝不轻易升大版本。

2.2 MyBatis在服装BOM多变场景下的优势

为什么不用MyBatis-Plus，也不用JPA，而是选MyBatis？如果你是看过源码的人应该能理解，服装生产系统的SQL复杂度不在于单表增删改查，而在于多条件动态组合。比如生产排产查询，可能同时传入交期范围、款号、状态、车间主任；订单明细查询，需要按款号、颜色、状态过滤，还要联查客户名称。这种场景用固定SQL写会非常痛苦，而MyBatis的XML动态SQL对这种“查询条件个数不确定”的需求几乎是量身定做的。

另外，MyBatis对复杂报表查询的掌控力也更强。后面做面料出入库汇总、订单完成进度统计时，需要写联表子查询，XML里可以直接写出完整的SQL，而JPA的Criteria API写复杂查询时简直要人命。所以这套系统坚持用XML文件管理SQL，保持了最大的灵活度。

2.3 MySQL与Vue：数据存储和交互层的现实选择

MySQL在这套系统里没什么悬念。服装生产管理系统的数据量撑死几十万条，单机MySQL完全够用，社区版免费，Navicat一连就能看数据，新手学习成本最低。说实话，很多项目把大量精力花在分布式数据库方案上，最后发现实际业务量连MySQL的零头都用不到。我这里给一个小建议：装MySQL 8.x就行，尽量别再用5.7这种老版本了，8.0的窗口函数写统计报表非常方便。

Vue部分用的是Vue 2的语法，配合Element UI组件库。你可能要问，现在都在推Vue 3，为什么用Vue 2？因为这套系统的定位是稳定、易上手、生态成熟。目前大量企业后台项目还是在Vue 2 + Element UI，网上资料最多，任何组件使用问题都能搜到解决方案。你要是熟悉Vue 3，后续自己升级改造也不难，核心路由和状态管理的思路是一样的。

2.4 源码目录结构的职责划分

拿到源码之后，你会看到两个顶层目录，一个是后端工程，一个是前端工程。看懂目录结构是读懂代码的第一步：

fms-backend/ ├── pom.xml └── src/main/ ├── java/com/fms/ │ ├── common/ // 统一返回Result、分页PageResult、全局异常 │ ├── config/ // WebConfig、跨域配置、MyBatis配置 │ ├── controller/ // OrderController、StockController、PlanController │ ├── service/ // 业务接口与实现，事务主要在这里控制 │ ├── mapper/ // MyBatis的Mapper接口 │ ├── entity/ // 数据库表对应的实体类 │ └── dto/vo/ // 请求参数对象和视图对象 └── resources/ ├── application.yml └── mapper/ // OrderMapper.xml、StockRecordMapper.xml等 fms-frontend/ ├── package.json └── src/ ├── api/ // 按模块封装的axios请求 ├── router/ // 路由表与动态路由逻辑 ├── store/ // Vuex状态管理 ├── styles/ // 全局样式 ├── utils/ // request.js统一封装 ├── components/ // SkuSelector、OrderDialog等组件 └── views/ // 订单管理、库存管理、生产计划等页面

后端是典型的Controller-Service-Mapper三层结构，Controller只做参数接收和结果包装，Service放业务逻辑和事务注解，Mapper负责SQL和数据库交互。前端按页面模块分目录，每个业务对象对应一个API文件，比如api/order.js里集中管理订单相关接口。看懂这个结构，你找任何功能点都知道去哪找代码。

3. 核心模块设计：从订单到交货的完整业务闭环

3.1 订单管理：款号/色号/尺码的三级模型

服装订单和其它行业订单最大的不同，在于多了一层“款式维度”。一个订单里有不同款号，每个款号有不同的颜色，每个颜色有不同的尺码及对应数量。如果按普通订单设计，每条明细存一个商品ID和一个数量，是表达不了这种结构的。这套系统用两张表解决：fms_order存订单头部的公共信息（订单号、客户、总数量、交货日期、状态），fms_order_item存订单明细，每行数据包含订单ID、款号、色号、尺码、数量。

CREATE TABLE fms_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单号', customer_id BIGINT NOT NULL COMMENT '客户ID', total_quantity INT NOT NULL COMMENT '总数量', delivery_date DATE NOT NULL COMMENT '交货日期', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态:0草稿,1已确认,2已排产,3生产中,4已完工,5已发货,6已关闭', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) ); CREATE TABLE fms_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, style_id BIGINT NOT NULL COMMENT '款号ID', color_code VARCHAR(32) NOT NULL COMMENT '色号', size_code VARCHAR(16) NOT NULL COMMENT '尺码', quantity INT NOT NULL COMMENT '数量', KEY idx_order (order_id), KEY idx_style (style_id) );

这种设计的好处是，前端页面可以做成三层联动选择：先选款号，系统自动带出该款号支持的颜色列表；选了颜色，再带出尺码列表；最终填数量。每一层都有数据库支撑，不会出现业务员随意组合出无效款色码的情况。我做这个模块时特别推荐使用Element UI的级联选择器，数据格式直接由接口返回，前端几乎不用写多余逻辑。

3.2 面料辅料库存：批次、领料与安全库存预警

面料和辅料的库存管理，是服装管理系统最容易做砸的地方。如果只做一个简单的库存数字表，每次出入库直接改数量，时间一长账面和实际就对不上了。原因很简单，采购入库的批次不同、价格不同，领料出库要按先进先出或指定批次来扣减。所以这套系统设计了fms_stock作为实时库存表，fms_stock_record作为流水表，任何数量的变动都先写流水，再更新库存表。

我把关键逻辑简化成一段伪代码，更容易理解：

1. 领料单审核通过 2. 遍历领料明细，逐条扣减fms_stock数量 3. 同事务里向fms_stock_record插入“出库”流水 4. 扣减后检查fms_stock.quantity是否小于安全库存 5. 小于则生成预警记录，后台“库存预警”页面可见

这样做最直接的收益是问题可追溯。比如某天仓库发现面料短了10米，你可以通过流水表筛选出对应仓库该料号近期所有的出库记录，逐条核对，而不是面对一个被改得面目全非的库存数字无从下手。我给这套系统加安全库存阈值字段后，面料采购员的工作方式发生了很大变化：她不用每天手动翻台账，系统在首页待办里直接提示哪些料号低于安全线，她只需要按预警列表生成采购单就行。

3.3 生产计划与车间进度：排产、派工与完工上报

生产模块在最开始设计时只有一张fms_production_order工单表，记录工单号、订单号、计划开工日期、计划完工日期和状态。但实际跑起来你会发现，车间的行为是“裁剪、车缝、包装”逐道工序推进的，光有工单状态没法表达当前卡在哪道工序。后来我把生产过程拆成了两个环节：排产（生成工单并确定裁剪日期）和报工（记录每日各工序完成数量）。

报工这块用fms_work_report记录，每个班组在一天结束时，可填写各工单当前工序的实际完成数量。不用做到MES那种精细到工人级别的录入，那对中小型工厂负担太重，只要按“工单 + 工序 + 数量”汇总，管理层就已经能清楚看到哪个工单进度正常、哪个可能延期。后台生产看板页面把这些数字按日期汇总，配合订单交期，逾期风险一眼就能看出来。

3.4 成品入出库与交付追踪：状态机的流转设计

管理系统里最忌讳状态字段随意乱改。我见过不少项目，订单状态在数据库里被不同接口写成五花八门的数字，最后统计口径都对不齐。为避免这个问题，这套系统把所有核心业务单据的状态流转收敛到Service层统一处理。以订单为例，它的状态流转是：

草稿 -> 已确认 -> 已排产 -> 生产中 -> 已完工 -> 已发货 -> 已关闭

每个状态转换都对应一个独立的方法名，比如confirmOrder、scheduleOrder、completeOrder，方法内部先校验当前状态是否允许变更，再执行状态更新。订单已发货后，再想回退到生产中，Service层会直接抛异常。这种做法在管理系统的业务一致性上作用很大，尤其第后期接统计报表时，状态字段永远是可控的、可预料的。

4. 数据库表设计的心得：二十多张表怎么串成一张网

4.1 主数据表：服装款式、BOM和客户供应商

主数据是管理系统的“地基”，这套系统里最核心的主数据表是fms_style（服装款式）和fms_style_bom（款式物料清单）。fms_style存款号、品名、品类（T恤、裤子、外套等）、季节（春/夏/秋/冬）、参考售价等基本信息。真正有设计含量的是fms_style_bom，它记录生产一件该款衣服需要哪些物料、每种多少用量。举个例子，一件针织长袖款可能需要：

• 面料：1.6米
• 里料：0.8米
• 纽扣：5颗
• 拉链：1条
• 洗唛：1张

BOM表里就是这些行数据：物料ID、单件用量、单位和损耗率。生产排产时，系统按订单数量乘以BOM用量，自动算出原材料需求，再对比现有库存，自动生成采购建议。这一步是整个系统最提效的功能，也是面试时最值得讲的亮点。

客户和供应商表比较常规，重点是要做好和订单、采购单的关联索引，后面统计“这个客户今年下了多少单”就靠这个关联。

4.2 业务单据表：订单、生产工单、出入库单的主外键关系

我把这套系统的核心业务表关系拉出来说，你会发现它是一个典型的“单据 + 明细”模式：

主表存单据的公共信息和状态，明细表存具体物料、款色码和数量。这种设计有两个好处：一是查询单张单据时，连表简单清晰；二是统计时可以直接对明细表做聚合，性能更好。我用EXPLAIN测过，只要给外键字段加上索引，几十万数据量下的联表查询基本都在毫秒级，完全够用。

4.3 库存流水与对账：用流水表保证数据可追溯

第3章我提到过库存流水表，这里再展开说说它是怎么设计的。fms_stock_record里有一个biz_type字段，标识这笔流水来自采购入库、生产领料、退货入库还是销售出库；还有一个biz_no字段，存对应的业务单号。比如领料单号是PL20250113-001，那么该单据产生所有出库流水里都带着这个单号。这样对账时就非常方便：拿库存的期初数，加上所有入库流水，减去所有出库流水，得到的结果应该等于实时库存表的当前数。如果不等，说明某处有bug或人为改过数据，直接按流水定位。

线上系统我强烈建议保留这套流水机制。库存表可以被业务操作反复update，流水表只做insert，两者配合既保证性能又保证可追溯。

4.4 初始化数据的顺序与SQL脚本踩坑

很多小伙伴拿到源码后第一步就想直接启动，结果往往卡在初始化数据库上。这套系统的SQL脚本不是一次性导入就完事的，它有严格的顺序要求：先建数据库和主数据表（用户、客户、供应商、物料、款式、BOM），再建业务表（订单、采购、工单、出入库、出货），最后插入演示用的基础数据。顺序乱了，外键和菜单权限关联数据就会报错。

另外一个常见的坑是MySQL 8的默认字符集问题。在低版本MySQL里，数据库默认latin1编码，导入中文数据会变成乱码。所以建库语句里一定要明确指定DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci。如果你导入后发现中文变问号，十有八九是这里出了问题。用Navicat导入脚本时，也记得把连接编码切到utf8mb4。

5. MyBatis在这一项目里的正确用法：动态SQL、批量操作与缓存

5.1 动态SQL处理多条件组合查询

管理系统后台，几乎每个列表页都会有一个“筛选区”：输入订单号、选择状态、选择客户、选交货日期范围，然后点查询。这些条件用户不会每次都全填，所以SQL必须是动态拼装的。MyBatis的<where>加<if>标签就是为这个场景设计的。比如订单分页查询的核心SQL：

<select id="selectOrderPage" resultType="com.fms.entity.Order"> SELECT * FROM fms_order <where> <if test="orderNo != null and orderNo != ''"> AND order_no LIKE CONCAT('%', #{orderNo}, '%') </if> <if test="status != null"> AND status = #{status} </if> <if test="customerId != null"> AND customer_id = #{customerId} </if> <if test="startDate != null"> AND delivery_date &gt;= #{startDate} </if> <if test="endDate != null"> AND delivery_date &lt;= #{endDate} </if> </where> ORDER BY create_time DESC </select>

<where>标签会自动处理第一个条件前的AND，条件全为空时它也不会生成多余的where关键字。这套写法在面试里也经常被问到，“MyBatis动态SQL有哪些标签、各自用途是什么”这种面试题，你把这段XML逻辑讲清楚，基本就过关了。

5.2 批量插入提升工单明细的写入效率

订单明细和BOM明细都有批量保存的需求。比如一个生产工单要生成几十条报工计划，如果用循环单条insert，不仅慢，而且要写几十次数据库交互。MyBatis的<foreach>标签可以把一个List参数拼成一条多值插入语句：

<insert id="batchInsertBomItems"> INSERT INTO fms_style_bom (style_id, material_id, quantity, loss_rate, unit) VALUES <foreach collection="list" item="item" separator=","> (#{item.styleId}, #{item.materialId}, #{item.quantity}, #{item.lossRate}, #{item.unit}) </foreach> </insert>

使用批量插入要注意两点。第一，MySQL默认的max_allowed_packet限制，一次插入的数据量太大时会报错，常规做法是控制单批在500条以内。第二，前端传来的数据需要校验后统一放入List，不能一条一条调用insert，否则就失去了批量意义。实测下来，BOM明细50条左右的数据，一条SQL就完成插入，速度提升非常明显。

5.3 缓存与事务：哪些地方能开缓存

MyBatis的一级缓存是SqlSession级别的，二级缓存是Mapper级别的。这片代码里我没有默认开启二级缓存，原因是管理系统的数据实时性要求高，任何订单、库存变更都希望立即反映在查询结果里。而二级缓存容易让人掉进“缓存和数据库不一致”的坑。

那哪些地方适合开缓存？我建议只对“基本不变化的主数据”开，比如款式品类字典表、客户名称列表、物料单位列表。这些数据查询频率高、更新频率几乎为零，加上缓存能明显减小数据库压力。在Mapper接口上加@CacheNamespace注解即可。其余订单、库存、流水等核心业务表，保持每次实时从数据库查，不缓存。这也是我做这类系统的一贯原则：宁可数据库多扛一点查询，也不让业务数字出现不一致。

5.4 TypeHandler和自动填充在项目中的实际应用

源码里还有一个容易被忽略的设计——TypeHandler。比如订单状态字段在库里存的是TINYINT，但前端页面要显示“已确认”“已排产”这样的文字说明。如果每个查询接口都在Service里做枚举转换，代码会非常啰嗦。这里用MyBatis的TypeHandler，在查询结果映射时自动把整数转换为对应的状态枚举对象，同理在写入时把枚举转回整数。对这类业务字段来说，这一层转换能让Controller代码干净很多，这也是热词里“mybatis中typehandler的工作流程图”指向的实际用途。

数据库时间字段方面，我把create_time和update_time都放在数据库层处理，建表时用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP，这样即便代码忘了传时间字段，数据也是正确的。程序层面只在需要业务时间（如交期、发货日期）时才显式传入。

6. 前端Vue实现中的关键片段：路由、状态管理与订单操作页

6.1 动态路由与权限控制的落地方式

这套前端没有把所有页面都在路由表里写死，而是基于用户角色动态生成。后端登录接口返回用户的角色标识和菜单列表，前端拿到菜单列表后，通过router.addRoutes动态注册对应页面路由。这样不同角色登录进去看到的菜单天然不同：业务员看订单和客户，车间主任看生产计划和报工，仓库管理员看库存和出入库。菜单权限控制不在页面里写一堆v-if，而是从路由源头就做了隔离，侵入性最小。

同时，还需要做一层全局路由守卫，处理未登录跳转和登录后过期清理：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('fms_token') if (to.path !== '/login' && !token) { next('/login') } else if (to.path === '/login' && token) { next('/dashboard') } else { next() } })

这里有个细节很多人会踩坑：动态路由是在登录之后才addRoutes的，如果用户刷新页面，路由表会被重置为空。所以要在刷新时重新获取用户信息并再次生成动态路由，否则一刷新就跳回登录页或者白屏。我建议把用户信息持久化到localStorage，刷新时先从本地恢复再走一次addRoutes逻辑。

6.2 axios封装与接口错误统一处理

前端请求后端接口，我不会在每个页面里单独写axios调用，而是统一封装一个request.js。核心做了三件事：基础URL配置、请求拦截器注入token、响应拦截器统一处理后端返回码。后端返回结构统一是{ code: 200, data: ..., message: ... }，拦截器里如果code等于401，直接清掉token并跳转登录页；如果code不等于200，用Element UI的Message提示错误信息。这样业务页面里只需要关心data，不用每个方法都写try catch去处理异常提示。

6.3 SKU联动选择组件的设计与坑

订单新增页面是前端最复杂的部分，核心是那个SKU联动选择组件。它要实现的交互是：选择款号，自动加载该款号的颜色列表；选择颜色，自动加载尺码列表；然后批量填写每个尺码的数量。我在实现时用一个嵌套的el-table：每一行是一个“颜色”，点击展开后出现尺码数量输入区，这样做既能看清楚又能批量操作。

这个组件有两个常见的坑。第一个是数据联动时的依赖更新问题，选完颜色再选尺码，需要用watch监听颜色变化并清空已输入的尺码数量，否则切颜色后数量会串行。第二个是数量校验，前端要拦截负数和超大批量（防止多写一位数导致整单数量异常），后端在Controller里的@Validated也要做二次校验。前端拦截是体验，后端校验是安全，两头都要做。

生产看板页面我也是用Vue做的，把报工数据按工单分组，按日期横向排列，直接用Element UI的进度条组件展示完成比例。这个页面做好之后，车间主任每天只需要看一眼进度条就能判断哪些工单要催货，比之前每天翻本子高效太多。

7. 本地跑通全流程：从数据库初始化到前后端联调

7.1 环境检查与版本匹配建议

在动手跑项目之前，先核对环境，版本匹配能避免大量无意义报错。我的建议组合是：

如果你电脑里装的是JDK 11或17，跑Spring Boot 2.7也没问题，但要注意pom.xml里不要引入javax被替换的冲突依赖。Node版本是我特别想强调的，很多旧前端项目依赖node-sass，新版Node下默认会编译失败，直接用16.x最稳。

7.2 初始化数据库与基础数据

数据库初始化别用图形界面去手动建表，那样既慢又容易漏字段。直接打开Navicat或命令行，执行SQL脚本即可。我的建议顺序是：

1. 执行建库语句，建fms_db，设置utf8mb4字符集
2. 执行表结构脚本，依次创建主数据表和业务表
3. 执行初始化数据脚本（含演示账号、菜单权限、基础客户/物料/款式数据）

执行完检查一下：登录表和菜单表里有没有数据。很多项目跑不起来，不是代码有问题，而是菜单权限表空了，登录之后看不到任何页面。所以初始化后先查一遍关键表的数据行数，确认不是零。

7.3 后端启动参数与常见启动失败原因

后端启动前，先改application.yml里的数据源配置。MySQL 8一定要加时区和SSL相关参数，这块对小白来说是个经典坑：

spring: datasource: url: jdbc:mysql://localhost:3306/fms_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

这里serverTimezone=Asia/Shanghai解决了“日期差8小时”的问题；allowPublicKeyRetrieval=true解决MySQL 8使用caching_sha2_password认证时报的Public Key Retrieval错误。如果你用的是MySQL 5.7，驱动类仍可以写com.mysql.jdbc.Driver，但MySQL 8驱动兼容5.7，直接用com.mysql.cj.jdbc.Driver更省事。

启动时如果报端口被占用，spring-boot-maven-plugin起了但日志卡住不动，多半是8080被别的进程占了，改server.port或杀掉占用进程即可。如果报表找不到，检查mybatis.mapper-locations是否指向classpath:mapper/*.xml，并且XML文件路径与包结构匹配。这些都是我帮人看代码时最常处理的问题。

7.4 前端启动与跨域配置细节

前端启动前先执行npm install，如果安装速度慢，把npm镜像切到淘宝源：

npm config set registry https://registry.npmmirror.com npm install npm run serve

之后要检查前端请求的后端地址是否写对。utils/request.js里的baseURL和后端application.yml里的server.port要一致。如果前后端端口不同，就需要在后端配置跨域。这套系统的WebConfig实现了WebMvcConfigurer，重写addCorsMappings，允许指定前端地址跨域。这里的关键在于，setAllowedOriginPatterns里要写前端完整地址（http://localhost:8081），而不是*，否则带token的请求会被浏览器拦截。

7.5 功能自测的基本清单

启动完成后，建议按这份清单走一遍，确认系统真的可用：

• 用管理员账号登录，左侧菜单是否完整显示
• 新建一个订单，选款号、颜色、尺码，填写数量，确认后订单列表中能看到且状态正确
• 对订单执行排产，生成生产工单，维护计划日期
• 做一次采购入库，库存数量增加，库存流水有记录
• 做一次生产领料，库存数量减少，对应物料低于安全库存后出现预警
• 添加完工报工，生产看板进度百分比更新
• 创建出货单，订单状态流转为已发货

跑完这套流程，说明前后端、数据库、业务逻辑方方面面都通了。很多初学者喜欢跳过功能验证直接改代码，我建议还是先把Demo流程完整走一遍，形成一个“正确结果”的心理预期，后面改动时才知道是不是改坏了。

8. 基于这套源码二次开发的实用建议

8.1 包名和数据库前缀的全局替换

很多同学是拿这套源码去做毕业设计或者项目练手，如果你准备写成自己的项目，第一步是改包名和项目名。以下几个地方要同步替换，缺一不可：

• Java代码包路径com.fms换成你自己的域名倒写，比如com.example
• XML里的namespace、resultType、parameterType全跟着换
• application.yml里的spring.application.name
• 前端代码里接口路径如果保留了上下文路径，也要一起改

用IDE全局替换功能时，注意先替换长包名再替换短包名，顺序反了小写字母可能串替换到其他英文单词，比较稳妥的是在文件搜索时勾选“全字匹配”和“限定在代码注释以外”。

8.2 加报表统计和导出Excel

管理系统做完CRUD之后，最容易加分的功能就是统计报表和数据导出。我给你一条从简到繁的实现路线：

第一步加订单状态分布统计：用MySQL的GROUP BY status直接统计各状态订单数，前端用ECharts做一个饼状图。这一步只是新增一个查询接口和一个统计页面，代码量不大。

第二步加月度产出趋势：按月份聚合订单完成数量和发货数量，用折线图展示。SQL里用DATE_FORMAT(delivery_date, '%Y-%m')做分组，MySQL 8还支持WITH ROLLUP做小计。

第三步加报表导出Excel：后端使用EasyExcel或POI导出当前查询列表，直接把现有分页查询的结果对象转成Excel行即可。前端在列表右上角放一个“导出”按钮，拿到后台生成的文件流后用blob下载。

这三步做完，你的项目从“能用”变成了“好演示”，面试或答辩时效果完全不同。

8.3 从单体到微服务：什么时候才需要拆分

最后聊一个很多人都会问的问题：这个项目要不要拆微服务？我的观点是，如果你的系统只是这家工厂自己内部用，用户量不超过几百人，业务量每天几千单，拆微服务纯粹是给自己找麻烦。单体架构把所有模块放在一个应用里，事务管理简单、部署运维成本低、排错容易，对中小制造企业的场景来说是最优解。

只有当出现以下情况时才考虑拆分：比如集团下面有多家工厂，每家的生产数据要独立管理，需要通过接口互相调用了；或者报表统计并发过高，单库单表扛不住了。到了那个阶段再按“库存服务”“订单服务”“生产服务”拆，配合消息队列做数据同步，才是合理的演进路径。为了微服务而微服务，把生产计划模块单独拆出一个服务，却没有独立数据库和流量场景，反而会引入分布式事务和数据一致性的麻烦。

我自己在实际部署这套系统的过程中，印象最深的一次排障是MySQL 8的认证插件问题，客户端连接时一直报Authentication plugin 'caching_sha2_password' cannot be loaded，折腾了半天最后确认是驱动版本太低，升级MySQL连接驱动版本后立马解决。所以如果你也遇到启动时报数据库连接相关错误，先去看驱动版本，再看URL参数，八成能解决。最后再分享一个做这类系统的小心得：别急着写代码，先把订单、库存、工单、物流这条业务链在纸上画一遍，把每个表的关联关系理清楚了，后面所有模块都会顺很多。