SpringBoot+Vue+MyBatis企业级洗衣店订单管理系统实战解析

1. 项目背景与核心需求拆解

如果说要选一个最适合拿来练手、又最能体现全栈能力的业务系统，洗衣店订单管理系统绝对算一个。业务链路完整、状态流转清晰、权限划分明确，还牵扯到会员、优惠、库存、对账这些真实商业场景。我之前帮一家连锁洗衣门店做过类似的信息化改造，回头再看这类系统的设计，其实有很多共通的思路可以聊。

这套基于 SpringBoot + Vue + MyBatis + MySQL 的洗衣店订单管理系统，定位是“企业级”，意味着它不只是把订单增删改查做出来那么简单。你至少需要面对几个硬指标：多门店或工位的数据隔离、订单状态的严谨流转、会员储值和计次的账务安全、高峰期并发下单时数据库的稳定性。如果把源码下载下来只当学习 Demo 看，那格局小了——它的价值在于给了一套可以直接落地的企业应用范式。

从技术选型上来说，SpringBoot 负责后端接口与业务逻辑，Vue 承担前端交互与状态管理，MyBatis 作为持久层框架操作 MySQL，这套组合是当前 Java 全栈开发里最主流、招人最多的技术栈。对新手而言，它的学习曲线比 Spring Cloud 微服务体系平滑得多；对团队而言，它足够轻量，部署只需要打包一个 Jar 包加一份前端静态资源，不需要引入额外的中间件。

我见过很多人在拿到这类源码后，第一反应是赶紧跑起来看看界面长什么样。但我个人的建议是，先别急着启动，而是按下面这个思路去拆：

1. 先理清业务：这个系统里到底有哪些角色？每种角色关心什么数据？
2. 再看表结构：订单、会员、商品、库存这些核心表之间的关系是什么？状态字段怎么设计的？
3. 然后看权限：登录之后，用户能访问哪些接口，靠什么机制控制？
4. 最后才是跑起来，从前台下单到后台派单，完整走一遍流程。

从我个人经验来看，源码学习最容易踩的坑就是“跑起来之后不知道点哪里”，最后只学会了启动项目。所以这篇文章我会带着你把业务模型、数据库设计、权限体系、订单流转这些核心环节逐一拆开，顺便把我实际开发中遇到的坑也交代清楚。

2. 总体架构设计思路解析

2.1 前后端分离架构的特点

那为什么这类系统普遍采用前后端分离？不只因为主流，更因为它有实打实的好处——前端和后端可以独立开发、独立部署、独立扩容。我开发的时候感受最明显的一点是，洗衣店的前台收银界面和后端管理后台其实是两类完全不同的交互场景：收银员需要大按钮、快速操作、防止误触，而店长需要看报表、处理异常订单。如果揉在一个传统模板项目里，改一处前端逻辑就容易牵一发动全身。

SpringBoot 在这一架构里的职责很纯粹：只提供 RESTful API，不关心页面长什么样。它负责接收前端的 JSON 请求，调用 Service 层处理业务，再通过 MyBatis 与 MySQL 交互，最终把结果以 JSON 格式返回。前端 Vue 项目则通过 axios 这类 HTTP 客户端请求这些接口，拿到数据后再渲染到页面上。

这样做还有一个好处：同一套后端接口，以后如果要扩展小程序端或者自助洗衣柜终端，前端部分完全可以单独新增项目，后端只需要补充必要的接口和鉴权策略。从这个角度看，这套架构本身就是面向未来扩展的。

2.2 为什么选 MyBatis 而不是 MyBatis-Plus 或 JPA

这个可能是很多人拿到源码后会问的第一个问题：既然 MyBatis-Plus 能省掉大量单表 CRUD 的 SQL，为什么不直接用？我的理解是，MyBatis 原生方式在复杂查询、多表关联、SQL 调优场景下，掌控力是最强的。洗衣店订单系统里典型的复杂查询包括：按时间段统计门店营业额、查询会员剩余次数和储值余额、订单和订单明细一对多关联查询，这些用原生 SQL 写出来，哪里该建索引、哪里需要子查询、哪里需要连表，一眼就能看明白。

