Spring Boot+MyBatis打造洗衣店订单管理系统：从建模到部署全解析

1. 洗衣店订单管理的需求真相：为什么不能只是"记个账"

先讲个我自己的经历。有一次去小区楼下的洗衣店取羽绒服，老板翻了一分钟本子才找到我的单子，旁边还有三个顾客在排队等着查衣服洗到哪一步了。那一刻我就想，这家店每天的订单量少说几十单，每单又是少则一两件、多则七八件衣物，靠Excel表格甚至纸质本子管理，早晚要出乱子。后来帮朋友做毕设选题时，他提出想做一个"基于spring boot的洗衣店订单管理系统"，我一听就觉得这个选题特别实在——需求清晰、业务闭环完整、技术栈又主流，做出来之后是真的能拿去给洗衣店用的系统，而不是那种写完就躺代码仓库里的作业。

这类系统的核心价值，不是"把纸质记录电子化"这么简单。洗衣店的日常运营有五个老大难问题：

一是订单碎片化。顾客不是一次只洗一件，而是把一周攒的外套、衬衫、窗帘一起送来，每件衣物的洗涤方式和价格还都不一样。如果用"一单一价"的模型，账根本算不清。

二是状态追踪靠吼。衣服进入洗涤流程后，顾客最常问的一句就是"我的衣服好了没"。没有系统的话，店员只能靠记忆和翻本子，高峰期一问三不知，体验很差。

三是取衣环节容易扯皮。取衣服时要核对件数、核对洗涤方式有没有做错、核实价格有没有多算。纸质单丢了、字迹看不清、价格记错了，都是纠纷来源。

四是营收统计滞后。老板想看看这个月干洗赚了多少、水洗赚了多少、哪个品类最赚钱，翻本子翻到半夜也算不出来。

五是会员管理靠感觉。谁充值了多少钱、余额还剩多少、是不是老客户，全在老板脑子里，换个人就看不懂了。

所以从需求层面说，"基于spring boot的洗衣店订单管理系统"实质上是围绕订单生命周期构建的一套小型业务中台，覆盖开单、明细管理、状态流转、结算取衣、会员储值和经营统计。技术难度不高，但对业务建模能力、数据表设计和接口设计的要求一点不低。

本文适合正在做类似Java Web课程设计或毕业设计的同学，也适合想给小型商户做信息化项目但又不想一上来就上微服务那套重武器的开发者。我会按"需求分析→技术选型→表结构设计→核心接口实现→典型踩坑→部署实践"这条线展开，全程用我实际开发过程中采用的方案和踩过的坑说话。

2. 技术选型复盘：Spring Boot + MyBatis这套组合好在哪

2.1 为什么是Spring Boot而不是传统SSH或纯Servlet

很多人做管理系统时有个误区：觉得Spring Boot就是"Spring MVC换了个壳"。实际差别非常大。Spring Boot最核心的价值是自动配置和约定优于配置。洗衣店订单管理系统这种业务系统，80%的代码都是CRUD + 业务状态判断，如果把这些时间浪费在配置XML、配数据源、配事务管理器上，那项目的核心业务反而没精力打磨了。

Spring Boot帮我们省掉的工作量，具体到这个小项目上感受特别明显：

• 内嵌Tomcat，一个java -jar命令就能起服务，不需要在本地装Tomcat再手动部署war包。
• spring-boot-starter-web、spring-boot-starter-jdbc、spring-boot-starter-validation这些起步依赖，引入一条依赖就等于配好了一整套和Spring MVC、JDBC、参数校验相关的默认环境。
• 自动配置的数据源和MyBatis集成，只需要在application.yml里写数据库连接信息，其余交给框架处理。

我用的是Spring Boot 2.7.x版本，配合JDK 8。为什么不用最新的Spring Boot 3.x？这里有一个很现实的考虑：3.x基于JDK 17，如果你电脑上装的是JDK 8，那连编译都过不了；而且部分第三方MyBatis增强插件对3.x的适配还不太成熟。课程设计和中小型项目，稳定压倒一切，2.7.x是经历过大量生产验证的版本。

2.2 MyBatis和JPA之争：我为什么选MyBatis

选持久层框架时，很多人会在Spring Data JPA和MyBatis之间纠结。我做这个项目选MyBatis，理由非常直接：洗衣店订单管理系统的查询场景，有大量多表关联和统计类SQL，MyBatis手写SQL的场景掌控力更强。

