1. 这个系统到底在解决什么问题第一次完整地做一个前后端分离的管理系统我选的主题就是“基于 Java SpringBoot Vue3 MyBatis MySQL 的服装生产管理系统”。这套系统源码看起来像是一个典型的课程设计或者毕业设计题目但把它拆开看它本质上是在解决一个小型服装工厂从接单、备料、排产、报工到入库发货的全流程信息同步问题。以前很多工厂靠 Excel 排计划、靠微信群传进度、靠纸质工单记录工序数据一多就乱老板问个订单做到哪一步了要拉半天表格。这套项目把链路搬到系统里业务人员通过 Vue3 后台录入订单后端 SpringBoot 处理业务规则MyBatis 负责数据库读写MySQL 保存所有业务数据前端再通过接口实时刷新状态整个流程变得可追踪、可统计。我建议这几类人认真看这个项目准备 Java 后端入门但缺一个完整业务案例的开发者想把前后端分离开发流程走一遍的 Vue3 初学者以及小工厂想自建生产管理系统的技术负责人。它不是那种“只能跑通登录”的玩具项目而是把服装行业里高频出现的订单、工单、工序、质检、库存、计件工资等模块做了完整结构对真实业务有参考价值。1.1 服装工厂的核心业务链路做系统之前必须先搞清楚服装厂是怎么运转的。一条单子进厂后大概经历这些环节销售和客服录入客户订单技术部根据订单创建款号和 BOM物料清单计划部根据订单交期和产能生成生产计划裁剪车间按照尺码比例拉布、裁剪缝制车间按工单把裁片做成成衣后整车间负责锁眼、钉扣、整烫、包装质检确认合格之后进成品仓最后安排发货。这个链路里订单不是一张表就能解决的。一个订单可能包含多个款号一个款号又分好几个颜色和尺码这就是服装行业常说的 SKU 维度。真正下发到车间的是“生产工单”工单必须关联到款号、颜色、尺码、数量、计划交期、负责班组。如果系统只做了订单表而没有工单拆分后面所有工序进度、车间产量、计件工资都没法算。所以这个系统里我第一件事就是把业务主链画清楚客户 - 订单 - 订单明细 - 款号 - BOM - 生产工单 - 工序 - 报工记录 - 质检记录 - 成品库存。所有页面和数据表都围绕这条主链展开。1.2 技术栈为什么这么选SpringBoot 是现在 Java 后端最主流的选择理由很简单自动配置、内嵌 Tomcat、生态成熟不需要像早期 SSM 那样写一大堆 XML 配置。Vue3 相比 Vue2 最大的变化是组合式 API 和更灵活的逻辑复用配合 Element Plus 做后台管理界面很顺手既适合新手学也适合团队长期维护。MyBatis 相比 JPA 更可控尤其是服装生产这种统计查询特别多的业务多条件筛选、多表关联、动态更新字段手写 SQL 反而看得明白。MySQL 则是“性价比选手”部署简单、资料多、小规模集群也够用前中期完全不需要上重型数据库。有朋友问为什么不用 MyBatis-Plus。其实也能用但这个项目里我保留了较多自写 SQL主要原因是想把分页、动态 SQL、统计报表这类高频技能练扎实。等你理解了底层 SQL 怎么写的再上手 MyBatis-Plus 也就是几分钟的事。这个选择对项目的最终效果没有坏处反而让源码里的 SQL 更贴合真实业务。2. 数据库表设计先建模型再写代码2.1 核心数据表与关系根据业务链路我梳理了几个核心表它们也是这套服装生产管理系统的骨架。每个表之间通过业务编号或主键关联比如garment_order是订单主表order_item是订单明细表work_order是生产工单表。下面这张表是主要业务表的定位说明表名核心字段作用sys_userusername, password, role_id, real_name登录用户内置管理员和车间员工角色garment_orderorder_no, customer_id, order_date, order_status客户订单主表记录订单整体状态order_itemorder_id, style_id, color, size, quantity订单明细一个订单对应多款多色多码stylestyle_code, style_name, image_url款号档案记录服装款式基础信息bom_materialstyle_id, material_id, material_count款号对应的物料清单决定用料需求work_orderwork_order_no, order_item_id, plan_date, status生产工单真正下发给车间的最小生产任务process_stepwork_order_id, process_name, sort_no, unit_price工单的工序划分计件工资按工序计算work_reportprocess_step_id, employee_id, quantity, report_date员工每日报工记录是产量统计和工资计算的原始数据quality_checkwork_order_id, check_result, bad_count, check_time质检记录标记合格、返工、报废finished_stockstyle_id, color, size, quantity成品库存表入库后增加、发货后扣减这些表之间不是孤立存在比如查询“某订单当前生产进度”就要从garment_order找到order_item再关联work_order再关联process_step和work_report汇总。设计阶段把这些关系理清楚后面写接口会顺手很多。2.2 字段设计里容易被忽略的细节我在改这个项目时踩过一个很典型的坑很多表一开始没有状态字段或者状态字段用的是中文比如“进行中”“已完成”。当时觉得挺直观结果后面做统计报表时发现字符串判断容易出错还得兼容输入法全角半角非常难受。后来我统一改成tinyint类型的数字状态并在一张常量表或者 Java 枚举里维护对应关系。比如订单状态0 待确认1 已确认2 已排产3 生产中4 已完工5 已入库6 已发货7 已取消。页面上展示的文字由前端根据数字映射数据库只存数字筛选和统计都比字符串高效。另外有三个字段我要求所有业务表都必须有create_time、update_time、deleted。deleted是逻辑删除标识默认 0业务数据不物理删除这样历史记录还能查。写入时在代码里统一设置或者利用 MyBatis 的自动填充功能都可以。还要注意的是金额和数量字段一律用DECIMAL(10,2)不要用float或double否则累计产量和工资时会出现小数点误差财务核对的时候非常头痛。2.3 用状态机管理订单和工单流转服装生产管理最大的难点是状态变化特别多。同一个订单从待确认走到已发货中间要经过计划、备料、裁剪、缝制、后整、质检、入库好几个环节如果所有环节都去更新order_status一个字段逻辑会乱成一团。我最终把状态拆成了几组订单状态、生产状态、库存状态。订单状态管整个单子的商务进度生产状态管道车间里所有工单的汇总进度库存状态管成品是否入库、是否完全发货。三个状态相互独立但又能联合查询。在代码里我不建议每个接口直接写“把订单状态改成已排产”这种散落的赋值语句。最好在 Service 层提供统一方法比如confirmOrder()、startProduction()、completeWorkOrder()由这些方法校验前置状态并更新后续状态。这样别人读代码时能一眼看出业务流程也避免一个状态被多个接口重复改产生脏数据。对于后期接扫码报工、PDA 终端这套状态机设计也能平滑兼容。3. 后端接口与 MyBatis 的落地实现3.1 SpringBoot 工程结构和关键配置后端的整体结构建议按功能分层不要所有类都堆在 controller 里。我是这样划分的src/main/java/com/company/garment/ ├── config // 配置类比如拦截器、Cors、全局异常 ├── controller // REST 接口层 ├── service // 业务逻辑层 ├── mapper // MyBatis Mapper 接口 ├── entity // 数据库实体类 ├── dto // 前端请求和响应的数据对象 └── common // 统一返回结果、常量、工具类对应的application.yml里MySQL 连接串需要注意几个参数尤其是 MySQL 8 环境spring: datasource: url: jdbc:mysql://localhost:3306/garment?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.company.garment.entity configuration: map-underscore-to-camel-case: truecharacterEncodingutf8保证中文不出现问号serverTimezoneAsia/Shanghai解决时间差问题allowPublicKeyRetrievaltrue是很多人在 MySQL 8 连接时报Public Key Retrieval is not allowed时才想起来的参数提前写上能少踩一次坑。map-underscore-to-camel-case用来把数据库的user_name自动映射成 Java 的userName省掉一堆写resultMap列表的重复劳动。3.2 MyBatis 分页插件实操PageHelper 用法前端后台管理页面几乎离不开分页。MyBatis 最常用的分页方案就是 PageHelper不是 MyBatis-Plus 那种自带分页插件而是独立的pagehelper-spring-boot-starter。引入依赖dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version1.4.7/version /dependency然后在application.yml里加一段配置pagehelper: helper-dialect: mysql reasonable: true support-methods-arguments: truereasonable开启后当前端传的页码小于 1 时自动查第一页大于总页数时自动查最后一页对用户体验很友好。实际调用分页的写法一定要牢记这个顺序Override public PageInfoWorkOrderVO selectWorkOrderPage(WorkOrderQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); ListWorkOrderVO list workOrderMapper.selectWorkOrderPage(query); return new PageInfo(list); }PageHelper.startPage()之后的第一个查询会被拦截并自动加上limit所以中间不能插入其它 SQL 或业务逻辑。返回时用PageInfo包装不要直接返回List否则前端拿不到total总条数。还有一个小细节不要在for循环里调用PageHelper.startPage()因为它是基于线程本地变量实现的循环里调用会造成拦截错乱统计接口的结果经常莫名其妙少数据。遇到循环查分页应该先查出主表 ID 集合再一次性批量查询明细。3.3 动态 SQL 在复杂生产查询中的作用工单查询往往是多条件的比如想查“3 月份裁剪车间张三做过哪些款、状态不是已完成的工单”。这种场景用动态 SQL 最合适。我在 Mapper XML 里会这样写select idselectWorkOrderPage resultTypecom.company.garment.dto.WorkOrderVO SELECT wo.id, wo.work_order_no, wo.style_code, wo.status, e.employee_name FROM work_order wo LEFT JOIN employee e ON wo.employee_id e.id where if testquery.status ! null AND wo.status #{query.status} /if if testquery.styleCode ! null and query.styleCode ! AND wo.style_code LIKE CONCAT(%, #{query.styleCode}, %) /if if testquery.workshop ! null and query.workshop ! AND wo.workshop #{query.workshop} /if if testquery.startDate ! null AND wo.plan_date gt; #{query.startDate} /if if testquery.endDate ! null AND wo.plan_date lt; #{query.endDate} /if /where ORDER BY wo.plan_date DESC /select这里有几个细节要说明。where标签会自动处理第一个条件前面的AND比手写where 11更干净。日期比较的和必须转义成gt;和lt;否则 XML 解析会报错。LEFT JOIN而不是INNER JOIN是因为工单可能暂时没有绑定员工如果内连接查这条工单就直接消失了业务上不能接受。像这种多条件查询用 MyBatis 手写 SQL 的灵活度是 JPA 比不了的这也是我在这个项目里保留 XML Mapper 的重要原因。3.4 登录、权限和统一返回结构后台管理系统的登录不能只做一个用户名密码查询。我用 JWT 生成 token用户登录成功后返回 token前端存放在 Pinia 和 localStorage 里后续请求在Authorization头带上Bearer token。后端用一个拦截器校验 token同时在数据库中查询当前用户角色来决定某个接口是否可访问。密码存储不用明文使用 BCrypt 加密即使数据库泄露也不能直接反推出密码。统一的返回结构也很关键。后端所有接口都返回{ code: 0, message: success, data: ... }这种格式code 非 0 表示失败。为了做到这一点我会把Result类放在 common 包里所有 controller 返回Result.success(data)或Result.error(code, msg)。另外再配合RestControllerAdvice做全局异常处理像参数校验失败、业务异常、未知异常都转成统一返回结构前端拦截器只需要判断 code 就能统一提示不需要每个接口各自写错误处理。4. Vue3 前端页面与前后端连接4.1 用 Vite 初始化 Vue3 工程并接入组件库前端部分我用 Vite 创建项目而不是老的 vue-cli启动速度确实快很多。命令非常简单npm create vitelatest garment-ui -- --template vue cd garment-ui npm install npm install element-plus axios pinia vue-router npm install -D sassnpm install -D sass是因为 Vue3 单文件组件里如果用了style langscss必须在 devDependencies 里装 sass否则编译会直接报错。装完后在main.js里全局注册 Element Plusimport { createApp } from vue import ElementPlus from element-plus import element-plus/dist/index.css import App from ./App.vue import router from ./router import { createPinia } from pinia const app createApp(App) app.use(ElementPlus) app.use(router) app.use(createPinia()) app.mount(#app)配置 UI 组件库时我做了一个取舍后台管理系统页面不多组件全量引入更省事开发也更快。如果项目将来变得非常大再改成按需引入或者 unplugin-vue-components 自动按需引入也来得及。前期不要在这种地方过度优化。4.2 Axios 请求封装和统一状态处理前端请求不能每个页面写一遍 axios。我会在src/utils/request.js里统一封装一个实例核心是请求拦截器和响应拦截器import axios from axios import { ElMessage } from element-plus import { useUserStore } from /store/user import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer ${userStore.token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 0) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } if (res.code 401) { userStore.resetToken() router.push(/login) } return res }, error { ElMessage.error(error.message || 请求失败) return Promise.reject(error) } ) export default request这个封装的价值在于业务页面里只需要关心成功后的数据错误提示、token 失效跳转都在拦截器统一处理。要注意在拦截器里使用 Pinia 之前一定要确保useUserStore()是在 Pinia 实例注册之后调用不然会报“get active pinia”的错误。如果你想从自定义接口导出导出时把实例返回不需要通过this访问。4.3 订单列表和工单看板页面的实现思路服装生产管理系统前端的核心页面可以分成两类一类是订单列表典型的“搜索表单 表格 分页”另一类是工单看板用卡片分组展示不同状态的工单让车间主管一眼看到哪些在排产、哪些在生产、哪些已完成。订单列表页我习惯用ref定义查询条件和列表数据用reactive定义分页参数。请求方法大概是这样const queryForm ref({ keyword: , orderStatus: null }) const tableData ref([]) const pageInfo reactive({ pageNum: 1, pageSize: 10, total: 0 }) const fetchList async () { const res await request.get(/order/page, { params: { ...queryForm.value, pageNum: pageInfo.pageNum, pageSize: pageInfo.pageSize } }) tableData.value res.data.list pageInfo.total res.data.total }这里必须提醒一下 Vue3 的响应式陷阱从 Pinia 的 store 里解构出来的token、userInfo如果不经过storeToRefs转换可能会丢失响应式导致页面字段展示不会自动更新。同理如果是reactive对象不要直接整体重新赋值比如pageInfo res.data这样会让 pageInfo 变成普通对象正确做法是Object.assign(pageInfo, res.data)。工单看板页面则更依赖状态筛选。我用status作为 Tab 切换条件再通过computed把工单按状态分组。Vue3 的computed比 Vue2 更清晰只要把分组逻辑写成一个纯函数UI 就自动根据数据变化刷新。前端部分不用做太多状态管理核心是保证接口数据源正确页面展示自然稳定。4.4 开发环境跨域代理和接口路径约定前后端分离开发时最常见的一个问题是跨域。浏览器直接访问localhost:5173后端是localhost:8080端口不同就触发了跨域。最省事的解决方式不是在后端开 CORS而是让前端 Vite 启动一个代理。在vite.config.js里配置export default defineConfig({ server: { host: 0.0.0.0, port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/order/page会被代理到http://localhost:8080/api/order/page浏览器里看起来是同源请求不会出现跨域报错。路径上我建议后端接口统一加/api前缀。这个前缀从开发环境一直保留到生产环境Nginx 做反向代理时只需要匹配/api就能把请求转发给后端后端也不需要额外再做一个 rewrite省掉不少麻烦。5. 从源码到部署环境准备和疑难问题排查5.1 MySQL 安装与初始化系统数据库我见过很多源码跑不起来的例子最后都卡在 MySQL 安装这一关。Windows 上建议直接去 MySQL 官网下载 MSI 安装包一路默认就行装的时候选择utf8mb4字符集同时把 root 密码记好。Linux 上用 apt 或者 yum 安装后要手动初始化注意设置环境变量。比如 MySQL 安装在/usr/local/mysql下面时需要编辑/etc/profile加入export PATH$PATH:/usr/local/mysql/bin然后执行source /etc/profile才能直接在命令行敲mysql。初始化项目时先从源码里的sql目录找到初始化脚本执行mysql -uroot -p sql/garment.sql如果提示命令找不到先确认 MySQL 服务有没有启动。Windows 可以在服务管理器里看MySQL80服务状态Linux 用systemctl status mysqld。账号连不上时优先检查 root 密码是否复制错了以及 MySQL 8 默认认证插件是不是caching_sha2_password连接参数里尽量加上allowPublicKeyRetrievaltrue。5.2 项目启动高频问题速查表我把这个系统前后端联调阶段容易遇到的问题整理成了一张速查表部署和二次开发的时候可以直接对照排查现象主要原因解决办法SpringBoot 启动报 Failed to configure DataSource数据源配置缺失或 MySQL 服务没启动检查 application.yml 的 url、username、password确认 MySQL 已启动接口报 Invalid bound statementMapper XML 没找到或 namespace 写错检查 mapper-locations 路径、namespace 是否等于 Mapper 接口全限定名MyBatis 查询返回字段全是 null驼峰映射没开启在 yml 里配置 map-underscore-to-camel-case: true前端 npm install 报 ERESOLVENode 版本和依赖 peerDependencies 冲突用 npm install --legacy-peer-deps 或降低 Node 版本登录后请求接口 401token 名称不一致或请求头没带上前端检查拦截器 Authorization 格式后端检查 token 解析逻辑页面刷新 404Vue Router history 模式没有 fallbackNginx 配置 try_files $uri $uri/ /index.html这张表里的问题基本覆盖了 80% 的“部署别人的源码跑不起来”的场景。很多时候不是代码有问题而是环境没对齐。所以配置参数、Node 版本、MySQL 版本最好都按 README 里的要求来。5.3 前后端打包和 Nginx 部署开发完成后部署到服务器思路很清晰后端打成可执行 jar前端打成静态文件Nginx 提供静态服务并反向代理接口。后端先在 pom.xml 所在目录执行mvn clean package -DskipTests生成target/garment-system.jar后用java -jar garment-system.jar启动。前端执行npm run build得到dist目录。把dist里的文件上传到服务器某个目录比如/opt/garment-ui/dist然后在 Nginx 配置里增加server块server { listen 80; server_name your-domain.com; root /opt/garment-ui/dist; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }这里最关键的try_files $uri $uri/ /index.html;是给 Vue Router 的 history 模式用的。如果缺失用户刷新订单页就会 404。location /api/里的proxy_pass注意不要漏掉 URI 部分的/api/否则后端收到的路径会少一段和开发环境的代理不一致。6. 二次开发建议和我的实操体会6.1 怎么把源码快速变成自己的项目拿到这套源码后不要一上来就到处改代码。我建议按下面三步走。第一步先把工程结构跑通数据库导入、前端启动、后端启动至少能登录进去看到菜单。第二步找一个最简单的模块深入读一遍比如“订单列表查询”从前端接口请求到 controller 再到 service 再到 mapper XML把一条完整调用链读懂。第三步再按相同模式添加一个自己的模块比如“车间设备管理”走一遍建表、写实体、写 Mapper、写 Service、写 Controller、写前端页面的流程。改包名和数据库名时要注意的地方很多。Java 包名改了Mapper XML 里的 namespace 和 resultType 也要跟着改数据库名改了application.yml 里的 url 要改前端里若有大写字母的接口地址也要全局搜索修改。这些全局替换操作最好用 IDE 的“在文件中替换”功能不要手动一个个改不然很容易漏掉某个 XML 节点导致接口报错。6.2 这个系统后面可以扩展的方向服装生产管理系统继续往下做有几个方向很自然。第一是把字典数据、用户 token、物料基础信息放到 Redis 缓存减少 MySQL 压力。第二是用消息队列推送生产进度事件比如工单完工后通知计件模块自动结算工资。第三是接扫码报工员工在车间用 PDA 扫工单码上报工序数量后端接收后更新产量效率比手工填写高很多。第四是给多厂区场景加一层数据权限不同账号只能看自己车间的数据。第五是增加 ECharts 生产看板把每天的产量、合格率、订单交付情况做成可视化图表。缓存这里我要多提一句MyBatis 的一级缓存默认是开启的同一个 SqlSession 内重复查询会命中缓存二级缓存要手动配置但多表关联查询用了二级缓存可能会出现脏数据因为一张表被多表 SQL 关联时缓存失效策略不一定覆盖到。我的建议是这个项目里只对字典表、款号档案这类低频更新数据开二级缓存订单、工单、报工这类高频变更数据不要开避免缓存与数据库不一致。6.3 最后分享几个我实际踩过的坑这类生产管理系统的坑往往不是在写代码阶段爆发的而是在改需求的时候。最初我设计订单表时只留了一个“订单状态”字段以为一个状态能贯穿全过程。结果后来需要区分“生产已完成但库存还没全部入库”的场景只能往表里加字段还不得不重写一堆判断逻辑。第二次我直接把状态拆成订单状态、生产状态、库存状态三个状态在 Service 层维护后面改需求就舒服很多。还有一个性能上的教训。分页列表接口如果一下子关联七八张表数据量超过几万条后响应时间会非常难看。我现在做这类报表查询习惯是先查主表的主键 ID 和分页数据再根据主键批量查关联明细最后在 Java 里组装。虽然代码多写了几行但数据库压力小很多用户体验也更稳。暂时先说到这里。这套系统的价值不在于代码有多花哨而在于它用一套相对传统的 Java 技术栈把一个真实行业的管理流程落了地。如果你正在准备 Java 项目经验或者在找前后端分离的管理系统源码作参考可以先从数据库建模和工单状态流转这两个角度反复看几遍理解透了再去改代码整个项目就会变得非常顺。