再看 JPA（Java Persistence API，Java 持久层规范），它的自动建表和 Hibernate 缓存机制在学习阶段确实省事，但在数据量上来之后，SQL 自动生成带来的不可控性会成为排查问题的障碍。举个例子：JPA 的 N+1 查询问题（即查询主表后又逐条查询从表，导致大量 SQL 请求），如果没有深入理解，线上环境会出现大量慢查询，而 MyBatis 的连接查询和懒加载机制完全由开发者通过 XML 控制，性能是可控的。

在这套系统里，MyBatis 还有一个优势是动态 SQL。洗衣店的订单查询条件非常多：订单号模糊查询、手机号精确匹配、时间段范围、状态多选、是否加急，这些条件组合起来，用 <if> 和 <where> 标签可以优雅地拼接 SQL，既能满足不同组合的筛选需求，又能避免代码里出现大量 if-else 拼接字符串的情况。

2.3 整系统分层：Controller 只做转发，Service 只做业务

我见过太多项目出问题，根源都在分层不清晰。有的把 SQL 写在 Controller 里，有的在 Service 里塞了一堆 HTTP 请求逻辑，时间一长代码就变成了“屎山”。这套系统的分层比较标准，可以参考这种风格：

• Controller 层（接口层）：只负责接收参数、调用 Service、返回统一结构。参数校验放在这一层，不通过就直接返回错误提示，原则上不写任何业务代码。
• Service 层（业务层）：承载业务规则，比如判断会员余额是否足够、计算订单金额和优惠、生成取件码、修改订单状态等。事务注解加在 Service 方法上。
• Mapper 层（持久层）：定义数据库操作方法，对应的 XML 文件里写 SQL。Mapper 接口只做数据访问，不做任何业务判断。
• entity/domain 层（实体层）：与数据库表结构对应的 Java 对象，字段名和表字段一一对应（遵循驼峰命名转换规则）。
• VO/DTO 层：用于接口数据传输的对象，VO（视图对象）负责向前端输出，DTO（数据传输对象）负责接收前端传入，避免直接把实体类暴露给前端接口，防止带出密码等敏感字段。

我在实际开发中，很早就体会过分层混乱的坑。有一次在 Controller 里既查了库存又写了订单，还顺手改了会员的积分，结果某天业务调整要限制积分发放次数，我翻了半天才在 Controller 层里找到这段逻辑——它根本不该出现在那里。所以这个系统的分层设计，从教学角度给了一个相当标准的参考，值得仔细品味。

3. 核心模块拆解：从下单到取衣的完整链路

3.1 登录认证与权限控制的设计

洗衣店系统的用户角色一般分三种：系统管理员、店长/前台收银员、会员（C 端用户）。如果是单门店版本，内部员工和会员的权限边界会比较清晰：员工能访问管理后台，会员只能在小程序或 H5 端查看自己的订单、余额和卡券。

权限控制这块，合理的方式是用 Token（访问令牌）机制做登录态管理。用户输入账号密码后，后端校验通过，生成一个带有效期的 Token 返回给前端。前端把它存在本地（通常是 localStorage），之后每次请求都在 Header 里带上，后端通过拦截器统一校验。这样做的好处是完全无状态，方便以后做水平扩容。

除了登录态，还要考虑接口级别的权限控制。我建议用一个权限标识（如 order:add、order:cancel、member:recharge）来标注接口，登录用户查询自己的角色权限列表，访问接口时动态比对。这样管理员可以灵活调整某个员工能做什么、不能做什么。

需要注意的坑是：不能只在前端隐藏按钮就认为安全了，所有的鉴权必须放在后端拦截器里做，因为前端的路由和按钮都可以被绕过。我做过的项目里，就遇到过有人直接在浏览器里模拟请求，绕过前端按钮调用接口下发折扣的情况，吃过亏之后，权限校验一律走后端。

3.2 订单表与状态机设计

订单是系统的心脏，表结构设计决定了系统的上限，所以要先理解订单相关的表和状态流。