举个例子，前端要展示"取衣页面"时，需要一次性查出来：订单主信息、该订单下所有衣物明细、每件衣物的洗涤方式名称和价格、顾客姓名和会员余额。这个查询如果设计成一张大宽表，用JPA的实体关系映射会很别扭；用MyBatis写一个多表LEFT JOIN的查询，把结果映射到自定义DTO，思路清晰、SQL性能也肉眼可见地可控。

再看经营统计这个功能，要按日、按洗涤类型、按会员/散客分组聚合营业额，这种动态SQL的拼装场景，MyBatis的<if>标签和<where>标签简直就是为它而生的。用JPA去做这种动态条件查询，要么退回去写Specification，要么直接上原生SQL——绕了一圈还是回到SQL本身。

另外一个很实际的原因是，MyBatis的排查成本低。SQL写得再复杂，报错了你直接拿日志里的SQL语句丢到Navicat里执行，问题出在哪一眼就能看到。JPA生成的SQL一旦和你预期不一致，定位问题反而多一道干扰。

2.3 前端和后端的协作方式

这个小项目我没上前后端分离，用的是Thymeleaf模板引擎 + Bootstrap。原因不复杂：洗衣店订单管理系统的使用者是店员和老板，并发量极小，交互复杂度也就是表单提交、列表刷新、状态按钮切换。用Thymeleaf直接在服务端渲染页面，一个Spring Boot + MyBatis + Thymeleaf + MySQL的单体应用就全覆盖了，学习的知识密度更高，维护也更省事。

如果你是冲着技术简历去的，也可以在这个项目基础上把前端拆成Vue，后端提供纯JSON接口。我的建议是先把这个单体版本跑通，再考虑拆，一上来就前后端分离，事务控制、页面跳转、状态管理这些概念混在一起，反而容易学成一锅粥。

下表是我最终选型的结果，后续所有实现都围绕这个组合展开。

3. 核心模型设计：订单表、状态机与洗衣单价的联动逻辑

3.1 一单多衣：订单主表和明细表为什么要拆开

这是整个系统最关键的建模决策。洗衣店的业务形态很明确：一个顾客送一次衣服，产生一张订单；一张订单里可能有外套、衬衫、裤子、被套等多件衣物，每件衣物的洗涤方式不同，价格也不同。

如果把所有信息塞在一张表里，会出现什么后果？要么一行数据只能代表一件衣物，导致一个订单在表里占多行，没法精确表达"这张单总价多少、谁取的、是否取走"这种状态；要么用冗余列存多件衣物，字段数量不可控，查询和统计都会变成灾难。

所以必须拆成订单主表（orders）和订单明细表（order_items）。主表只管"这一单是谁的、什么状态、应收多少钱、实收多少钱、取没取走"；明细表只管"这一单里有哪几件衣物、分别是什么洗涤方式、单件多少钱、有无瑕疵备注"。

这里有一个业务关怀点必须体现在表结构里：明细表中要有一个字段叫衣物现状备注。洗衣店收衣服时，店员需要对衣物进行预检，比如口袋有没有东西、衣服有没有破损、会不会掉色，这些信息必须落到明细表的备注字段里。否则顾客取衣时发现"我衣服上的纽扣之前就是松的"，双方说不清楚，这就是纠纷隐患。

我设计的订单主表核心字段如下：

• id：主键，自增
• order_no：订单编号，格式如XD20250601001，方便人工核对和口播
• customer_id：关联会员表；如果顾客不是会员，则允许为空
• customer_name：冗余存顾客姓名
• customer_phone：冗余存手机号，取衣时核对身份用
• total_quantity：总件数，由明细表聚合而来
• total_amount：应收总金额
• status：订单状态，用TINYINT表示状态机编码
• remark：订单整体备注
• create_time、update_time：创建和更新时间

注意customer_name和customer_phone是冗余字段。为什么不直接join会员表？因为洗衣店会出现"非会员顾客"的订单，这种情况下没有customer_id，但姓名和电话必须留底，否则没法取衣。

3.2 订单状态机：不要用字符串描述状态

订单状态管理是这类系统最容易做烂的地方。有人图省事，直接在status字段里存"待洗""洗好""已取"这种中文描述字符串，后果就是：前端显示依赖后端写死，统计时中文值不可控，一个"已取走"能写出一万种变体。

正确做法是用整数编码 + 枚举类定义常量，再在展示层做映射。我为订单设计了这样一个状态流：

• 0：已下单（待确认）
• 1：清洗中
• 2：已晾干/已完工待取
• 3：已取衣
• 4：已取消

这几个状态之间的流转路径不是任意的。0可以走到1或4；1只能走到2；2只能走到3；4是终止态。在Service层写状态变更逻辑时，必须做状态合法性的校验，不能出现"已取衣又变成清洗中"这种荒谬流转。

