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

前阵子整理了一套基于SpringBootVue的服装生产管理系统源码春节前刚好利用这套骨架给一家做针织衫的中小型服装厂做过信息化改造摸底。整套系统跑下来我觉得它特别适合两类人一类是刚入行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. 技术选型背后的取舍SpringBootVueMyBatisMySQL四个组件怎么搭才不别扭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 业务单据表订单、生产工单、出入库单的主外键关系我把这套系统的核心业务表关系拉出来说你会发现它是一个典型的“单据 明细”模式主表明细表关联字段fms_order客户订单fms_order_itemorder_idfms_purchase_order采购单fms_purchase_itempurchase_idfms_production_order生产工单fms_work_report报工记录production_order_idfms_delivery出货单fms_delivery_itemdelivery_id主表存单据的公共信息和状态明细表存具体物料、款色码和数量。这种设计有两个好处一是查询单张单据时连表简单清晰二是统计时可以直接对明细表做聚合性能更好。我用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 CHARSETutf8mb4 COLLATEutf8mb4_general_ci。如果你导入后发现中文变问号十有八九是这里出了问题。用Navicat导入脚本时也记得把连接编码切到utf8mb4。5. MyBatis在这一项目里的正确用法动态SQL、批量操作与缓存5.1 动态SQL处理多条件组合查询管理系统后台几乎每个列表页都会有一个“筛选区”输入订单号、选择状态、选择客户、选交货日期范围然后点查询。这些条件用户不会每次都全填所以SQL必须是动态拼装的。MyBatis的where加if标签就是为这个场景设计的。比如订单分页查询的核心SQLselect idselectOrderPage resultTypecom.fms.entity.Order SELECT * FROM fms_order where if testorderNo ! null and orderNo ! AND order_no LIKE CONCAT(%, #{orderNo}, %) /if if teststatus ! null AND status #{status} /if if testcustomerId ! null AND customer_id #{customerId} /if if teststartDate ! null AND delivery_date gt; #{startDate} /if if testendDate ! null AND delivery_date lt; #{endDate} /if /where ORDER BY create_time DESC /selectwhere标签会自动处理第一个条件前的AND条件全为空时它也不会生成多余的where关键字。这套写法在面试里也经常被问到“MyBatis动态SQL有哪些标签、各自用途是什么”这种面试题你把这段XML逻辑讲清楚基本就过关了。5.2 批量插入提升工单明细的写入效率订单明细和BOM明细都有批量保存的需求。比如一个生产工单要生成几十条报工计划如果用循环单条insert不仅慢而且要写几十次数据库交互。MyBatis的foreach标签可以把一个List参数拼成一条多值插入语句insert idbatchInsertBomItems INSERT INTO fms_style_bom (style_id, material_id, quantity, loss_rate, unit) VALUES foreach collectionlist itemitem 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 环境检查与版本匹配建议在动手跑项目之前先核对环境版本匹配能避免大量无意义报错。我的建议组合是组件推荐版本说明JDK1.8兼容面最广Spring Boot 2.x默认支持MySQL8.0.x注意时区配置编码用utf8mb4Maven3.6.x 及以上拉依赖用建议配国内镜像Node.js14.x 或 16.x前端依赖安装稳定过高版本可能报node-sass错误npm/yarn随Node推荐用淘宝镜像源如果你电脑里装的是JDK 11或17跑Spring Boot 2.7也没问题但要注意pom.xml里不要引入javax被替换的冲突依赖。Node版本是我特别想强调的很多旧前端项目依赖node-sass新版Node下默认会编译失败直接用16.x最稳。7.2 初始化数据库与基础数据数据库初始化别用图形界面去手动建表那样既慢又容易漏字段。直接打开Navicat或命令行执行SQL脚本即可。我的建议顺序是执行建库语句建fms_db设置utf8mb4字符集执行表结构脚本依次创建主数据表和业务表执行初始化数据脚本含演示账号、菜单权限、基础客户/物料/款式数据执行完检查一下登录表和菜单表里有没有数据。很多项目跑不起来不是代码有问题而是菜单权限表空了登录之后看不到任何页面。所以初始化后先查一遍关键表的数据行数确认不是零。7.3 后端启动参数与常见启动失败原因后端启动前先改application.yml里的数据源配置。MySQL 8一定要加时区和SSL相关参数这块对小白来说是个经典坑spring: datasource: url: jdbc:mysql://localhost:3306/fms_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver这里serverTimezoneAsia/Shanghai解决了“日期差8小时”的问题allowPublicKeyRetrievaltrue解决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.exampleXML里的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参数八成能解决。最后再分享一个做这类系统的小心得别急着写代码先把订单、库存、工单、物流这条业务链在纸上画一遍把每个表的关联关系理清楚了后面所有模块都会顺很多。