订单主表的核心字段通常包括：订单号、会员 ID、下单门店、收衣人信息（姓名、电话）、衣物总件数、应收金额、实收金额、优惠金额、支付方式、支付状态、订单状态、订单备注。订单明细表记录每一件衣服，核心字段包含：订单 ID、衣物名称、品牌、颜色、瑕疵备注、服务类型（干洗/水洗/熨烫/皮具护理）、单价、数量、状态（待洗/洗涤中/已洗完/异常）。

订单状态流转是洗衣业务的关键。标准流程大概是这样：

code复制待支付 → 待取件（已付款下单成功） → 洗涤中 → 待取衣 → 已完成

在真实业务里还会加上“已取消”和“售后中”两个状态。需要细致考虑的一点是：衣物送回时，收银员要核对件数，如果发现少件或洗坏，订单要能进入异常登记流程。

状态之间不能随意跳转。比如“待取件”的订单不能直接变成“待取衣”，必须经过“洗涤中”。为了避免脏数据，实现上有两种思路：一是在 Service 层写 if 判断当前状态是否允许流转；二是建一张订单状态流转配置表，由专人维护。对于第一版上线，前者更直观可控，先把判断逻辑写清楚，等业务方有了更复杂的流程需求再上配置化也不迟。

还有一个非常实用的技术点——防重校验。开洗衣店的人一定遇到过这种场景：顾客微信支付成功了，但是因为网络延迟，前端没收到成功回调，用户多点了两下，结果创建了两个一模一样的订单。解决办法是引入幂等机制，在创建订单时传一个客户端的唯一请求号，后端在缓存或数据库里记录这个请求号是否处理过，重复就拒绝。

3.3 会员、储值与卡券业务

洗衣店对会员的黏性非常依赖储值赠送、次卡、优惠券这类运营手段，所以会员模块不是简单的用户表加积分字段，这里面的逻辑细节很值得仔细研究。

先说储值钱包的账务设计。会员表里存一个余额字段是最省事的方式，但对账的时候容易出问题。严谨的做法是储蓄余额单独建一张资金流水表，每一笔入账（充值、赠送、退款）和出账（消费抵扣）都有一条记录；会员表里的余额字段可以保留，但只是冗余展示，真正的账本数据以流水表为准。这样设计的原因是：如果系统出现 Bug 或人工误操作直接改了余额，通过流水表可以追踪到问题点，还能用于对账，即使出错也有据可查、方便撤销。

次卡或计次卡（比如“洗衣 10 次卡”）需要单独建卡项和会员持卡表。每次消费时，扣减的是次数而不是金额；次数不足时，需要支持“次数不足走余额补差价”的逻辑。这里要注意并发问题——两个收银员同时给同一个会员刷卡扣次，可能导致超扣。解决方案是 SQL 层面加条件，比如在扣减时带上 WHERE remaining_times > 0 再执行 UPDATE，利用数据库行锁避免超扣。

优惠券的设计也要考虑清楚。按使用门槛分无门槛券、满减券；按适用范围分全场通用、指定品类、指定门店。下单时前端会把可用券列表展示给用户，后端在下单接口里要重新校验券是否在有效期内、是否满足使用条件，而且一张券只能被使用一次——防止用户开了两个页面重复提交订单，把同一张券用两次。

3.4 库存与洗衣耗材管理

衣物送到店里，洗护过程中需要用到洗衣液、柔顺剂、包装袋等耗材，这些需要纳入库存管理。如果忽略这一块，到了月底会发现耗材消耗量和营业收入对不上。

这套系统中的库存模块，我建议采用“出库即扣减”的策略。比如收衣时，每件衣服默认搭配一个衣架和一个包装袋，系统自动扣减对应的耗材库存；洗涤时再按服务类型扣减洗涤剂用量。虽然实际操作中不可能精确到克，但可以设置一个“每标准件消耗量”的参数，日结时系统汇总当日耗材消耗，人工盘点差异。

库存预警是实用的功能，给每种耗材设置最低库存阈值，低于阈值就给管理员推送提醒。这里需要提醒的是：库存操作一定要记录操作日志，包括经办人、操作类型（入库/出库/盘点调整）、变化数量、操作时间，这是做库存审计的基础。

