企业级私人西服定制管理系统：从业务建模到落地的完整复盘
做定制西装生意的人大概都体会过那种痛：量体数据记在本子上，面料色卡靠脑子记，订单排期靠微信聊天记录，客户回访随缘。店一开大，量体师、版师、车间、销售各管一摊，信息断层是常态，交期延误是偶然中的必然。这套基于 SpringBoot + Vue + MyBatis + MySQL 的企业级私人西服定制管理系统，就是把“量体-制版-裁剪-缝制-试穿-交付”这条长链条收拢到一个平台里，用代码把老师傅脑子里的经验变成公司可沉淀的资产。
项目源码完整，前端用 Vue 生态做单页应用，后端基于 SpringBoot 提供 RESTful 接口，持久层走 MyBatis 的灵活 SQL 映射，数据落在 MySQL 里。它解决的并不是“有没有一套软件管订单”这种伪需求，而是解决“定制业务怎么用软件管才不别扭”的真问题——因为西服定制的核心不是订单流程，而是版型数据、量体数据和面料数据这三类非结构化信息的结构化存储与流转。
这篇文章不打算做成平平淡淡的项目介绍，我会把整个系统的设计拆解、数据库建模思路、关键业务实现、部署踩坑全部掰开揉碎，把一个定制管理系统从零到落地过程中最值得抄作业的部分完整呈现。适合正在做类似管理系统开发的人、想学习 SpringBoot + Vue 全栈项目的同学，以及准备把定制业务数字化的从业者参考。
1. 项目整体设计与业务建模思路
1.1 定制业务的核心流程拆解
如果把传统定制店的一天画成流程图，你会发现大部分时间花在了“问”和“找”上：销售问量体师客户上次的尺寸，量体师找面料商问库存，版师问车间做到哪一步了。这套系统做的第一件事，就是把这些问题全部固化成数据流。
业务主链路是标准的六段式：客户建档、量体数据录入、面料选择、下单排期、制作进度跟踪、交付回访。但定制行业有个特殊点，每一段都附着大量“非标”信息。比如量体数据不只是胸围腰围臀围这几个数字，还包括客户体型特征（溜肩、驼背、凸肚）、穿衣习惯（是否喜欢垫肩）、甚至左右肩膀高度差这种细节。面料选择也不只是选一块布，还要记录色卡编号、克重、缩水率、库存余量。这些信息在普通进销存系统里根本没有地方放，但在定制业务里，恰恰是最值钱的部分。
系统在设计时遵循了一个原则：主流程走标准订单模型，非标信息用扩展数据表承接。订单主表只存客户ID、量体ID、面料ID、价格、交期等核心字段，量体数据单独建表、面料数据单独建表，通过外键关联。这样既保证了主流程的清爽，也给非标信息留足了空间。
1.2 为什么选择这种模块划分方式
很多管理系统喜欢把模块划得很细，客户管理、订单管理、库存管理、财务管理、报表管理……每个模块一个菜单，看起来功能齐全，但使用起来很割裂。这套系统没有走这条路，它把模块划成客户全生命周期、定制业务流、基础数据维护三大块，每块内部再做纵向延伸。
客户全生命周期模块不只管客户联系方式，而是把量体记录、历史订单、偏好信息（面料偏好、版型偏好、价格敏感度）全部挂到客户档案下。销售打开一个客户页面，能看到这个客户三年前第一次定制时的完整量体数据，也能看到上一次调整了哪些部位的尺寸。这种“以客户为中心”的数据组织方式，对定制业务来说比“以订单为中心”高效得多，因为复购和转介绍是定制行业的主要收入来源，客户档案的完整度直接决定销售跟进质量。
定制业务流模块则是把量体、面料、制版、缝制、试穿、交付串成一条状态流。每个环节有明确的操作人和时间记录，状态流转通过后端接口严格控制，不允许跳步。比如量体数据没录入完成，订单就不能进入制版环节。这种设计看起来死板，但在定制业务里是必要的，因为每一步都依赖上一步的输出，跳步意味着返工。
基础数据维护模块管的是面料库、版型库、工艺库。面料库要维护供应商、色卡号、成分、克重、库存；版型库要维护版型编号、适用体型、调整规则；工艺库要维护工艺标准、工时、难度系数。这三个基础库撑起了系统的“专业度”，也是后期做产能估算和成本核算的数据基础。
1.3 这套架构解决的核心问题
管理系统的价值从来不在于“有功能”，而在于“功能是否贴合业务”。拿量体数据管理来举例，传统做法是纸质记录单，量体师在单子上画人体示意图，标注各部位尺寸。数据进了系统之后，如果只是把数字搬进去，那系统就只是个电子档案柜，没有真正提升效率。
这套系统做了一个很聪明的设计：量体数据表支持部位维度扩展。系统内置了常规量体部位（颈围、胸围、中腰、裤腰、臀围、肩宽、袖长、衣长、裤长等），同时允许量体师按客户体型差异追加自定义部位。西服定制的经验是“一人一版”，每个客户的体型都有自己的特殊性，比如有些人左右臂长差1.5厘米，有些人背厚需要特加，这些信息必须能记录在案，并且在制版环节能够直接调取。这个设计真正解决了“非标数据难以标准化”的行业痛点。
同时，权限控制也是这套系统值得拿出来说的部分。量体师只能看到量体模块和订单制作模块，销售看不到成本价，财务只能看结算数据，版师只有制版相关模块的读写权限。定制行业员工流失率不低，一套严格的权限体系能防止核心数据（尤其是版型数据和客户数据）被随意导出。
2. 前端Vue实现与交互设计要点
2.1 基于Vue的页面组织方式
前端基于 Vue 生态构建，使用 Vue Router 做单页应用路由管理。整个前端按业务模块拆分成多个视图组件，配合 Vuex 做全局状态管理。我在实际开发中的一个体悟是，定制管理系统这种偏重型业务系统，前端最大的挑战不是页面多，而是状态共享。
比如客户详情页里嵌着订单列表、量体记录、面料偏好三个子模块，用户在一个子模块里操作后，其他两个子模块的数据需要联动刷新。如果用纯组件 Props 传递，代码会变得非常绕；用 Vuex 做全局状态同步，数据流向就清晰多了。系统在 Vuex 里维护了当前客户、当前订单、当前量体记录三个核心状态对象，所有页面组件都从 Store 里取数据，任何模块的数据变更都走 Action 提交 Mutation，保证数据一致性。
菜单权限方面，前端配合后端返回的角色权限码动态生成路由表。用户登录后，后端一次性返回该用户可访问的模块列表，前端用router.addRoutes动态注册路由。这里有一个容易踩的坑：动态路由在页面刷新后会丢失，必须在路由拦截器里判断 Store 中是否存在权限数据，如果不存在则重新请求后端接口获取。很多人在开发阶段发现一切正常，一刷新页面就白屏，通常是这个原因。
2.2 量体数据录入的特殊交互设计
量体数据录入是这套系统前端交互最复杂的部分，没有之一。传统表单没法满足量体记录的需求，因为量体师需要在一张人体示意图上标注各部位尺寸。系统把前端量体页面设计成左右布局：左侧是一张可交互的人体轮廓 SVG 图，右侧是与部位对应的输入表单。点击左侧人体的某个部位，右侧自动定位到对应输入框；反过来，在右侧输入框中聚焦某个部位时，左侧人体图对应部位高亮显示。
这种交互设计在开发时花了不少精力，价值也很明显：量体师在录入时不需要低头看键盘找字段，眼睛盯着人体图就能完成所有数据录入，效率和准确率都提升了。数据提交时，前端把量体数据组装成一个 JSON 数组，每个元素包含部位编码、部位名称、尺寸数值、备注说明。后端接收到 JSON 后解析入库，通过这种前端结构化的数据组织方式，实现了“一种数据结构适配所有体型差异”的目标。
2.3 订单状态可视化的实现思路
订单状态跟踪是客户和老板都最关心的功能。系统在订单列表和订单详情两个层面都做了状态可视化。列表页用标签展示当前状态（待量体、待制版、制作中、待试穿、已完成、已交付），颜色区分；详情页用步骤条组件展示完整业务流程进度，并标注每个节点的完成时间和操作人。
这里分享一个开发经验：不要用枚举值硬编码在前端做状态映射。系统在后端定义了一个状态码字典接口，前端通过字典接口获取状态码对应的名称、样式类、排序值。这样后续如果业务流程增加新状态，不需要改前端代码，后端字典加一条数据即可。这种“数据驱动界面”的思路，对这个系统后期维护是极其友好的。试想一下，如果新增一个“二次返修”状态，硬编码的方式要找到所有状态判断的代码逐一修改，很容易漏改。
3. 后端SpringBoot与MyBatis的深度配合
3.1 后端模块化设计与事务控制
后端基于 SpringBoot 构建，按业务域拆包：customer（客户模块）、order（订单模块）、measurement（量体模块）、fabric（面料模块）、system（系统管理模块）。各模块内部再按controller、service、mapper、entity四层组织。这种分包方式在实际开发中很好用，团队分工时可以按模块分人，互不干扰。
SpringBoot 版本选型上，建议直接用 2.7.x 系列，不要用 3.x。很多人看到新版本就想用，但 SpringBoot 3 基于 Jakarta EE，部分老牌整合组件兼容性还没完全跟上。2.7.x 配合 Spring Cloud Alibaba 也好用，部署运维资料多，踩坑容易找到解决方案。
事务控制是订单业务的核心保障。以“创建订单”这个动作为例，一次操作涉及多个表的写入：订单主表、订单明细表、量体记录绑定表、物料预留表、操作日志表。任何一步失败都会导致数据不一致。系统在 Service 层方法上加@Transactional注解，并指定回滚规则：运行时异常触发回滚，同时捕获受检异常手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()强制回滚。这里有一个很值得注意的细节：千万不要在事务方法内部用 try-catch 吞掉异常，一旦异常被捕获不抛出，事务无法感知错误就不会回滚，数据就处于半写入状态。我见过太多初级开发在这个问题上翻车。
3.2 MyBatis映射策略与SQL优化实践
MyBatis 的使用在系统中占了很重的比例，复杂的数据查询基本都是手写 SQL 在 XML 中实现，简单的增删改才用 MyBatis-Plus。这里说一下为什么坚持用 MyBatis 而不是全盘 MyBatis-Plus：定制业务系统的查询逻辑太复杂，关联表多、过滤条件动态变化，MyBatis-Plus 的 LambdaQueryWrapper 在这种场景下写出来的代码可读性很差，而且复杂的嵌套查询用条件构造器根本表达不了。手写 SQL 在 XML 里，SQL 和业务逻辑分离，DBA 审 SQL、DBA 调优都方便。
量体记录查询算是系统里最复杂的一个查询场景：需要按客户、时间范围、体型特征、部位数据等多个维度组合过滤，还要按量体时间倒序分页。MyBatis 的<where>标签配合<if>标签动态拼接 SQL，可以完美解决参数可选问题。这里有一个性能优化的关键点：量体数据表不要和订单主表做成一对多嵌套查询。如果一条订单要查出对应的量体数据，用嵌套查询会导致 N+1 问题——每条订单执行一次量体查询，订单量一大数据库就直接压力拉满。正确做法是先查订单列表，再用订单ID集合做一次IN查询把量体数据一次性取出，在 Java 内存中按订单ID分组组装。
MyBatis 的二级缓存是这个项目里争论过的一个点。系统最终策略是：基础数据字典和面料数据表开启二级缓存，订单和量体这类频繁更新的业务数据不开启。原因很简单，二级缓存的失效策略是“只要有更新操作就会清空该命名空间的所有缓存”，订单表频繁写入会导致缓存形同虚设，反而增加维护负担。基础数据表几乎不变，开启后查询性能提升明显。
3.3 代码生成器的合理使用边界
项目里配了一套基于 MyBatis Generator 的代码生成工具，但也只是用来生成最基础的 entity、mapper 接口和 XML 映射。很多团队用代码生成器恨不得把 controller、service 也全部生成出来，我觉得这是走偏了。代码生成器生成的代码有很强的模板感，一旦业务逻辑复杂起来，这些代码反而会成为负担。
实际开发中的做法是：代码生成器只负责生成数据表对应的实体类和基础 SQL 映射，业务相关的 SQL 手写追加到 XML 中，Service 层完全手写。这样能保证业务逻辑的灵活性，又不浪费代码生成器在机械重复工作上的效率优势。
3.4 前后端分离与接口设计规范
系统采用前后端完全分离的架构，前端 Vue 项目独立部署在 Nginx，后端 SpringBoot 打成 Jar 包独立运行。接口设计遵循 RESTful 风格，资源路径 + HTTP 方法语义化。比如获取客户订单列表是GET /api/customer/{id}/orders，创建量体记录是POST /api/measurement，更新订单状态是PUT /api/order/{id}/status。
统一响应结构在项目里是必须的，系统定义了Result<T>泛型类，包含code、message、data三个字段，成功code为 200，业务异常code为 4xx，系统异常code为 500。全局异常处理器用@RestControllerAdvice实现，把参数校验异常、业务异常、系统异常分别捕获，返回规范化的错误信息，避免把 Java 原始异常堆栈直接抛给前端。
这里特别强调一个安全细节：接口层面的权限校验不能只靠前端隐藏按钮。系统在后端写了拦截器，基于注解@RequiresPermission对敏感接口做二次拦截。比如更新订单交期、修改报价这类接口，即使前端页面上没有入口，恶意用户也可以通过直接调用接口来实现越权操作。后端的接口权限控制是系统安全的最后一道防线，这一层必须有。
4. 数据库设计：MySQL建模的核心细节与经验
4.1 核心表的字段设计与物理建模
数据库是整个系统的地基，设计得好不好直接决定业务能不能跑顺。系统核心表包括：customer（客户表）、measurement（量体数据表）、fabric（面料表）、fabric_inventory（面料库存表）、order（订单表）、order_process（订单流程表）、sys_user（用户表）、sys_role（角色表）、sys_permission（权限表）。
订单主表的设计有个反直觉的点：不要存客户姓名和电话，只存 customer_id。看起来多一次关联查询很麻烦，但这符合数据库第三范式，避免客户改名、换电话时需要同步修改订单表。而且客户信息变更时，历史订单应该保留当时的快照还是跟随客户变化？业务上通常选择跟随，因为定制店的客户资料都是长期维护的，不需要像电商那样按订单冻结快照。
量体数据表的设计采用了 EAV 模型（实体-属性-值）的变体。一张表存量体记录主信息（客户ID、量体师、量体时间、整体体型描述），另一张表measurement_detail存各部位明细数据，每个部位一行，包含部位编码、部位名称、尺寸值、备注。EAV 模型虽然被很多 DBA 诟病查询效率低，但在量体数据这种“每个客户要记录的部位可能不一样”的场景里是最合适的。
面料表的设计则比较多维：基础信息（名称、供应商、成分、克重、幅宽）、采编信息（色卡号、颜色名称、花型编号）、采购信息（单价、库存余量、安全库存阈值）。这里有个容易忽略的细节：面料表要存缩水率这个字段。定制西装的面料在制作前通常需要预缩水处理，缩水率直接影响版型的缩放计算，很多初做定制系统的人会漏掉这个字段，导致后续做用料计算时数据对不上。
4.2 关键索引策略与查询性能优化
索引设计是数据库性能的第一道关。系统针对高频查询场景设计了组合索引：order表的(customer_id, create_time)组合索引支撑“查客户订单列表并排序”的场景；order_process表的(order_id, process_code)组合索引支撑“按订单查流程状态”的场景；measurement_detail表的(measurement_id, part_code)组合索引支撑“按量体记录查明细”的场景。
这里有一个索引设计的原则性建议：不要在区分度低的字段上建索引。比如状态字段（status）如果只有几个值，建立单列索引基本没用；但建组合索引时，如果把状态字段放在前面的位置，反而会导致索引利用率下降。系统里订单状态是放在索引靠后的位置，把范围查询字段（create_time）放在前面，这样既支持排序也支持范围过滤。
MySQL 的版本选择上，推荐使用 5.7 或者 8.0。5.7 更稳，资料全；8.0 的窗口函数和公共表表达式写复杂统计 SQL 时特别好用。如果业务有复杂报表需求，直接上 8.0。安装时要注意字符集设置成utf8mb4，排序规则用utf8mb4_general_ci。很多人忽略这个细节，直接用默认的latin1，一旦存入中文、Emoji 或者生僻字就乱码。这个坑极易踩中。
4.3 数据字典与枚举数据的存储策略
业务系统里大量“看起来是枚举”的数据，比如订单状态、量体部位编码、面料成分类型，系统的存储策略是：有业务含义的枚举进数据库，纯技术性的枚举进代码。
举一个直观的例子。订单状态（待量体、待制版、制版中、裁剪中、缝制中、待试穿、已完成、已交付）不仅是枚举，每个状态还关联下一步可执行操作、需要提醒的角色、对应的页面样式，这种“带行为”的枚举必须存数据库，并设计成一张数据字典表，字段包含状态编码、状态名称、排序值、适用角色、样式类名。后续业务流程调整时，只改数据库不改代码。
而像性别（男/女）这类纯展示性枚举，直接在 Java 代码里定义常量即可。如果也放数据库，纯属给自己找麻烦，查询多一次 JOIN 不说，代码里还要做字典翻译，目前主流做法都是通过数据字典接口一次性拉取全院字典到前端缓存。
5. 关键功能与核心代码实现说明
5.1 动态量体表单的后端解析与存储实现
量体数据录入的前端是动态表单，提交上来的数据是 JSON 数组格式，后端要做的事就是把这个 JSON 解析并落库。系统的 Control ler 层接收一个MeasurementSaveDTO，内部包含List<MeasurementItemDTO>，每个 ITEM 有部位编码、部位名称、尺寸值、备注。Service 层先保存量体主记录获取主键ID，再遍历明细列表批量插入。
这里要特别说明“批量插入”的性能优化。如果用 for 循环单条插入，量体一次记录通常有 20-30 个部位，那就是 20-30 次数据库交互，虽然量不大，但设计不够优雅。系统用 MyBatis 的<foreach>标签实现了一条 SQL 批量插入多条明细数据，数据库交互次数从 N 次降低为 1 次，代码简洁的同时性能也更好。
量体数据的版本管理是这个系统的一个亮点。客户每次到店量体新增一条记录，不覆盖历史数据。因为定制业务里“对比历史量体数据”极其重要——版师需要知道客户这段时间体型变化，哪些部位变大了哪些变小了，才能做出更合身的版型调整。所以量体数据只新增不更新，业务上明确了这个规则，设计上就简单了。
// 量体明细批量插入的 Mapper XML 片段 <insert id="batchInsertMeasurementDetail" parameterType="list"> INSERT INTO measurement_detail (measurement_id, part_code, part_name, part_value, remark, create_time) VALUES <foreach collection="list" item="item" separator=","> (#{item.measurementId}, #{item.partCode}, #{item.partName}, #{item.partValue}, #{item.remark}, NOW()) </foreach> </insert>以上的代码片段摘取自系统 Mapper 层，是最常见的批量写入写法。需要注意 MySQL 对单条 SQL 的参数数量有限制（默认max_allowed_packet限制的是包大小，但参数占位符数量太多也会有问题），量体明细一次最多几十条，远不构成压力，可以放心用。
5.2 订单状态机的设计与实现
订单状态管理不能简单做成“一个字段 + 修改接口”，那样业务规则会散落在各处。系统的订单状态用状态机模式实现：定义状态流转规则表，明确每个状态允许跳转到哪些目标状态，以及触发跳转的前置条件。
这套设计在实际使用中非常稳。比如“待量体”状态可以流转到“待制版”，前提是量体数据已录入完整；如果量体数据缺失，后端直接抛出业务异常“当前订单缺少量体数据，无法进入制版环节”。通过状态机的严格校验，数据的完整性在业务链条上得到了保障。
订单状态变更的接口设计上也有些讲究：每次变更都要在操作日志表中记录操作人、操作时间、原状态、新状态、备注说明。这个日志在后期追溯时很有价值，比如客户打电话过来说“我之前明明说了要改袖长，为什么交付的袖子长短不对”，查操作日志就能定位到到底改没改、谁改的、什么时候改的。系统的每一步操作都有迹可循，这也是“企业级”三个字的含金量所在。
5.3 面料库存预警与订单用料计算
面料库存管理是很多定制管理系统的薄弱环节，大部分只做“入库、出库、库存查询”三个功能。这套系统增加了一个很实用的功能：按订单自动扣减面料库存，并在库存低于安全阈值时触发预警通知。
订单面料用量不是简单的一个长度数字。系统在面料表和版型表之间建立了关联——每个版型根据款式和尺码，预置了标准用料长度，然后在创建订单时结合实际体型自动计算。比如一件单排扣平驳领西装，标准用料是 1.5 米（幅宽 1.5 米面料），但如果客户体型特殊需要加放，用量会相应增加。系统实现时计算逻辑并不复杂，但背后要有足够的数据支撑，这就是前面说基础数据库重要性的原因——没有版型和面料的参数数据，这个功能就是空中楼阁。
面料库存扣减的逻辑同样要放在事务里。同时涉及库存表和订单表的写入，一旦后续流程失败，库存需要回滚。系统中面料扣减使用的是乐观锁机制，在面料库存表增加version字段，更新时比对版本号。这个机制有效防止了高并发场景下的超卖——两个订单同时看到库存还剩 3 米，提交时只有一个能成功扣减，另一个会得到版本冲突提示。定制行业的订单量不会像电商那么高，但乐观锁这种防患于未然的机制还是很有必要。
6. 部署实战与环境搭建记录
6.1 本地开发环境的搭建流程
拿到这套源码之后，第一步是在本地把环境跑起来。前端需要 Node.js 环境，建议 16.x 或 18.x LTS 版本。安装完 Node 后，在 Vue 项目目录下执行npm install安装依赖。
这里有一个非常常见的坑：npm install 报错 ERR! code ERESOLVE。这个问题通常发生在 Node 版本过高的环境里，因为 npm 7+ 的依赖解析策略更严格，项目里某些旧的传递依赖会触发冲突。解决办法是加--legacy-peer-deps参数，或者用npm install --registry=https://registry.npmmirror.com换用国内镜像，速度也快，实测下来遇到问题不多。
后端环境的搭建更直白。确认 JDK 版本（这个项目用的是 Java 8 或 11，推荐用 8，稳定兼容 SpringBoot 2.x）, 安装 Maven 3.6+，修改application.yml中的 MySQL 连接参数指向本地数据库。首次启动时后端会自动执行schema.sql建表脚本（如配置了spring.sql.init.mode=always），没有的话需要手动导入项目附带的 SQL 文件。
6.2 生产部署的一整套操作流程
生产环境部署分为前端和后端两部分。前端 Vue 项目构建命令是npm run build，产物是 dist 目录下的静态文件，把这些文件上传到 Nginx 的 html 目录，并配置 Nginx 将 API 请求反向代理到后端服务端口。这一步的关键是Nginx 的 SPA 路由配置：需要配置try_files $uri $uri/ /index.html;，否则刷新 Vue Router 的 history 模式路由时会报 404 错误。
后端的部署方式是打成 Jar 包发布。执行mvn clean package得到可执行的 Jar，上传到服务器后用nohup java -jar xxx.jar > app.log 2>&1 &启动。不要直接把 Jar 包丢在一个裸目录里跑，建议用systemd配置成服务，这样开机自动启动、崩溃自动重启、日志集中管理，运维成本大幅降低。
生产环境启动时要注意 JVM 参数配置：-Xms和-Xmx根据服务器内存合理分配，通常 2G 内存的服务器配-Xms512m -Xmx1024m就够这套系统跑了。数据库连接池 HikariCP 的maximum-pool-size不要默认 10，定制店的日常并发并不会太高，5 到 8 个连接足够了，避免浪费数据库资源。
6.3 部署过程中最值钱的踩坑经验
部署过程中踩坑最多的就是 MySQL 的 SSL 连接问题。Java 8 及以上版本连接 MySQL 时默认会尝试 SSL 加密，但很多本地或内网环境下的 MySQL 并没有正确配置 SSL 证书，就会报错Communications link failure。解决办法非常简单：在数据库连接 URL 上加上useSSL=false&serverTimezone=Asia/Shanghai参数。
另一个非常常见的问题是时区问题。MySQL 5.7 默认时区是系统时区，而 Java 应用程序默认用 JVM 时区，两边对不上会出现“数据存进去时间差了 8 小时”的问题。在 JDBC URL 上显式指定serverTimezone=Asia/Shanghai就能彻底解决。这类“看似诡异”的时间错乱问题，在那个时间点排查确是很费劲的。
还有一个容易忽视的问题是文件上传大小限制。定制系统里客户照片、体型照片、面料实拍图的上传是很常见的需求，SpringBoot 默认的上传文件大小限制只有 1MB，生产环境配置中必须手动调大：
spring: servlet: multipart: max-file-size: 20MB max-request-size: 50MB不配置的话，上传稍微大一点的面料图片就直接抛异常，前端只看到一个莫名其妙的报错提示。这类问题定位起来比代码逻辑 bug 费劲多了，因为报错信息提示不利于快速定位。把这些“环境坑”记住，部署带来的麻烦能少了一大半。
7. 常见问题排查与运维心得
7.1 接口正常但页面空白的问题定位路径
前端页面空白是在管理系统开发中最高频的问题之一，定位路径是固定的：先看浏览器控制台有没有报错；没报错就看 Network 里接口是否返回；接口正常就看 Vuex 里数据是否成功写入；数据有了还空白，大概率是组件渲染条件没满足。
我用这套系统排查过几次空白页面问题，最终的根因往往出在一个很隐蔽的地方：接口数据返回后，某个字段的值为null，而页面的 JS 代码里直接访问了res.data.list.length，忽略了 list 本身为null的情况，导致异常被抛出、组件渲染中断。页面完全空白，没有任何提示。这个问题的通用解法是写好默认值或空值兜底逻辑，在接口返回数据结构不稳定时尤其重要。
提一个容易忽略的点：Vue 项目验收前建议把所有console.log都删掉或用eslint做拦截。很多人习惯用 console.log 调试，上线后忘了清理，虽然不是致命问题，但在控制台里刷屏的信息会影响后续真正问题的排查。
7.2 数据库连接池耗尽问题的应对措施
运行一段时间后，系统可能会突然出现类似Connection is not available, request timed out的报错，这是典型的数据库连接池耗尽。本系统出现这个问题的原因是某处代码从连接池拿连接之后没有释放。
特别容易发生连接泄露的场景就是事务方法里嵌套了异步操作。比如订单完成后需要发送短信通知，有人会把发送逻辑写在事务方法里，并且在方法内部用new Thread或者线程池异步执行。这个异步线程如果也用了数据库操作，就会从连接池再拿一个连接，而这时事务线程还没提交释放连接，连接池很容易被占满。正确做法是把短信发送、消息推送这类非核心操作放到事务提交之后再异步执行，或者用 MQ 消息解耦。
排查连接池泄露有个很管用的手段：开启 HikariCP 的泄漏检测参数leakDetectionThreshold: 60000，配置后连接从连接池拿出去超过 60 秒没有被归还，日志里就会打印告警信息和具体调用栈，直接定位到泄露的代码路径。生产环境开启这个参数不会对性能有太大影响，强烈建议所有 SpringBoot 项目都配上。
7.3 容器内运行与日志管理的建议
有条件的话建议把前后端都容器化部署，Docker Compose 一键编排，MySQL、后端服务、前端 Nginx、Redis（可选）一起拉起来。用 Docker 的好处不只是部署方便，更重要的是环境一致性——开发环境、测试环境、生产环境跑的都是一样的镜像，不会再出现“本地好好的上线就崩”的情况。
镜像构建时要注意分层缓存的设计，把依赖层和代码层分开。前端的 Dockerfile 最好分多阶段构建：第一阶段用 Node 镜像构建静态资源，第二阶段用 Nginx 镜像拷贝产物。这样每次改代码构建时，依赖层可以直接命中缓存，构建速度快很多。后端也同理，Maven 构建阶段用mvn dependency:go-offline把依赖提前下载好，后面代码层改动时能快速构建出新镜像。
日志管理方面，容器化部署后用docker logs查看是基本功，但建议把日志集中收集起来。可以使用 ELK 栈或者轻量一点的方案（比如 Loki + Grafana）。对于管理系统而言，甚至不需要这么重的链路，用logrotate定期归档后端日志文件就够了——但要注意日志切分和保留策略，避免无限制增长把磁盘塞满。
8. 关于这套系统的几点售后体会和建议
系统开发到上线运行，我有几个体会想分享出来。
第一个体会是：定制行业管理系统最难的不是技术选型，而是把老师傅脑子里的隐性知识转换成数据结构。跟十几年的量体师聊一次，收获远超读十篇技术文档。量体时老师傅会关注很多系统里没设计到的点：客户挺胸还是含胸，肩膀是端肩还是溜肩，这些都会影响版型调整。如果不深入业务现场做调研，设计出来的量体表单就只是“纸上谈兵”，看着标准但实际用不起来。
第二个体会是：从前端到后端、从数据库到部署，全栈能力在一个小团队里真的很重要。管理系统开发不像做算法或中间件那样需要某一个方向的深度钻研，它更需要的是全局视野。任何一个环节出现短板，交付质量和开发效率都会被拖累。前端交互不顺手，后端接口设计再合理也没用；数据库字段设计不合理，后端 SQL 写得再妙也只能勉强支撑。
第三个体会是：持续迭代才是体现这套系统价值的地方。业务是活的，需求是变的。系统首次交付只是一个开始，之后不断有新的需求进来——增加新报表、调整审批流程、对接微信通知、增加数据分析看板。底子打好了，后面的迭代才能快速稳健。
如果你正在做类似的管理系统，或者准备用 SpringBoot + Vue + MyBatis + MySQL 这套技术栈搭建业务系统，这套定制管理系统的源码和设计思路应该能帮你少走不少弯路。重点去研究它的量体数据建模方式、订单状态机设计、面料库存联动逻辑这三个核心部分，把这些吃透了，你就不只是会写 CRUD 的管理系统，而是真正理解了“业务系统”这三个字的分量。