这里要和洗衣店的实际流程对齐一点：不要设计"待支付"和"已支付"两个状态。洗衣行业是先服务后付费，顾客取衣时结算。如果洗完衣服顾客一直不来取，订单就压在"待取"状态，这是正常的业务滞留，不代表异常。支付信息和订单状态分离，支付字段单独用pay_status管理。

3.3 洗衣价格表：价格计算要留变数

每种洗涤方式（水洗、干洗、熨烫、精洗）和衣物类型（上衣、裤子、外套、窗帘、玩偶）的组合价格，都是需要维护的基础数据。我单独建了一张wash_price表，字段是cloth_type（衣物类型）、wash_type（洗涤方式）、price（价格）。页面录入明细时，选择衣物类型和洗涤方式，价格自动带回，允许店员根据实际污渍程度手动微调。

这样设计的好处是，老板调整价格时只要改数据库里的记录就行，不用改代码。我还预留了一个discount_amount字段，用于会员折扣、节庆优惠这种整单优惠场景。计算订单总价时，逻辑是把所有明细单价累加，减去discount_amount，得到total_amount。应收金额在开单时就要算出来并沉淀到主表，不能等取衣时再临场按明细重算，否则一旦中间有人改了明细但忘了改主表，金额就对不上了。

4. 关键功能落地：开单、状态流转、取衣结算的接口设计思路

4.1 开单接口：事务边界要划清楚

开单是整个系统最高频的操作，它做的事其实不少：校验会员是否存在、生成订单编号、写入订单主表、逐件写入明细表、累计总件数和总金额、扣减会员余额（如果是储值支付）。这一串操作必须包在同一个事务里，任何一个环节失败，整单回滚。我用@Transactional标注Service层方法，默认的RuntimeException回滚策略就够了。

开单的Controller接口我设计成接收一个DTO，而不是直接把前端表格数据裸传给Service。DTO里包含两部分：主单信息和明细列表。前端页面里，店员先填写顾客信息，然后动态添加一个明细表格行，一行就是一件衣物，选衣物类型、洗涤方式，填备注，表格下方自动汇总件数和总金额，确认后提交。

给Service层写核心代码时，我用了简单的分层：

@Override @Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 生成订单编号，格式 XD + yyyyMMdd + 当日序号 String orderNo = orderNoGenerator.generate(); // 2. 组装订单主表实体，status 初始为 0（已下单） Order order = new Order(); order.setOrderNo(orderNo); order.setCustomerId(dto.getCustomerId()); order.setCustomerName(dto.getCustomerName()); order.setCustomerPhone(dto.getCustomerPhone()); order.setStatus(OrderStatus.CREATED.getCode()); order.setRemark(dto.getRemark()); order.setCreateTime(LocalDateTime.now()); // 3. 计算总金额和总件数，同时校验每件衣物价格合法 List<OrderItem> items = dto.getItems().stream().map(itemDTO -> toItem(itemDTO)).collect(toList()); BigDecimal totalAmount = items.stream() .map(OrderItem::getPrice) .reduce(BigDecimal.ZERO, BigDecimal::add); // 减去整单优惠 totalAmount = totalAmount.subtract(dto.getDiscountAmount()); order.setTotalQuantity(items.size()); order.setTotalAmount(totalAmount); // 4. 先插入主表，得到自增id，再插入明细表 orderMapper.insert(order); for (OrderItem item : items) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } return order.getId(); }

这里有个细节很容易被忽略：明细表的插入必须先拿到主表的自增ID。MyBatis的useGeneratedKeys="true" keyProperty="id"必须配好，不然order.getId()返回的是null，明细表外键就废了。

4.2 状态流转接口：一个方法搞定合法跳转

状态流转接口在设计时，我一开始写了好几个方法，什么startWash()、finishWash()、pickUp()，后来发现这纯粹给自己找事。状态流转本质上就是对status字段的受控更新，用一个通用的方法，内部做合法性校验，反而更简洁。