4. 数据库设计与核心表关系

4.1 核心数据表全景

由于这是企业级应用，表结构设计不能拍脑袋。我根据业务梳理出一份核心数据表清单，拿到源码后建议按这个清单对应着看：

4.2 字段类型与索引设计的关键细节

字段类型如果选错，后面改起来非常痛苦，对这个系统来说有几个字段值得特意留意。

金额字段一律用 DECIMAL(10,2)，不能使用 FLOAT 或 DOUBLE。原因很简单——洗衣店虽然单品金额不高，但累计计算时如果出现精度丢失，对账就不平，导致储值和订单金额对不上。浮点数存储会有精度问题（例如 0.1 加 0.2 并不是精确的 0.3），对金额敏感的业务是致命的。

手机号字段用 VARCHAR(20) 即可，但如果要考虑隐私脱敏显示，查询出数据后在接口层做处理，不要存加密数据——否则你在业务后台搜索会非常麻烦。

订单状态字段使用 TINYINT 存储 0-9 的数字状态码，并在代码里用常量类或枚举去定义，绝不裸写数字。比如 0：待支付、1：待取件、2：洗涤中、3：待取衣、4：已完成、5：已取消。裸写数字的坏处是，过三个月你自己都记不住 2 代表什么意思。

索引设计方面，核心查询条件要建索引。订单表的查询基本都围绕 order_no（唯一索引）、member_id（普通索引）、store_id + create_time（联合索引，用于按门店和时段统计）来走。会员表要针对 phone 做唯一索引。这里有个误区值得提醒：索引不是越多越好，因为每次写入都要更新索引，索引过多会影响写入性能，而且会占用更多磁盘空间。

4.3 金额计算与精度把控

订单金额计算涉及衣物服务单价、件数、优惠券抵扣、会员折扣、充值赠送消耗等环节。为了避免订单最后算出来的应收金额与实际支付对不上，我的建议是所有计算金额都走后端，前端只负责展示。

后端金额计算用 BigDecimal，不要用 double。BigDecimal 的初始化方式也需要注意：new BigDecimal("19.9") 是安全的，而 new BigDecimal(19.9) 可能会因为二进制浮点数表示误差拿到一个类似 19.899999... 的值。我见过很多 Java 开发在这上面吃过亏。

计算顺序可以设计为：

1. 先按订单明细计算原始总价（单价 × 数量累加）
2. 判断是否满足会员折扣条件，按折后金额向下取整（保留两位小数）
3. 判断是否使用优惠券，按门槛条件抵扣
4. 得出应收金额
5. 支付时校验支付金额与应收金额一致

每笔订单生成后，建议同时在表中冗余保存一个“原价金额”字段，因为后续要统计“优惠让利了多少”“会员贡献了多少流水”，没有原价就统计不准确。

4.4 事务与并发控制

下单是一个涉及多表写入的操作——插入订单主表、插入订单明细、扣减会员余额、核销优惠券、扣减库存。任何一个步骤失败了，前面已经写入的数据都不应该残留，否则系统就会出现脏数据。解决办法是在 Service 方法上加 @Transactional（Spring 的声明式事务），让这些操作在同一个数据库事务里执行，要么全部成功，要么全部回滚。

这里要提醒一个常见的坑：事务自调用失效。如果你把两个方法写在同一个类里，A 方法（没加事务）调用同类中的 B 方法（加了事务），B 的事务不会生效。因为 Spring 的事务是通过 AOP 代理实现的，同类内部的调用（this 调用）不会经过代理。我当时第一次遇到这个坑的时候很困惑，排查了很久才发现问题在这儿。解决办法要么是把需要事务的方法拆到另一个 Service 类中调用，要么通过 AopContext.currentProxy() 获取代理对象调自身方法，但前者更符合代码组织习惯。

在库存和会员余额这类关键扣减操作上，可以配合乐观锁。比如在会员账户表加一个 version 字段，更新时用语句：UPDATE member_account SET balance = balance - #{amount}, version = version + 1 WHERE id = #{id} AND version = #{oldVersion}，如果影响行数为 0，说明期间有其他请求改过数据，再进行重试或提示用户稍后操作。

