前几天我一个朋友接手了一家连锁洗衣店的分店跟我吐槽说每天最头疼的不是洗衣服而是那本越写越乱的开单簿。顾客送衣服来手写一张三联单一联给顾客、一联夹在衣物袋上、一联留底到了取衣的时候翻单子翻到眼瞎月底跟总店对账更是全靠Excel和计算器硬扛。他问我有没有现成的管理系统我说这类小业务系统其实完全可以自己动手做一套而且不太复杂。今天就把我最近整理的一套洗衣店订单管理系统源码拿出来聊一聊技术栈是Java SpringBoot Vue3 MyBatis数据库用的MySQL前后端完全分离页面和接口都已经跑通直接下源码改改配置就能用。这篇文章不会只给你看目录结构我会把业务拆解、数据库设计、后端接口实现、前端页面逻辑以及跑项目时常见的坑全部写出来适合正在学Java全栈、或者想找一个完整项目练手的开发者参考。1. 为什么洗衣店需要一个订单管理系统业务痛点与功能拆解洗衣店这个业态看着小实际运营起来细节非常多。散客和会员混在一起衣物从进店到出店要经过接收、洗涤、质检、取衣好几个环节每一环都可能出问题。大多数人第一次接触这类系统时会觉得不就是增删改查吗但真正动手做之后你会发现订单状态流转、会员余额操作、对账单据统计每一块都需要先想清楚业务规则再写代码。1.1 门店日常运营的三个核心痛点第一个痛点是开单效率。手工开单要写顾客姓名、电话、衣物名称、件数、约定取衣时间碰到高峰期门口排着队手写速度根本跟不上还容易出现字迹潦草导致取衣时认错单子的情况。第二个痛点是衣物状态不透明。顾客打电话来问我那件羽绒服洗好了没店员只能去翻纸质单看有没有完成标记如果流程没跟上根本答不上来体验非常差。第三个痛点是会员账目混乱。很多洗衣店都有储值卡和次卡储值卡扣费、次卡划次数如果靠手工记账月底总有一堆对不平的账。这三个痛点指向同一个解决方案把订单数字化。顾客进门后收银员在系统里创建订单输入手机号能自动带出会员信息订单关联的衣物明细逐条录入从接收开始每一步都更新状态取衣时系统自动计算金额、扣款、留痕。管理者想看今天做了多少单、营业额多少、哪些项目最受欢迎打开统计页一目了然。1.2 系统功能模块拆解我整理这套源码时把功能划分成六个模块没有刻意堆功能每个模块都对应门店实际用得上的场景模块核心功能解决什么问题登录与权限管理员/收银员/洗衣工三种角色不同岗位干不同事系统层面做隔离会员管理开卡、充值、余额变动流水储值卡账目清晰顾客余额随时可查洗衣项目管理维护水洗、干洗、熨烫等项目和单价开单时直接选择不用每次手输价格订单管理创建订单、订单明细、全流程状态流转从接单到取衣全程可追踪取衣结算按单结算、优惠计算、打印小票取衣环节收银准确高效统计看板今日单量、营业额、订单状态分布经营者随时掌握门店运转情况这个功能范围对单体门店或者小型连锁分店来说完全够用。如果你想扩展比如加一个短信通知顾客取衣、加一个衣物拍照存档、或者接一个微信公众号推送这套系统的表结构和前后端分层都能直接支撑不需要推倒重来。1.3 这套系统真正解决了什么有人会觉得市面上有那么多商业收银系统为什么还要自己开发一套如果你只是开一家店直接买商业软件确实更省事。但如果你是做毕业设计、做项目练习或者你是连锁品牌的IT人员需要给门店做一套可定制的内部系统那这套源码的价值就很明显了。它不绑定任何第三方商业平台代码完全可控加字段、改流程、接接口都不受限制。更重要的是这个项目完整覆盖了一个业务系统从后端数据库设计到前端交互展示的全过程。SpringBoot负责提供接口Vue3负责渲染页面MyBatis负责数据库访问MySQL负责数据存储。你把它跑通一遍相当于把Java全栈开发的主要环节都过了一遍后面换任何业务场景套路都是通的。2. 技术选型SpringBoot Vue3 MyBatis 这套组合的取舍逻辑技术选型这件事很多人会直接抄热门组合但未必清楚每一个组件在这个项目中承担什么职责、为什么非它不可。我来说说这套组合的理由方便你看完知道自己手里拿的是什么。2.1 后端SpringBoot为什么是首选Java后端开发现阶段的主流方案基本就是SpringBoot没有太大争议。它把Spring繁琐的XML配置大幅简化内嵌Tomcat打一个jar包就能直接运行。对于洗衣店订单系统这种体量的业务SpringBoot提供的Web模块、事务管理、参数校验、拦截器等功能已经绰绰有余不需要引入额外框架去增加学习成本和维护成本。我选用SpringBoot还有一层考虑这个项目面向的阅读者是Java开发者群体。市面上Java岗位的面试和项目经验里SpringBoot几乎是必写项。一个能独立讲清楚接口实现、事务控制、权限拦截的SpringBoot项目比花里胡哨的微服务项目更容易让新人真正吃透。所以在源码里我有意做了几个典型场景的完整实现比如拦截器做JWT Token校验、声明式事务控制订单创建。2.2 持久层MyBatis的灵活性在于SQL可控关于数据访问层选MyBatis而不是Spring Data JPA核心原因是对SQL的掌控力。洗衣店订单系统的查询场景非常多按手机号查会员、按时间范围查订单、按状态查列表、多条件组合筛选。MyBatis允许你把这些查询写成XML里的动态SQL条件拼装完全在你的控制之下查询性能可以通过SQL本身去优化。相比之下JPA的自动SQL生成在处理简单CRUD时确实省事但一旦遇到复杂的统计查询或者多表关联查询要么写JPQL要么用原生SQL绕一圈之后还是要回到SQL本身。MyBatis的另一个优势是结果映射灵活从数据库的下划线命名映射到Java对象的驼峰属性一行配置搞定。整套源码看下来你会发现绝大部分查询都能在XML里直观地看到SQL语句这对学习和排查问题都特别友好。2.3 前端Vue3 Composition API更适合后台管理Vue3出来之后我用它重构过好几个管理后台项目感受非常明显。Composition API可以把同一个业务逻辑的变量和方法聚在一起代码组织性比 Vue2 的 Options API 好很多。拿订单列表页来说查询表单的参数、表格数据加载方法、状态枚举的映射、分页参数这些逻辑在setup函数里集中书写比把它散在data、methods、computed里更容易维护。配合Element Plus这套UI组件库表格、表单、弹窗、标签页这些后台管理常用组件都是现成的两天时间就能把基础页面框架搭出来。另外Vite作为构建工具开发环境启动速度比Webpack快一大截改代码热更新时间基本在几百毫秒以内日常开发体验非常舒服。2.4 前后端分离与MySQL的现实考量前后端分离现在已经是非常成熟的做法。前端一套代码可以同时适配PC浏览器和移动端浏览器后端接口理论上也能被多个客户端复用。洗衣店管理端不需要像C/S架构那样在每台电脑上安装客户端浏览器打开网址就能用部署成本低很多。前端开发完用Vite打包成静态文件可以丢到Nginx下也可以直接放进SpringBoot的静态资源目录灵活度很高。数据库选MySQL没什么好多说的稳定、免费、资料多。小型门店一天几百单MySQL的支撑能力绰绰有余。唯一需要注意的细节是建表时字符集统一用utf8mb4因为订单备注、顾客姓名里如果将来要存emoji表情utf8mb4之外的字符集容易报错。我在源码的初始化SQL里已经全部设置好你导入的时候留个心就好。3. 数据库设计订单主表、明细表与状态机字段的细节这套系统的数据库一共六张核心表用户表、会员表、洗衣项目表、订单主表、订单明细表、余额变动流水表。把订单拆成主表和明细表是因为一个订单可以包含多件衣物、多个服务项目主表存顾客信息和总额明细表存每件衣物的具体服务项目和金额这种一对多的设计是订单类系统的标准做法。3.1 核心建表语句订单主表的设计是整张表里最关键的部分字段含义非常清晰CREATE TABLE la_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, member_id bigint DEFAULT NULL COMMENT 会员ID散客为NULL, customer_name varchar(50) NOT NULL COMMENT 顾客姓名, customer_phone varchar(20) NOT NULL COMMENT 联系电话, total_amount decimal(10,2) NOT NULL COMMENT 订单原总金额, discount_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, actual_amount decimal(10,2) NOT NULL COMMENT 实付金额, order_status tinyint NOT NULL DEFAULT 0 COMMENT 状态0待接收 1洗涤中 2待取衣 3已完成 4已取消, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL COMMENT 创建时间, update_time datetime NOT NULL COMMENT 更新时间, deleted tinyint NOT NULL DEFAULT 0 COMMENT 逻辑删除 0未删除 1已删除, PRIMARY KEY (id), KEY idx_member_id (member_id), KEY idx_customer_phone (customer_phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT洗衣订单主表;订单明细表的重点在于每一条明细都对应一件衣物的具体服务项目包含衣物名称、服务项目ID、数量、单价和小计金额。这样创建订单时前端传一组明细过来后端循环入库即可统计干洗业务一个月有多少营收这类问题直接对明细表按项目ID分组聚合就能得到结果。3.2 order_status 状态机设计要点订单状态我用了tinyint整数类型0到4分别代表待接收、洗涤中、待取衣、已完成、已取消。用整数而不是直接用字符串好处有三个存储占用小、查询效率高、代码里做枚举映射清晰。每次订单状态变更时前端调用对应的接口后端校验当前状态是否允许变更到目标状态这样能避免已取消的订单又被改成已完成这种业务错误。一个容易忽略的细节是订单做逻辑删除而不是物理删除。洗衣店的订单数据是经营凭证月底要对账、要追溯物理删除了数据就没了。我在所有业务核心表上都加了deleted字段查询时统一拼接deleted 0条件既保证了数据可恢复也不影响日常查询效率。3.3 金额精度、时间字段与索引规划金额字段必须用decimal这是经验教训不是选择题。如果用double或者float存金额看起来能计算但涉及到余额扣减、优惠折扣这些操作时浮点误差会在多次运算后被放大。decimal(10,2)可以精确到分洗衣店单笔金额一般不会超过十万这个精度范围足够了。后端Java对应类型也要用BigDecimal不要用double接收前端传过来的金额。时间字段统一datetime类型Java里用LocalDateTime对应前后端交互时格式化成yyyy-MM-dd HH:mm:ss我在JSON序列化配置里已经处理好。索引规划上订单表对member_id和customer_phone各建了一个普通索引因为日常查询主要就是按会员查历史订单、按手机号查订单这两个场景。4. 后端实现从统一返回类到订单状态流转的完整链路后端代码结构是标准的四层架构Controller接收请求并做参数校验Service处理业务逻辑Mapper定义数据库访问接口XML文件存放SQL语句。这套结构清晰稳定不会因为业务增长而变得不可维护。4.1 统一响应体与全局异常处理接口返回格式如果不统一前端每次拿数据都要做不同的判断非常痛苦。我在源码里写了一个Result类所有接口的返回值都包裹成固定的结构{ code: 200, message: 操作成功, data: {} }前端的Axios拦截器会对code进行统一判断200直接返回data401跳转登录页其他错误码弹出消息提示。后端同时配合一个全局异常处理器业务上抛出的自定义异常会被统一捕获转成约定格式返回给前端。这样写的好处是Controller里的代码非常干净只管业务不管异常格式。4.2 登录鉴权JWT Token 拦截器方案登录模块我用的是JWT搭配SpringBoot拦截器实现。用户登录成功后后端根据用户ID和角色生成一个Token返回给前端前端把它存进localStorage之后每次请求都会在请求头带上Authorization: Bearer token。后端拦截器拦截除登录接口之外的请求校验Token的合法性和有效期校验通过就从Token里解析出用户信息放进请求上下文。这个方案比传统的Session机制更适合前后端分离因为后端的接口是无状态的谁拿Token谁就能访问不需要在服务器内存里维护Session状态。集群部署的时候也不用考虑Session共享的问题。当然它也有局限比如Token注销麻烦但那是后面要讲的安全进阶话题作为项目初期方案完全够用。4.3 MyBatis动态SQL订单多条件查询的一次成型订单列表页的查询条件有手机号、订单状态、下单日期范围、订单编号如果这四个条件都为空就返回全部订单。这种场景用MyBatis的动态SQL写起来非常顺手看一段XML里的查询片段select idlistOrders resultTypecom.example.entity.Order select * from la_order where if testorderNo ! null and orderNo ! and order_no like concat(%, #{orderNo}, %) /if if testcustomerPhone ! null and customerPhone ! and customer_phone #{customerPhone} /if if testorderStatus ! null and order_status #{orderStatus} /if if teststartTime ! null and create_time #{startTime} /if if testendTime ! null and create_time lt; #{endTime} /if and deleted 0 /where order by create_time desc /select这个查询解决了两个常见问题。第一如果不用动态SQL你得在Java代码里手写一堆if判断来拼接SQL字符串拼接容易出错还难维护第二MyBatis的where标签会自动去掉第一个条件前面的and避免SQL语法错误。页面上的筛选条件多少变了只要改这个XML就行不用动Java代码。4.4 创建订单的事务边界控制创建订单这个操作在业务上会同时影响多张表写入订单主表、写入订单明细表、如果顾客是会员还要扣会员余额、记录余额变动流水。这四个操作如果中间任何一个失败前面写入的数据就必须全部回滚否则会出现订单建了但金额没扣的严重对账问题。这里用Spring的Transactional注解放在创建订单的Service方法上方法内任何一个异常都会触发事务回滚。我把事务边界控制放在Service层而不是Controller层是因为Controller层只负责接收参数和返回结果业务操作的原子性必须在Service方法级别保证这也是面试里经常会被问到的点。5. 前端Vue3实现路由守卫、Axios封装与订单看板前端项目基于Vite创建目录结构非常清晰views存放页面组件api存放接口调用方法router存放路由配置store用Pinia管理全局状态utils存放Axios实例等工具函数。这种结构是后台管理系统的通用范式你拿去做别的新项目直接换页面文件就行。5.1 登录与权限控制的处理方式在前端实现权限控制第一个核心是路由守卫。我在router的beforeEach钩子里判断当前访问的页面是否需要登录如果需要登录但没有Token就强制跳转到登录页。同时根据Token里解析出的角色字段判断是否有访问权限比如洗衣工角色看不到统计看板。这种前端控制是主要防线后端接口仍然会做二次校验防止有人绕过前端直接调接口。登录表单的校验我用Element Plus的Form组件自带规则手机号必须符合11位手机号格式、密码不能为空。登录成功后从后端返回去用户信息放进Pinia的store里整个应用都可以通过store读取当前登录人信息比如在页面右上角显示欢迎你收银员小李。5.2 Axios拦截器与Token刷新请求层我用Axios实例统一配置了baseURL和超时时间。请求拦截器负责从localStorage取出Token添加到请求头响应拦截器负责统一处理错误如果后端返回code为401清除本地登录信息并跳转到登录页。这种做法把是否登录的判断收敛在一个文件里不需要每个页面单独处理。开发环境还有一个关键配置就是Vite的proxy代理。前端开发服务器跑在localhost:5173后端接口跑在localhost:8080如果前端直接请求后端接口必然触发跨域问题。我在vite.config.js里配置了一个代理把所有/api开头的请求转发到http://localhost:8080同时后端也加了CORS配置兜底双保险应对联调环境的各种情况。5.3 订单列表页的实现细节订单列表页是这个系统最核心的页面。顶部是筛选条件栏包括手机号输入框、状态下拉框、日期范围选择器、查询和重置按钮。中间主体是一张表格展示订单编号、顾客信息、金额字段、当前状态和操作按钮。底部分页器控制每一页显示10条或者20条数据。状态列我用Element Plus的el-tag标签加上颜色区分待接收是灰色、洗涤中是蓝色、待取衣是橙色、已完成是绿色、已取消是红色。这种可视化的状态呈现店员扫一眼就知道哪些订单还压在哪个环节。表格里操作按钮取衣结算只有在订单状态为待取衣时才显示状态为已完成时显示查看详情这样前端侧也做了状态流转的控制配合后端校验保证业务逻辑不会走错。订单列表的数据加载逻辑放在setup函数里完成页面加载时调用查询接口拉取第一页数据并填充表格和分页器点击查询按钮时重置页码为1并按条件重新加载点击分页器页码时按当前筛选条件加载对应页。后面的统计看板页复用同一个查询接口按订单状态分组聚合展示为卡片数据视觉上直接展示今天接了多少单、待取衣多少件、已完成多少件、总营收多少钱店长每天早上打开电脑一眼就能掌握门店情况。5.4 创建订单与取衣结算的交互设计创建订单页面拆成两个区域左侧是会员信息与顾客信息表单输入手机号后自动查询是否为会员是会员就带出余额和等级散客则直接填写姓名电话右侧是衣物明细列表一行一行动态添加衣物名称、服务项目、数量、单价金额组件联动计算出该项小计。所有明细行汇总后显示在底部提交时前端把整个订单对象和明细数组一起传给后端接口。取衣结算的交互稍微复杂一点涉及结算金额、实际收款、优惠金额三个值的联动。结算页打开时展示待取衣订单的应收总额收银员可以输入优惠金额前端实时计算应收金额确认收款后调结算接口后端记录实际收款金额、更新订单状态为已完成、扣减会员余额并写入流水。这套交互里没有用复杂的组件就是el-form、el-table、el-dialog这些常用组件组合核心在于字段之间的数据联动要写清楚。6. 实际跑项目时最容易踩的坑跨域、时间格式、金额精度与MyBatis映射我把这套源码跑通并且做二次开发的过程中踩过不少坑。这几个是最典型、也是新手几乎必遇的我把完整的排查思路写出来你遇到类似问题时可以直接对照。6.1 前端跨域问题的完整排查链路场景是前端npm run dev起在5173端口后端跑在8080端口页面发请求直接报错。控制台显示CORS错误请求根本没到后端。不少同学第一个动作就是去后端加一个CrossOrigin注解结果发现有时候管用有时候不管用。我这里给一个更稳妥的链路排查方法先确认前端开发服务器的代理配置是否生效vite.config.js里改完配置要重启dev serverhot reload不会自动应用代理变更。确认前端请求路径走的是相对路径/api/...而不是写死http://localhost:8080/api/...。写死的情况下代理不会命中请求直接发给后端跨域问题就会转移给后端CORS处理。后端CORS配置我用的是实现WebMvcConfigurer接口的类比分散的CrossOrigin注解更统一因为一个项目里接口多每个都加注解容易漏。如果后端接口在网关或者Nginx后面还要检查代理层有没有把跨域响应头透传。前端最终上线时页面和接口通常部署在同一个域名下跨域问题就会自然消失。但开发阶段必须把这个链路处理好不然联调效率极其低下。6.2 LocalDateTime序列化导致的接口返回异常放了LocalDateTime字段后接口返回的JSON时间字段如果你不处理会出现输出格式带T的一长串类似2025-01-15T10:20:30前端显示出来非常难看而且前端解析这个格式在一些老版本浏览器上会直接报错。排查时第一反应是加JsonFormat注解最直接但每个字段都要加很繁琐。更完整的做法是在SpringBoot的配置文件中全局指定格式加上Jackson的jsr310模块依赖spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样所有接口的LocalDateTime字段都会自动格式化成我们想要的样子前端拿到的都是2025-01-15 10:20:30这种可读格式。注意time-zone一定要设置成GMT8否则你会发现时间比实际早了8个小时这种时间偏移的bug最隐蔽看到数据对不上时第一反应往往是测试出错而不是时区问题。6.3 金额精度BigDecimal是唯一选择前端输入金额时用的是number类型到了后端如果直接用double接多次计算的精度就存在风险。举个例子0.1加0.2用double计算结果是0.30000000000000004做金额计算显然不能接受。我在后端所有涉及金额的实体类字段都声明为BigDecimal接收前端参数时也用BigDecimal接收。前端展示时金额都做保留两位小数处理。另外建议你在数据库里也对金额字段使用decimal(10,2)不要用double或float从源头保证数据准确。对于优惠计算这类逻辑我在Service层里写了一个金额计算工具方法统一处理原价、优惠、实付的换算避免每个接口各写一套导致逻辑不一致。6.4 MyBatis驼峰映射与XML路径配置MyBatis查询结果映射到Java对象时默认不开启驼峰映射。数据库字段是customer_phoneJava属性是customerPhone如果没开启映射查询结果会是null非常容易踩中。在application.yml里加上这一行配置mybatis: configuration: map-underscore-to-camel-case: true这个问题排查看上去很怪数据库有数据、SQL在客户端执行正常结果Java对象里全是空值。排查的时候可以先打印查询结果如果是null就看字段名。另外一个高频坑是XML文件路径配置错误。我在源码里把Mapper接口和XML文件放在同一个包路径下并且在application.yml里设置了mapper-locations: classpath*:mapper/*.xml确保SpringBoot能扫描到XML文件。如果XML放错目录启动时不报错运行查询时才报Invalid bound statement这个错对于第一次接触MyBatis的人来说相当劝退。7. 本地部署运行指南从源码克隆到前后端启动的完整步骤关于部署这块我直接给出在你自己电脑上把项目跑起来的步骤里面包含所有初始化文件和个人经验总结的操作顺序。7.1 初始化数据库与默认数据先确保本地装好了MySQL 8.0然后创建一个数据库名字建议直接叫laundry_db。源码里的sql目录下有两个文件schema.sql是建表语句data.sql是初始化数据。在命令行里依次执行mysql -uroot -p -e CREATE DATABASE laundry_db DEFAULT CHARACTER SET utf8mb4 mysql -uroot -p laundry_db schema.sql mysql -uroot -p laundry_db data.sql初始化数据里内置了一个管理员账号admin、密码admin123还有几个测试用的洗衣项目。你自己开发测试时直接用这个账号登录就行不用再自己去造数据。注意data.sql里用了INSERT语句如果你之前跑过一遍再重复导入可能会报主键冲突所以建议只在第一次导入时执行或者导入前把数据表清空。7.2 后端配置与启动后端工程是标准的Maven项目先把依赖拉下来。打开application.yml默认配置里数据库密码是root如果你本地MySQL密码不一样改一下就能跑。启动方式有两种用IDE直接运行启动类或者命令行执行mvn spring-boot:run启动日志里看到Tomcat started on port 8080就说明后端已经就绪。建议启动后先测试一下登录接口用Postman或者直接在浏览器里请求http://localhost:8080/api/login如果能拿到返回的Token就说明数据库连接和登录逻辑都正常后端这一步就算跑通了。7.3 前端启动与联调前端工程在vue3目录下先安装依赖npm install npm run dev看到Local: http://localhost:5173 说明启动成功浏览器打开这个地址会跳到登录页。使用管理员账号登录后首页就是统计看板。如果页面能正常加载订单数据和统计数字前后端联调就完成了。注意前端接口请求路径是通过Vite代理转发到后端的不需要手动改任何接口地址。7.4 最后再说几个真实操作中的注意事项开发调试阶段建议后端接口的打印日志打开在application.yml里把Mapper层的日志级别设置成debug这样能在控制台看到每一条执行的SQL语句排查数据问题效率会高很多。还有一点是我个人习惯在改数据库表结构时不要只改实体类而不改XML里的resultMap这会导致字段对不上SQL能执行但取值全是null。这套洗衣店管理系统源码最大的价值不在于你直接拿来就能用而在于它把一套完整业务系统的每一个环节都串起来了。如果你正在学SpringBoot看完后端的Controller、Service、Mapper分层逻辑会特别清晰如果你正在学Vue3看完页面组件和状态管理也能理解一个后台管理系统的前端是怎么组织的。下一步如果你有时间可以试着给它加一个取衣提醒短信通知的功能找短信平台接一个接口前端在做取衣操作时调用一下整套系统就更有真实商用价值了。
