做服装生产管理系统这个项目前前后后折腾了两个月这里把整套设计思路、技术选型、踩坑记录都整理出来。项目用的是 Java SpringBoot Vue3 MyBatis数据库是 MySQL前后端完全分离。对象很明确就是中小型服装厂里那些订单跟踪、工序排产、物料统计、生产报工的业务需求。如果你正准备做一个类似的开发项目或者正在看这类源码不知道从哪下手这篇文章能帮你省掉不少弯路。很多网上流传的源码只给你看代码不给你讲为什么要这么设计。我这次反过来先从业务角度拆清楚每个模块存在的理由再落到表结构、接口、页面最后把部署和实际运行中容易翻车的地方全部摊开讲。看完以后你不光能照着做一个系统还能明白每一行关键代码背后的取舍。1. 项目背景与核心需求拆解1.1 服装厂生产管理的核心痛点先说业务。服装生产跟普通小商品生产不太一样它有几个特别折磨人的特点款式多、批量小、工序杂、交期紧。一个订单下来可能分好几个颜色、好几个尺码每个尺码又是一条独立的裁剪、缝制、整烫、包装链路。传统用 Excel 管理到了月底对账的时候经常出现“订单明明发了货库存却对不上”这种问题。这个系统要解决的就是三件事第一把订单从录入到出货的完整状态串起来第二把每道工序的报工数据收集上来知道每个环节做了多少件谁做的第三让物料和成品的库存数字尽量接近真实别在盘点的时候吓一跳。所以我在设计的时候没有追求特别花哨的功能而是抓住“订单—工序—报工—出入库”这条主线先把闭环跑通。1.2 为什么偏偏选这四样技术选 SpringBoot 没什么悬念。Java 生态里做企业级应用SpringBoot 的基本功足够硬写接口、整合第三方库、部署运维都有成熟方案。尤其做这种带权限、带报表的管理系统Java 的稳定性让人踏实。前端选 Vue3 而不是 Vue2一是因为 Vue3 的 Composition API 在处理多个页面共用的逻辑时更清爽二是这个项目需要跟流程表单打交道setup 语法糖写起来效率确实高。配 Vite 做构建工具冷启动和热更新都明显比 Webpack 时代的 Vue2 项目舒服。MyBatis 在这个场景里比 MyBatis-Plus 更合适。为什么因为服装生产管理的报表查询特别复杂订单维度、工序维度、员工维度、时间维度组合起来SQL 里大概率要写动态条件。MyBatis 的 XML 文件允许我把这些复杂的 SQL 一点点打磨出来可控性更强。MyBatis-Plus 虽然开发快但遇到多表聚合查询时反而不如手写 SQL 直接。MySQL 就不用说了中小型系统最稳妥的选择。这里提醒一句如果数据量真的大了可以再考虑读写分离但初期单实例 MySQL 配上良好索引完全够用。2. 系统架构设计前后端分离的关键决策2.1 前端工程结构与组件规划前端我用的是 Vite 创建 Vue3 项目目录结构基本是这样的src/ api/ -- 接口请求封装 assets/ -- 静态资源 components/ -- 公共组件 layout/ -- 主布局组件 router/ -- 路由配置 stores/ -- 全局状态管理 views/ -- 页面很多人做管理后台喜欢一把梭所有代码都往 views 里堆。我个人的习惯是把api目录单独拆出来每个模块一个 JS 文件统一管理接口地址。这样后端接口一旦变化只需要改一个文件不用满项目找请求调用点。组件这块我封装了两个比较核心的东西一个是pro-search负责组合查询条件另一个是pro-table负责列表展示和分页。Vue3 的组件复用能力比 Vue2 强不少通过v-model和defineProps做数据双向绑定业务页面里写少量代码就能完成一个标准列表页。2.2 后端分层架构与模块划分后端我按经典的四层结构Controller、Service、Mapper、Entity。重点是模块怎么划分。我没有做成一个大而全的单体应用而是按业务领域分成几个包com.xxx.garment controller/ -- 接口层只做参数接收和结果封装 service/ -- 业务逻辑层处理事务、状态流转 mapper/ -- MyBatis 数据访问层 entity/ -- 数据实体 dto/ -- 前端交互的数据对象 vo/ -- 视图对象返回给前端的数据 config/ -- 配置类 common/ -- 统一返回结果、异常处理Controller 层我严格禁止写业务代码它只做三件事接收请求参数、调用 Service、把结果包装成统一的ResultT返回。这样做的原因是便于后面前后端接口联调时排查问题——出错了先看 Service接口对不上状态码先看 Controller不会两头猜。2.3 接口约定与统一返回格式前后端分离项目最怕的就是接口格式不统一。有的接口直接返回数据有的返回{code: 200, data: ...}前端写封装的人会想打人。我用的统一返回结构是{ code: 200, message: success, data: {} }所有接口都走这个格式分页数据也放在data里前端用 axios 的响应拦截器统一处理。如果业务抛异常后端有个全局异常处理器RestControllerAdvice能把异常信息转成上面这个格式返回。这一步看似简单实际开发里能省掉大量联调时的沟通成本。3. 数据库设计MySQL 表结构怎么规划3.1 核心业务表拆解服装生产管理系统最核心的表我认为只有五张订单表、订单明细表、工序表、报工记录表、库存表。订单表不能只存一个总数因为服装订单要拆成款式、颜色、尺码。我设计了订单主表和订单明细表两级结构主表存订单编号、客户、交货日期、总数量明细表存每个颜色和尺码的具体数量。工序表单独拎出来非常重要。服装生产的工序不是固定的一条裤子可能拆成裁剪、车缝、锁边、整烫、包装这么多步骤每个步骤还可能有不同的计件单价。工序表要跟订单关联还要有工序序号方便按顺序展示。报工记录表记录每个工人某个时间段内完成了哪个订单的哪道工序、数量多少这张表是生产统计的主要数据来源。3.2 状态字段与关联关系设计这里我要重点说状态字段。很多新手喜欢把状态直接写成字符串比如“进行中”我建议用整数枚举后端定义常量或者枚举类订单状态0待排产1生产中2已完成3已取消报工状态0草稿1已确认库存类型1入库2出库用整数有几个好处查询速度快、避免字符串比较出错、后端可以做合法性校验。前端拿到数字之后映射成中文显示这个映射逻辑统一放前端的一个字典文件里。数据库里不要写一堆注释吗当然要写字段注释必须写清楚时间长了没人记得住那个字段是干嘛的。关联关系上我全部采用逻辑外键不在数据库层面物理建外键约束。为什么因为这套系统的报表查询经常要跨多张表 join物理外键会影响插入删除效率和灵活性。只要保证代码层面事务正确数据一致性有保障。3.3 数据库初始化与数据字典MySQL 安装配置这块我不多啰嗦只说两个容易踩的坑。第一个是字符集建库的时候一定要指定 utf8mb4不然存不了生僻字或者特殊符号。第二个是时区连接串里加上serverTimezoneAsia/Shanghai不然时间字段会差八个小时。建表语句我用一个schema.sql文件管理每张表都加上CREATE TABLE IF NOT EXISTS。系统第一次部署的时候可以通过一个初始化接口执行这个 SQL 文件或者直接用命令行导入。如果后续表结构有改动我会写增量脚本而不是直接改原文件这样方便在已上线的系统上平滑升级。4. 后端核心实现SpringBoot MyBatis 落地细节4.1 MyBatis 配置与 XML 映射文件MyBatis 的核心就是 XML 映射文件。SpringBoot 整合 MyBatis 时在application.yml里配置好 mapper 扫描路径和 XML 文件位置mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.xxx.garment.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case这个配置建议一定要开。数据库字段叫order_no实体里叫orderNo开启之后自动映射不用写一堆 ResultMap。XML 文件里我一般会这样组织每个表的查询条件用sql片段抽出来公共的列名也用sql定义。比如订单明细查询订单表和明细表 join 的场景很多我把 join 语句直接写在公共片段里后续新增查询就不需要重复写一大串 join。4.2 分页插件 PageHelper 的正确用法热词里我看到有人专门问 SpringBoot 里 MyBatis 分页插件的用法这里详细说。项目里用的是 PageHelper集成非常简单引入依赖后配置一个拦截器Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }实际使用的时候核心就一句话先调用PageHelper.startPage(pageNum, pageSize)紧接着执行你的查询方法查询完成后用PageInfo包装结果PageHelper.startPage(pageNum, pageSize); ListOrderVO list orderMapper.selectOrderPage(queryDTO); PageInfoOrderVO pageInfo new PageInfo(list);这里有一个巨坑startPage 必须紧接着查询方法调用中间不能有其他 MyBatis 查询否则分页会作用到错误的 SQL 上。比如你在 startPage 之后做了个数据字典查询那分页就完全乱了。我在项目里遇到过两次排查了半天才反应过来是这种问题。4.3 事务处理与生产数据一致性生产报工涉及库存变动比如裁片报工完成面料库存就要相应减少。这里的库存操作和报工记录插入必须在一个事务里完成不然会出现报工成功但库存没扣的情况。我在 Service 层加了Transactional(rollbackFor Exception.class)。注意默认情况下 Spring 事务只有遇到 RuntimeException 才回滚如果你捕捉了异常并转换成业务异常需要显式指定回滚类型。rollbackFor 写Exception.class最省心别省略。这里还要说一个实战经验事务不是开得越多越好。比如报表查询这种只读操作就不需要开事务开了反而占用数据库连接。我只在写操作比较多的地方加事务读操作一律不加。4.4 使用 POI 处理报表导出与图表服装厂月底想知道每个工人的计件工资老板想看订单完成率这些都需要报表导出。我用 Apache POI 做 Excel 导出后端生成数据后填充到工作表里。很多人在问 POI 能不能用 Word 生成图表答案是能。但实际做下来直接用 POI 在 Word 里画图表并不方便。我的建议是常规的月度统计导出 Excel 足够用Excel 本身自带图表功能。如果客户非要 Word 报告可以把统计结果做成图片插进去比直接操作 Word 图表对象稳定得多。5. 前端核心实现Vue3 页面与组件化5.1 Vue3 项目初始化和目录规划Vue3 的环境搭建先确认 Node 版本建议用 16 以上版本。用 Vite 创建项目npm create vitelatest garment-frontend -- --template vue创建完成以后我建议立刻装几个必备依赖vue-router、pinia、axios、element-plus。Element Plus 是 Vue3 生态里最成熟的管理后台 UI 库表格、表单、弹窗这些组件开箱即用。目录规划方面views下面我按模块划分dashboard首页看板order订单管理process工序管理report报工管理warehouse库存管理system系统设置每个业务模块尽量保持独立不要跨模块随便 import 组件。如果确实有公共逻辑提取到composables里去这是 Vue3 相对 Vue2 最大的优势。5.2 登录鉴权和路由守卫管理系统的登录鉴权方案很成熟后端登录成功后返回 token前端把 token 存到 localStorageaxios 请求拦截器统一在请求头携带 token。路由守卫做两层控制。第一层是未登录拦截访问任何业务页面时如果没有 token 就跳转登录页。第二层是权限控制路由的 meta 里配置角色标识比如meta: { roles: [admin] }进入页面时再用当前用户角色判断是否允许访问。router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) } else { next() } })权限控制这里踩过一个坑token 过期后接口返回 401但如果前端不做统一处理用户会一直停在页面上不知道发生什么。我在 axios 响应拦截器里加了判断一旦 code 是 401清掉本地 token跳转登录页同时用ElMessage提示登录已过期。5.3 核心页面生产订单管理与工序报工订单管理页面是系统里最复杂的。列表需要支持组合筛选按订单状态、客户名称、交货日期范围查询。新增订单时主表单加一个明细表格动态添加多个颜色尺码行。这里用 Vue3 的响应式数据处理起来很方便const detailList ref([]) const addDetailRow () { detailList.value.push({ color: , size: , quantity: 1 }) }报表页面里的工序报工数据结构是一张报工记录表展示字段包括订单号、工序、员工姓名、报工数量、工资单价、完成时间。因为是计件工资所以前端要实时算工资数量乘以单价。在表格里用computed或者直接显示时计算都可以。5.4 与后端接口联调的注意事项前后端联调是项目后期最磨人的阶段。我这里提供几个稳定的做法。开发环境用 Vite 的 proxy 代理解决跨域。配置在vite.config.jsserver: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } }接口文档用 Swagger 生成每个接口写清楚参数、返回体、状态码前端不用来问就知道怎么调。如果后端接口改动频繁建议在api封装层集中处理字段映射别在页面里到处改字段名。6. 常见问题与排查技巧实录6.1 MyBatis 相关Update 执行慢、Param 参数绑定先聊 Update 执行慢的问题。我在做生产报工更新的时候遇到过一次一个简单的 update 语句执行时间居然要几百毫秒。排查步骤是这样的先看 SQL 执行计划发现 update 语句走了全表扫描因为 where 条件里的字段没加索引。解决办法很简单给订单明细表加了联合索引(order_no, detail_no)。还有 MyBatis 里Param的问题。如果 Mapper 方法有多个参数不用 Param 就会报Parameter xxx not found。我一开始在 XML 里写#{orderNo}对应方法参数orderNo编译直接报错。必须写成ListOrderDetail selectByOrderNo(Param(orderNo) String orderNo, Param(status) Integer status);XML 里就用#{orderNo}、#{status}顺序无所谓名字对上就行。这是新手最常犯的错。6.2 MySQL 相关时区问题与默认值设置MySQL 时区问题我在前面提到过这里补充实际症状。如果连接串没有设置时区系统跑在服务器上本地时间明明是下午三点查出来的时间却是上午八点日期对不上。解决方案是在 JDBC 连接串后面加参数jdbc:mysql://localhost:3306/garment?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai再说默认值。MySQL 8.0 里设置字段默认值为 0直接这么写就行ALTER TABLE order_detail MODIFY COLUMN quantity INT DEFAULT 0;但要注意如果这个字段已经定义为NOT NULL修改默认值的时候要保留NOT NULL约束。很多人这里会翻车因为修改默认值之后原来允许为空的数据就插入不进去了。6.3 前后端联调跨域、XSS 与文件上传跨域问题如果是生产环境后台 Nginx 反向代理可以直接解决把/api路径转发给后端服务。我在开发环境用 Vite proxy在生产环境用 Nginx两个地方都不需要后端额外开启 CORS。XSS 这个热词也值得说。系统里有员工可以填备注如果有人在备注里写了一段script标签前端不加过滤就会执行。我的处理是前端用v-html的地方全部改成纯文本插值后端再加一层过滤在请求进入 Controller 之前通过全局过滤器把script、onerror这些危险标签替换掉。文件上传这里很多人会忽略 PDF 文件上传也可能带 XSS 风险。上传 PDF 本身只是存储文件但如果用户上传的是一个包含恶意 JavaScript 的 PDF下载打开后就可能触发。我的做法是上传时校验 MIME 类型并且把文件名重命名为随机字符串避免用户可控的文件名直接进入页面。6.4 打包部署与性能优化前端打包执行npm run build产物是静态文件放到 Nginx 的 html 目录就行。后端打包用 Mavenmvn clean package -DskipTests打成 jar 包以后用java -jar直接运行。生产环境我一般用nohup后台运行并且配置spring.profiles.activeprod。性能优化方面MySQL 要开慢查询日志分析哪些 SQL 耗时超过一秒。项目里最常见的慢查询是报表模块的聚合统计处理办法是给统计条件字段建联合索引。另外给前端首页加了缓存订单状态的数据不是每次刷新都重新查数据库而是五分钟拉一次缓存。最后补充一点点个人经验这套系统最大的价值不在于那个页面也不在于那几个接口而在于把所有生产环节的数据串在了一起。我后来复盘时发现真正花时间的不是写代码而是跟业务方聊清楚“报工数据谁录入、什么时候录入、错了怎么改”这些流程问题。如果你拿到一套现成源码要二次开发建议先把订单状态流转画一遍再动代码。状态流程理顺了开发效率至少提高一半。另外一个技巧分享给做这类管理系统的朋友数据库备份一定要做自动化。用系统自带的定时任务每天凌晨备份一次 MySQL 数据保留最近七天。生产数据是无价的代码丢了还能重写生产数据丢了那就是事故。设置备份的时候顺便把日志备份也带上方便日后排查问题。按照这个思路从需求到上线大约五到六周就能完成一个可交付的版本。中间会推翻一些设计方案很正常。但只要核心的生产链路跑通了剩下的功能都是锦上添花。