5. 核心实操：搭建运行环境与本地启动

5.1 MySQL 安装与配置

如果本机还没有 MySQL，建议直接装 MySQL 8.x 版本，这也是当前 SpringBoot 项目最主流的配合版本。不同操作系统的安装方式有差异，在这套系统的部署文档里一般也会说明。

装完 MySQL 之后的几个必做设置：

1. 修改 root 密码，并创建专用账号，不建议业务系统直接使用 root 连接。
2. 创建数据库，字符集选择 utf8mb4，排序规则用 utf8mb4_general_ci（或者 utf8mb4_unicode_ci）。utf8mb4 能完整支持 emoji 和生僻字，这点在会员备注上体验很明显。
3. 执行 SQL 脚本，把源码中提供的初始化脚本导入。我先提醒一句：先看 SQL 文件的开头，确认是否有 CREATE DATABASE 和 USE 语句，如果默认库名和你的不一致，全局替换掉再执行。
4. 时区设置：启动报错常见的一个是 The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。这通常是因为 MySQL 时区没设为 Asia/Shanghai（东八区），解决方法是在连接参数中加 serverTimezone=Asia/Shanghai，也可以修改 MySQL 的全局时区。

我在本机复现时，安装的是 MySQL 8.0.33，使用默认的 utf8mb4 字符集，执行初始化 SQL 后，再创建一个 laundry_user 账号并授予该库所有权限。这里有个习惯值得大家参考——不要把密码写在代码里，把数据库连接配置放到 application.yml（SpringBoot 配置文件）里时注意，正式的源码中对外发布的版本一般会替换掉真实密码，自己在调试时可以填入本地密码。

5.2 SpringBoot 服务端配置与启动

后端项目在 IDEA 里打开后，先不要急着点启动，检查三处配置：

第一处是 application.yml 里的数据源配置。确认数据库地址、端口、库名、用户名、密码都正确。常见的端口默认是 3306，如果本机被占用或改过，要同步修改。连接池推荐使用 HikariCP（SpringBoot 2.x+ 默认），配置好最大连接数和连接超时时间。

第二处是 Redis 配置（如果这套系统用到了 Redis 做 Token 缓存）。如果依赖 Redis 却没有修改 Redis 地址，启动时会因为连不上 Redis 直接失败。控制台日志里会有明显的提示，照着改 spring.data.redis.host 和 port，并在本地启动一个 Redis 服务即可。

第三处是端口配置。SpringBoot 默认端口是 8080，如果本机有别的应用占用了，改 server.port 为 8081 或 9090 就行。

检查完配置后，找到启动类，直接运行 main 方法。当控制台出现 Started LaundryApplication in x.xxx seconds 时，说明后端接口已经启动完成。这时打开浏览器访问 http://localhost:8080，虽然因为前端项目还没有启动，直接访问只会进入 SpringBoot 的默认错误页或欢迎页，但这并不代表接口有问题，可以先通过 Swagger 或直接拼接 URL 的方式验证（如果项目中集成了 Knife4j 或 Swagger，访问 /doc.html 或者 /swagger-ui/index.html 就能看到接口文档）。

启动后端时遇到过依赖下载失败的情况，多半是 Maven 没有配置国内镜像源。可以在 Maven 的 settings.xml 里配置阿里云公共仓库镜像，再刷新依赖（IDEA 里点 Maven 面板的刷新按钮）。

5.3 Vue 前端环境搭建与项目启动

Vue 项目这块是好多前端新手最容易卡住的环节，因为 Node 环境和 npm 依赖处理不好会让项目直接跑不起来。

先说 Node 版本。Vue 2 项目建议 Node 14 或 16 LTS 版本，Vue 3 项目则建议 Node 16 或 18。因为 Node 版本过高有时候反而会出现 node-sass（一个需要编译原生模块的依赖包）编译失败的问题。查看当前 Node 版本可以在终端输入 node -v。如果已经安装了过高版本的 Node，建议用 nvm（Node 版本管理器）切换版本，这比反复卸载重装要方便得多。