@Override @Transactional(rollbackFor = Exception.class) public void changeOrderStatus(Long orderId, Integer targetStatus) { Order order = orderMapper.selectById(orderId); if (order == null) { throw new BusinessException("订单不存在"); } // 状态机合法性校验 if (!OrderStatus.canTransfer(order.getStatus(), targetStatus)) { throw new BusinessException( String.format("订单状态无法从 %s 流转到 %s", OrderStatus.of(order.getStatus()).getDesc(), OrderStatus.of(targetStatus).getDesc())); } order.setStatus(targetStatus); order.setUpdateTime(LocalDateTime.now()); orderMapper.updateStatusById(order); }

关键判断都收敛在OrderStatus枚举里，枚举里用Map配置好合法的流转路径。以后想加状态、改流转规则，只动这一个类，不会影响其他代码。

4.3 取衣结算：并发场景下的金额校验

取衣是最容易出事故的环节。后台页面打开一个订单时，显示应收金额和会员余额。店员点击"确认取衣"，后端要做这几步：

1. 检查订单状态必须是"已完工待取"。
2. 重新核对明细表中的数量和金额，防止有人中途改过。
3. 如果使用会员余额支付，检查余额是否充足，若充足则扣减余额并记录一条储值消费流水。
4. 更新订单状态为"已取衣"，记录取衣时间。
5. 扣库存（如果你做了库存管理的话；简单场景下可以不考虑）。

第四步和第三步必须在一个事务里，否则就会出现"钱扣了但订单状态没更新"的中间态。这种问题在测试阶段不容易暴露，上量之后必现，所以事务边界一定是接口设计时就要想清楚的。

顺带提一个细节：取衣时需要核验身份，所以订单列表页要支持按手机号查询。我专门写了getOrderByPhoneAndStatus这样的查询方法，店员输入手机尾号就能把待取订单筛出来，效率远高于翻本子。

5. 开发中绕不开的坑：端口占用、MyBatis映射与事务静默失效

5.1 端口号被占用：Spring Boot项目启动失败的"第一杀手"

很多人第一次启动Spring Boot项目就报Port 8080 was already in use，包括我自己也遇到过。这个报错的原因很简单：本机上已经有另一个进程占用了8080端口，Spring Boot默认端口就是8080，谁抢到算谁的。

排查路径可以这样走：打开命令行，输入netstat -ano | findstr 8080，找到占用8080端口的进程PID，再打开任务管理器找到对应进程，确认是无用进程就结束掉。

另一个更省事的做法是修改Spring Boot的demo端口号，在application.yml里加上一行：

server: port: 8085

为什么要换成8085而不是8081、8082？没有硬性规定，关键是避开本机进程的常用端口范围。我实际用下来，8085、9090这类端口被占用的概率远低于8080。如果你用VSCode开发Spring Boot项目，可以在.vscode/launch.json里配置环境变量覆盖端口，这样即使多个项目同时在跑也不会冲突：

{ "type": "java", "name": "Launch WashSystem", "request": "launch", "mainClass": "com.example.wash.WashApplication", "env": { "SERVER_PORT": "8085" } }

这里有个经验：端口配置不到万不得已，不要硬编码在JAVA代码里。使用server.port配置项，部署时可以通过启动参数--server.port=8090覆盖，这才是生产环境的玩法。

5.2 MyBatis映射的经典陷阱：下划线字段映射不上

Spring Boot整合MyBatis时，最经典的坑就是数据库字段是create_time，Java实体属性是createTime，查询结果里createTime永远是null。原因在于MyBatis默认不做驼峰和下划线的自动映射。

解决方案是在application.yml里开启驼峰映射：

mybatis: configuration: map-underscore-to-camel-case: true

这一行加上，create_time才能正确映射到createTime。

但只开这个还不够。如果你写了复杂的多表JOIN查询，返回结果是自定义DTO，比如OrderDetailVO，里面有个字段叫itemCount，而SQL里给的是COUNT(*)。这个字段没有加别名，MyBatis会把它映射成COUNT(*)对应的列名，属性匹配肯定失败。标准做法是加别名：

SELECT o.id, o.order_no, COUNT(i.id) AS item_count FROM orders o LEFT JOIN order_items i ON o.id = i.order_id GROUP BY o.id, o.order_no

我踩过一次很深的坑是：一个统计查询在Navicat里跑得好好的，到代码里返回的itemCount全是null。排查了一晚上，最后发现是忘了加AS item_count。这个教训很值钱：别相信MyBatis自动映射，别名一定要写规范。

对于多对一或一对多的嵌套查询，能不用association/collection就不要用。我之前试图用collection把一个订单下的明细列表一次性嵌套查出来，结果触发了N+1查询问题——先查主表，再逐条查明细，数据量一大页面就卡。后来改成先查主表，再按order_id IN (...)批量查明细，在Service层把数据组装成VO，性能立刻上来了。

5.3 事务静默失效：同一个类里方法调用让@Transactional形同虚设

这个坑非常隐蔽。我写了一个OrderServiceImpl，里面有方法createOrder，它内部调用了同一个类里的deductBalance方法，后者加了@Transactional。测试时发现余额扣减和订单创建不在一个事务里，其中一步失败，另一步竟然提交成功了。

原因在于Spring的@Transactional是基于动态代理实现的。外部调用Service时，代理对象拦截调用，开启事务；但如果是一个类里的方法调用另一个方法，调用走的是this引用，绕过了代理，事务注解就被静默忽略。

解决办法有三个，按优先顺序排：

1. 把需要事务保证的操作提到同一个方法里，一个公开方法对应一个完整事务。
2. 把被调用的方法移到另一个Service类里，通过注入的方式调用，让代理接管。
3. 在同一个类里通过注入自身的代理对象来调用。

我推荐第一种，因为createOrder这个场景本身就是"开单加扣款"一个完整业务流程，没必要拆成两个方法再组合。事务的粒度应该跟着业务边界走，而不是跟着代码方法走。

5.4 MySQL连接参数：时区和SSL警告不能忽视

Spring Boot连接MySQL时，如果application.yml里连接串写法不完整，控制台会刷出一条警告：WARN: Establishing SSL connection without server's identity verification is not recommended，同时报时区错误。

这不是致命错误，但不处理的话，时间字段读写会差8个小时。正确的连接串写法：

spring: datasource: url: jdbc:mysql://localhost:3306/wash_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver

serverTimezone=Asia/Shanghai保证数据库连接会话时区正确；useSSL=false关闭SSL警告；allowPublicKeyRetrieval=true解决MySQL 8.0在非SSL连接时可能出现的公钥检索报错。这三个参数属于"不加也能跑、加了才稳定"的典型组合。

6. 从Demo到可上线：打包部署与日常维护心得

6.1 打包配置：跳过测试和资源过滤

开发调试时用mvn spring-boot:run就够了，交付给别人演示时要打成可执行JAR。在项目根目录执行：

mvn clean package -DskipTests

打包完成后，在target目录下会生成一个wash-system-0.0.1.jar。注意Spring Boot的Maven插件必须配了spring-boot-maven-plugin，否则打出来的JAR不是可执行的。我在pom.xml里还加了finalName配置，让生成的包名固定为wash-system.jar，部署脚本就不用改来改去了。

给洗衣店老板部署时，我不推荐装MySQL再单独搞一个Tomcat。直接用java -jar wash-system.jar --spring.profiles.active=prod启动，配合application-prod.yml里配置生产数据库连接，一台普通Windows电脑或者云服务器就能跑起来。JAR包自带内嵌Tomcat，省掉传统应用服务器配置的繁琐环节。

6.2 日志是排查线上问题的唯一线索

系统上线后，最怕的是"线上环境复现不了开发环境的问题"。我第一次部署到服务器时，订单列表页偶发报错，本地怎么测都好，后来查了服务器上的日志文件才发现，是服务器MySQL的sql_mode里开了ONLY_FULL_GROUP_BY，导致一个统计SQL报错。本地数据库没开这个模式，所以一直没暴露。

所以日志配置一定要从开发期就做好。我在application.yml里配了滚动日志，按天滚动、保留30天：

logging: file: name: logs/wash-system.log level: com.example.wash: info

排查问题时，先用grep关键字找到异常堆栈，再顺着时间线往前追关联日志。没有日志，线上问题就只能靠猜，猜的效率极低。

6.3 给店员和老板用的系统，交互设计要反着来

最后说一个很多开发者不重视的点。洗衣店订单管理系统是给店员用的，不是给程序员用的，所以交互设计逻辑和普通后台管理系统是反的。程序员喜欢"表单越简洁越好，查数据自己去数据库看"，店员需要的却是"一个页面能完成所有操作，不要让我记订单编号"。

我后来微调了几个交互细节，效果立竿见影：

• 首页默认展示"待取衣物"列表，按时间倒序，而不是一个空空的统计仪表盘。
• 手机号和订单号都支持模糊查询，店员只需要记住顾客的姓氏加尾号就能找到单子。
• 取衣按钮、状态切换按钮都放在列表行内，减少页面跳转次数。
• 结账时金额用大号字体显示，店员和顾客都能一眼看到，避免口头报数产生争议。

这些改动没有增加一行复杂技术，但对实际使用的口语化需求响应得很准。老板真正感动的功能也不是什么高深的统计报表，而是"顾客打电话问衣服好了没，我在系统里一秒钟就能告诉他"这个最简单的查询。

根据我个人实操体会，这种单体Spring Boot项目最难的地方从来不是技术选型，而是能不能把业务状态流梳理清楚、把数据边界划清楚。只要订单主表、明细表、状态机这三根柱子立住了，后续加会员、加报表、加打印小票都是顺水推舟的事。希望这篇记录能帮你少走几步弯路，尤其是状态流转合法性校验和事务边界那两块，值得多花点时间把它想透。