依赖安装是整个流程最容易出问题的环节。进入 vue-admin（或前端项目根目录，具体看目录结构）后执行 npm install，你在培训机构或者很多同学那里都能听到同样的话——“npm install 就是碰运气”。其实真正的问题大多出在镜像源上，直接把 npm 源切换为淘宝镜像源，这一条就能解决 80% 的依赖安装问题：

bash复制npm config set registry https://registry.npmmirror.com/

重新执行 npm install。如果项目里用到的是 yarn，就把 npm install 替换成 yarn install，注意不要混用包管理器，避免 package-lock.json 和 yarn.lock 冲突。

依赖装完后启动开发服务器：

bash复制npm run dev

默认访问地址是 http://localhost:9527 或 http://localhost:3000（具体看 package.json 里 scripts 段的配置）。控制台出现 App running at 就说明前端服务启动成功。

前端启动后还需要确认一个关键配置——前端请求后端接口的代理地址。在 Vue 项目的 .env.development 或 vue.config.js 里，一般会配置开发环境的基础 API 地址，比如：

code复制VUE_APP_BASE_API = '/api'

同时 devServer 的 proxy 把 /api 转发到 http://localhost:8080。我在配置代理时踩过坑：改完配置文件后必须 重启 npm run dev，因为配置文件在运行期间不会被热更新重新加载，改完没反应的时候第一反应应该是重启开发服务器，而不是反复检查代码。

5.4 完整流程验证清单

当后端、前端、数据库三个服务都启动成功后，不要急着点菜单，按下面的清单走一遍完整业务验证流程：

1. 用管理员账号登录后台，检查首页看板上的收入统计、订单量、会员增长等数据是否正常。
2. 进入会员管理，新建一个测试会员，设置初始余额。
3. 进入订单管理，模拟“到店收衣”流程：选择会员、添加多件衣物（干洗/水洗）、选择优惠券、确认订单，此时应收金额会自动计算。
4. 模拟支付，检查会员余额是否正确扣减、储值流水是否存在。
5. 进入洗涤管理，将订单状态从“待取件”更新为“洗涤中”，再到“待取衣”。
6. 模拟取衣流程，确认取衣码和衣物件数，将订单置为“已完成”。
7. 最后去数据管理查看订单明细和营收汇总是否与手动计算结果一致。

完成这么多步骤，整条链路没有报错，基本上这套系统就真正跑起来了。这才是源码学习的正确打开方式——复制流程、核对数据、验证状态之间的流转，而不只是在登录页溜达一圈。

6. 项目部署上线：从开发机到服务器

6.1 前后端打包的关键细节

开发环境跑通之后，如果这套系统要真正部署在企业服务器上，打包是个绕不开的环节。这里确实藏着不少坑，值得单独说。

后端打包用 Maven 命令：

bash复制mvn clean package -Dmaven.test.skip=true

跳过测试能大幅缩短打包时间。打包成功后在 target 目录下会生成一个 xxx.jar 文件。

前端打包前有一个地方必须检查：把开发环境的 API 地址改成生产环境的域名或 IP。很多人在本地开发时通过代理转发搞定跨域，但打包后的静态页面没有代理能力，必须在 vue.config.js 或环境变量中把请求地址指向真实后端地址。曾经有个项目部署上线后全部接口报 404，原因就是忘记修改这个公共请求地址，这可是一个经典的生产事故。

改完地址后执行：

bash复制npm run build

构建成功后生成 dist 目录，里面是纯静态文件（html、js、css），这就是要发布到 Nginx 的产物。

6.2 Nginx 部署与反向代理

后端 Jar 包可以用 java -jar 命令直接启动，但生产环境更好的做法是配合 systemd 写一个 Service 文件，让它能开机自启、崩溃自动拉起。前端的 dist 目录放在 Nginx 的 web 目录下。

Nginx 配置里比较关键的是前端静态资源服务和后端接口反向代理，一个简化版配置如下：

nginx复制server {
    listen 80;
    server_name your-domain.com;

    # 前端静态文件
    root /opt/laundry/dist;
    index index.html;

    # 解决前端 history 路由刷新 404 问题
    location / {
        try_files $uri $uri/ /index.html;
    }

    # 接口反向代理
    location /api/ {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

两个配置要点要解释清楚：

location / 里的 try_files 是配合 Vue Router 的 history 模式（即去除地址栏 '#' 号）。如果没有这行配置，刷新一个二级页面时 Nginx 会去找对应的静态文件，找不到就返回 404，但实际这个路径应由前端路由接管，返回 index.html 让它自己解析。

location /api/ 里的 proxy_pass http://127.0.0.1:8080/; 注意结尾的反斜杠——它有把 /api 前缀“吃掉”的效果。如果写成 http://127.0.0.1:8080（不带斜杠），后端接收到的 URL 仍会带 /api，容易导致后端找不到接口，这两者的差别非常隐蔽。

6.3 MySQL 生产环境的几点建议

如果你不只是练手，而是真的给门店做部署，MySQL 的生产环境配置有几件事建议提前做：

• 开启 binlog（二进制日志），为后续的数据恢复和主从同步留后路
• 设置慢查询日志，把执行时间超过 1 秒的 SQL 记录下来，上线后定期分析优化
• 定时全量备份，建议每天凌晨备份一次，可以用系统计划任务配合 mysqldump 自动执行
• 不要把数据库端口暴露到公网，只允许后端服务内网访问

这几点在系统上线初期看着像是多余的，我当年也是这么觉得的——直到有次凌晨误操作更新了整张订单表数据，没有备份的时候真的欲哭无泪。从那以后，“没有备份不上生产”成了我运维的一条铁律。

7. 常见启动报错排查与避坑指南

7.1 SpringBoot 启动失败类问题

拿到源码后第一次启动，大概率会碰到报错。技术社区里搜索频率最高的相关问题也集中在 SpringBoot 配和环境问题上。这里整理几个高发问题。

端口被占用。报错信息是 Port 8080 was already in use.，说明本机 8080 端口已被其他进程占用。先查谁占用了端口，换一个新端口后记得前端代理配置也要同步修改。

数据库连不上。报错关键词是 Cannot create PoolableConnectionFactory 或因连接超时导致的中文提示，基本就是三种原因：MySQL 服务没启动、IP/端口写错、账号密码错误。按照从前往后逐项排查可以快速定位。

驱动类找不到。如果 MySQL 是 8.x，驱动类名要写 com.mysql.cj.jdbc.Driver，而不是老的 com.mysql.jdbc.Driver。同时 pom.xml 里 mysql-connector-java 的版本不要过低，8.x 的 MySQL 建议对应 8.0.x 的驱动。

Redis 连接拒绝。如果系统用 Redis 存 Token，启动时 spring.data.redis.host 指向的地址连不上，SpringBoot 的启动流程不会挂，但登录接口会报错。本地调试如果没有 Redis，最简单的办法是用 Docker 快速起一个实例，或者用 Windows 版本的 Redis 服务。

7.2 Vue 前端问题汇总

Vue 项目开发中碰到的问题集中在 node-sass 和路由这两块，也是我在执行时最常被问到的内容。

node-sass 安装失败。报错信息很多，要么是 gyp verb check python checking for Python executable，要么是直接 Failed at the node-sass@x.x.x postinstall script。node-sass 需要从 GitHub Releases 下载二进制文件，网络不好就容易失败。解决方法很简单：用 sass 替代 node-sass（把 package.json 里的依赖名替换掉），或者直接用 nvm 切到 node-sass 官方支持良好的 Node 版本，比如 Node 14 配 node-sass 4.14。

前端启动正常但接口 404。页面能出来，说明前端服务没问题。点菜单时接口返回 404，优先检查代理配置是否生效，以及后端接口地址是否正确。在浏览器开发者工具的 Network 面板里看请求 URL，如果路径和 Swagger 上的接口文档不一致，多半是代理路径拼接错了。

刷新页面 404。这个问题在本地开发模式下较少遇到，主要是 Nginx 部署阶段会碰上，对应上一节提到的 try_files 配置。

7.3 业务数据异常与排查思路

还有一种“启动没问题但数据不对”的情况，这通常更让人头疼。我梳理几个典型场景：

订单金额算错。排查顺序是：先看前端传参是否完整——有没有把衣物明细完整传到后端；再查后端金额计算日志——原价多少、折扣率多少、优惠券优惠多少；最后看数据库订单表的数据——确认写入的结果和日志一致。因为金额计算步骤多，建议把每个中间值打印出来，用一份“预期结果 + 实际结果”的对照表来排查，比肉眼盲查代码高效得多。

会员余额扣了但订单没创建成功。这个大概率是事务没生效，重点检查 Service 方法是否是 public、是否通过 Spring 容器注入调用、同类内部是否发生了自调用，对照 4.4 节的内容逐一排查。

页面能进但按钮无权限。比如收银员账号登录后看不到“系统管理”菜单或点了没反应。先在前端代码里找到菜单权限控制逻辑，确认菜单是否通过接口动态返回、是按角色过滤还是按权限标识过滤。再看该账号的角色是否分配了对应菜单，SQL 联查一下用户的权限列表，确认是数据配置问题，还是前端过滤逻辑的 bug。

7.4 问题排查工具箱

最后分享点个人的排查思路。遇到问题时不要只盯着一处看，按照“前端请求 → 后端接口 → Service 业务 → SQL 执行 → 数据库状态”这条链路走一遍，每一步都验证一下，问题往往在链路中间就能定位，这也是多年踩坑换来的方法论沉淀。

排查问题的工具有值得配置的一套：MySQL 的慢查询日志要开，MyBatis 的 SQL 日志要打印出来。在 SpringBoot 配置文件里加一段：

yaml复制logging:
  level:
    com.laundry.mapper: debug

这样 MyBatis 执行每条 SQL 时都会在控制台打印完整语句和参数，排查“SQL 和预想的不一样”这类问题时非常有价值。我以前在 IDEA 里还会用 MyBatis Log 插件把预编译 SQL 还原成可执行的完整语句，直接复制到数据库客户端里执行一遍，能快速确认 SQL 本身是否正确。

8. 二开扩展思路与个人建议

源码跑通只是第一步，真正要把它变成自己简历上的亮点，强烈建议动手做二次开发。我根据实际门店反馈的需求，提供几个扩展方向供选择。

第一个方向是增加短信或微信模板消息通知功能。洗衣周期一般要两三天，顾客经常忘记取衣，门店要人工打电话催取，效率很低下。接入一个短信服务商或者微信服务号模板消息，在订单状态变为“待取衣”时自动给会员发送通知，这个功能落地的业务价值立竿见影。

第二个方向是增加多门店支持。单门店系统改成多门店时，要在订单表和员工表上都加 store_id（门店标识），所有查询和统计都按门店维度过滤，同时增加门店调拨功能——比如 A 店收的衣物送到 B 店洗护，中间的物流和交接状态也需要一套独立流程。

第三个方向是增加数据看板，用图表展示每日营收趋势、服务类型占比、会员复购率、促销活动效果对比。这里会用到 ECharts 这类可视化库，前端从后端接口拉取统计后的数据做渲染。建议后端直接用 SQL 做聚合统计（比如按天分组求 SUM），而不是把明细数据全量拉到内存里再用 Java 算——后者在后端数据量增长后会消耗大量内存和带宽。

从学习角度来看，不建议一开始就为这套系统引入 Redis 缓存、MQ 消息队列、分库分表这类中间件。先把单体架构下的业务逻辑吃透，把事务、索引、SQL 优化这些基本功打牢，等你真正遇到并发瓶颈时，再针对性地引入中间件，理解才会更深刻，对职业成长的帮助也更大。框架永远只是工具，核心还是对业务的理解，以及对数据一致性和系统性能的把控能力。这套洗衣店订单管理系统麻雀虽小、五脏俱全，如果你能把它彻底吃透，并亲手扩展一两个模块，在面试中去讲这个项目时，会比你简历上写的那一长串技术名词更有说服力。