最近帮某高校一位计算机专业的学生顺了一遍毕业设计，他拿来的题目就是“2026毕设SSM+Vue连锁干洗店后台管理系统”。我第一反应是这类管理系统题实在是老面孔，但细聊完发现，恰恰是这种“看着常见”的题，最容易被答辩老师问住——业务表面简单，真正把连锁、会员、订单流转串起来做，里面的门道一点不少。如果你也正在选毕设题目，或者已经选了SSM+Vue这套组合来开发管理系统，这篇文章可以帮你少走很多弯路。
说句实在话，管理系统类毕设每年都在大量重复，图书管理、仓库管理、学生选课、班级事务管理……这些题不是不能做，而是很难做出区分度。干洗店这个选题好在哪？好在它的业务流程长：收衣、洗涤、熨烫、质检、上架、取衣，每个环节都有状态变化；同时又叠加了连锁店的层级结构，有总店、有分店、有集中洗涤中心；再算上会员充值、余额消费、折扣规则这些财务相关操作。业务一长，数据表就多，接口就多，功能模块自然也就立体起来了。这篇文章就围绕这个题，把从业务拆解、技术分工、数据库设计到编码落地、论文写作的完整思路讲清楚。
1. 选题背后：为什么连锁干洗店比“某某管理系统”更适合做毕设
1.1 连锁场景制造了三层业务复杂度
单店干洗店的系统说白了就是“收衣、洗、取衣”三个动作，做出来就是一个简单的增删改查，连数据库都未必需要第三张业务表。但加上“连锁”两个字，系统的复杂度立刻就不一样了。
第一层是组织层级。总店管理员、门店店长、门店员工，这三类角色对数据的要求完全不同。总店要看见所有门店的经营数据，店长只能看自己门店，员工只能处理自己名下的收衣和结算。这个需求直接决定了你需要做“数据权限隔离”，而不是单纯做一个登录页区分用户身份。
第二层是业务流程的跨店处理。连锁干洗店常见的模式是前店后厂：分店负责收衣，衣物统一送到洗涤中心处理，洗完再送回分店等待顾客取衣。这就意味着订单不是在一个门店内闭环的，收衣门店、处理中心、取衣门店可能是三个不同实体。你的订单表设计、状态机流转都必须考虑到这个过程。
第三层是会员体系的连锁通用性。顾客在A店办了会员卡，去B店也能用，余额和积分是跨店的。这就不是简单的“会员表加个余额字段”能搞定的，你需要设计会员账户体系，并且对每一笔余额变动做流水记录。
这三层复杂度叠加下来，系统自然而然地就需要至少十几张表、几十个接口，论文里可画的图也多了：组织架构图、业务流程图、状态图、用例图、E-R图、模块结构图。对毕设来说，工作量非常容易展示。
1.2 评审老师最容易从哪些角度提问
我见过不少答辩现场，老师问得最多的不是“你这个代码怎么写”，而是“你这个业务场景下为什么这么设计”。干洗店这个题的业务足够直观，老师能快速理解，也就能快速提问。
常见的问题集中在几个点：会员充值后余额变更是直接改字段还是记流水？订单状态在不同门店流转时，谁有权限修改？如果顾客取衣时余额不足，订单如何处理？总店查看分店数据时，分页查询怎么做？这些问题下面几章都会讲到。提前把这些问题想明白，比堆砌一百个页面都管用。
2. SSM+Vue架构拆解：哪部分该用后端做，哪部分该交给前端
2.1 SSM三个组件各管哪一层
SSM是老牌组合，Spring负责管理对象和事务，SpringMVC负责接收HTTP请求并分发到具体的处理逻辑，MyBatis负责数据库访问。在干洗店系统里，我的建议是这样分工：
SpringMVC控制层主要做参数接收、调用Service、返回统一结果。Service层放业务逻辑，比如洗衣订单的状态校验、会员充值的流水写入、门店调拨的数据同步。MyBatis的Mapper层只做SQL操作，不要把业务逻辑写在SQL里，也不要把SQL写在Controller里。
事务控制一定要放在Service层。比如会员充值时，需要同时更新会员余额表和插入一条充值流水，两步操作必须在一个事务里。Spring声明式事务用起来很简单，加上@Transactional注解就行。如果写在Controller层，事务边界容易乱，而且Controller层代码会越来越胖，答辩时被问到代码结构会比较被动。
MyBatis这块，动态SQL是必须用起来的。订单列表查询需要支持按单号、按状态、按会员姓名、按门店多条件组合，不可能为每种组合写一个SQL。用<where>加<if>标签动态拼接条件，是这类系统最常规的做法，代码干净也容易维护。
2.2 Vue端如何组织页面和状态
Vue在这个系统里主要承担页面渲染和用户交互。对于管理系统，页面结构比较固定：左侧菜单、顶部栏、右侧内容区。
用Vue Router做路由管理时，建议把页面分成几组：登录页、总店端页面、门店端页面、公共页面。权限控制的思路是：前端根据用户角色动态生成路由表，而不是把所有路由都一股脑注册进去。比如员工登录后，系统里就不该出现总店经营报表的菜单入口。
组件复用方面，有三个地方特别值得做公共组件：会员选择器（填单时要选会员，很多页面都要用）、订单状态标签（不同状态显示不同颜色）、导出按钮（列表页普遍需要导出Excel）。把这些抽成组件，后面开发效率会明显提升，页面代码也会清爽很多。
如果项目规模不大，其实没必要引入Vuex或者Pinia，全局状态用一个简单的Store对象也能解决。但考虑到毕设要展示技能点，使用Pinia做登录用户信息和门店信息的全局存储，在论文里写“基于Pinia的全局状态管理”会更完整。
2.3 前后端接口约定：统一返回体和错误码
前后端分离后，最大的坑就是接口风格不统一。有的接口返回数组，有的返回对象，出错了又返回一堆堆栈信息，前端处理起来非常痛苦。我的建议是定义统一的返回结构：
public class Result<T> { private Integer code; private String message; private T data; // 其中 code = 200 表示成功，其他为业务错误码 }不管成功失败，后端都返回这个结构。前端在axios拦截器里统一判断code字段，如果等于200就返回data，否则弹提示信息。这样做的好处是，前端每个页面只需要处理data部分，不用关心错误分支，拦截器统一搞定。
接口命名也要规范。我的习惯是RESTful风格：POST /api/orders创建订单，PUT /api/orders/{id}/pickup取衣操作，GET /api/orders?status=WASHING查询订单列表。注意一点，状态变更尽量不要用POST /api/orders/updateStatus这种泛泛的写法，而是用语义化子资源表示动作，pickup、settle、cancel，这样接口文档一眼就能看懂业务动作。
3. 核心模块和数据库建模：订单流转、会员储值、门店数据隔离怎么落地
3.1 订单状态流转：整个系统的主动脉
干洗店打交道的核心对象就是订单。我把订单状态设计为六种：已收衣、洗涤中、待质检、已上架、已取衣、已取消。收衣员在门店收到衣服后创建订单，状态为“已收衣”；洗涤中心开始洗涤时改成“洗涤中”；洗完后质检合格变为“待质检”；质检通过、衣物挂回门店变为“已上架”；顾客来取衣，订单结算完成变为“已取衣”；顾客取消订单或超过保管期未取，则变为“已取消”。
每个状态变更都对应一个接口，并且后端要做状态合法性校验。比如“已取衣”的订单不允许再改成“洗涤中”，这个判断放在Service里。
为什么一定要做状态校验？因为前端界面可以控制按钮的显示和隐藏，但接口是裸奔的，懂点技术的人直接调接口就能跳过流程。毕设虽然不要求达到生产级安全，但答辩老师如果看到你做了这层校验，印象分会明显不同。
为了方便追溯，订单主表里加两个字段：current_status记录当前状态，status_history存状态变更记录。后者用JSON格式记录每次变更的操作人ID、原状态、新状态、操作时间。这样顾客来问“我的衣服现在到哪一步了”，查订单就能直接展示完整状态轨迹。
我觉得状态流转是这套系统最值得花心思的地方。从数据表到后端校验到前端展示，一整条链路都是连贯的业务逻辑，论文里可以画一张状态图，答辩时顺着图讲一遍，老师基本就不会质疑你的系统只考虑了增删改查了。
3.2 会员储值和钱包流水：金额别直接改余额
会员模块看着简单，最容易翻车的是余额处理。新手直接写UPDATE member SET balance = balance - 100 WHERE id = 1，这是大忌。原因很简单：第一，没有流水记录，对不上账；第二，并发情况下会出现超扣、余额为负的问题。
正确的做法是设计三张表：会员表（存当前余额）、储值规则表（充多少送多少）、钱包流水表（记录每一笔余额变动）。充值或消费时，在同一事务里写余额变更和插入流水记录。
比如会员储值这笔操作，Service层逻辑应该是查询会员信息、计算优惠金额（根据充值规则表）、用悲观锁或乐观锁更新余额、新增一条流水记录。流水表字段包括：会员ID、变动类型（充值/消费/退款/人工调整）、变动金额、变动前余额、变动后余额、关联订单号、操作人、备注。
为什么要把变动前余额和变动后余额都记录下来？因为这才是对账的依据。如果哪天发现某笔订单金额不对，可以顺着流水把余额变动串起来，直接定位到是哪一步出了错。毕设答辩时，老师大概率会问到“你怎么保证余额数据正确”，把流水表的设计思路讲出来，比背一嘴“用了事务”要强得多。
3.3 门店数据隔离与权限模型的落地
连锁系统的权限模型，我建议做成“用户—角色—门店”三层结构，不要简单给用户表加一个store_id字段。正确做法是：用户表只管登录账号和密码；角色表区分总店管理员、店长、员工；用户与门店的关联单独建一张员工门店关联表。
这样做的好处在于一个用户可以关联多个门店。比如一个区域经理可以同时查看辖区多家门店，或者某位收衣员今天在A店值班、明天调到B店。如果store_id直接写在用户表里，这种灵活的调整就很难实现。
数据查询层用MyBatis的拦截器或手动传门店参数来实现隔离。我的做法比较简单直接：员工登录后，后端把当前用户可访问的门店ID列表放入一个工具类中，查询关键业务数据时拼接store_id IN (...)条件。总店管理员则不加门店条件。这样写逻辑清晰，答辩时也容易解释。
这里有个很容易忽略的细节：订单查询、会员查询、统计报表，凡是涉及门店的都要做隔离，千万别只做了订单模块就完事。如果不一致，会出现“员工能看到其他门店会员信息”的尴尬情况，统一做一遍隔离处理，后续加新功能也会顺手很多。
3.4 核心表结构设计示例
我在这里给出订单表和流水表的简化建表SQL，可以当作起步参考。实际设计时可以根据自己业务再扩展字段：
CREATE TABLE `laundry_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `store_id` bigint NOT NULL COMMENT '收衣门店', `member_id` bigint DEFAULT NULL COMMENT '会员ID', `customer_name` varchar(32) 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 '优惠金额', `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额', `current_status` varchar(20) NOT NULL COMMENT '当前状态', `pickup_code` varchar(10) DEFAULT NULL COMMENT '取衣码', `created_by` bigint NOT NULL COMMENT '收衣员工ID', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;CREATE TABLE `wallet_transaction` ( `id` bigint NOT NULL AUTO_INCREMENT, `member_id` bigint NOT NULL COMMENT '会员ID', `change_type` varchar(20) NOT NULL COMMENT '充值/消费/退款/调整', `change_amount` decimal(10,2) NOT NULL COMMENT '变动金额', `before_balance` decimal(10,2) NOT NULL COMMENT '变动前余额', `after_balance` decimal(10,2) NOT NULL COMMENT '变动后余额', `ref_order_no` varchar(32) DEFAULT NULL COMMENT '关联订单号', `remark` varchar(255) DEFAULT NULL, `create_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;收衣时还需要订单明细表，记录每件衣服的品类、洗衣项目、单价。比如一件羽绒服、一件西装、两件衬衫，各对应不同的洗涤项目和费用。明细表的加入让订单表不用存冗长的冗余文本，统计各品类洗护量时也能轻松查询。
E-R图建议画清楚订单、会员、门店、员工、洗衣项目这几张核心表的关系，论文里这张图是需求设计部分的重头戏。
4. 关键功能的实现细节：接口设计、权限控制与前端交互的实战要点
4.1 登录鉴权和密码安全，别再用明文密码了
管理系统的基本入口是登录。很多毕设代码里密码直接用明文存数据库，这是答辩时比较严重的减分项。正确做法是使用BCrypt或MD5加盐做哈希存储。Spring Security可以引入，但配置偏重，毕设里我建议用一个简单的拦截器实现登录校验，密码用BCryptPasswordEncoder加密，这样既省事，又能体现你的安全意识。
登录成功后，后端生成一个简单的Token（可以使用JWT，也可以用一个UUID存在Redis里，设置2小时过期），前端存到localStorage，每次请求在axios拦截器里带在请求头中。后端写一个HandlerInterceptor，拦截除了登录接口以外的所有接口，校验Token是否存在、是否过期，并取出当前登录用户信息放入上下文。
这个设计的好处是，在任意Service层里都可以拿到当前操作人的ID，正好用在前面说的订单状态变更记录和流水表里。答辩时老师问“你这个操作日志是怎么记的”，你说是从登录拦截器里取的当前用户，整个链路是通的。
4.2 MyBatis动态SQL和分页查询
订单列表页是这个系统里查询条件最多的页面：订单号模糊查询、状态筛选、收衣门店筛选、收衣时间范围、会员手机号精确查询。这些条件组合起来，用MyBatis动态SQL最适合。
分页我建议用PageHelper插件。配置好之后，查询代码非常简洁：
PageHelper.startPage(pageNum, pageSize); List<OrderVO> list = orderMapper.selectOrderList(query); PageInfo<OrderVO> pageInfo = new PageInfo<>(list);注意一个问题：PageHelper的分页原理是在执行SQL前拦截并生成count语句和分页SQL，所以它必须紧跟在Mapper方法调用前面，中间不能穿插其他数据库操作，否则分页条件会串掉。这也是初学者最容易踩的坑。如果发现分页不生效或查出来的总条数不对，可以先检查一下是不是PageHelper.startPage和Mapper查询之间夹了别的代码。
VO层建议单独建类，不要直接把实体映射给前端。订单实体里有status字段，但前端展示需要“进行中”“已完成”等文字说明，还需要展示门店名称、会员姓名、收衣员工姓名。这些信息散落在多张表，连表查询后封装到OrderVO里返回给前端。这么做的好处是前端拿到的数据结构更友好，而且不会暴露你不希望返回的字段。
4.3 订单号、取衣码、金额计算的易错点
订单号我建议用“日期+门店编号+当日流水”的格式，比如20260612001，简单直观，而且同一个日期、同一个门店内编号不会重复。用数据库自增ID直接当订单号虽然省事，但在给顾客报单号时容易暴露店铺经营数据，而且多门店情况下自增ID有规律，安全性不好。
取衣码我用的是4位数字，随机生成并保证当日不重复。顾客来取衣时报取衣码，员工输入后系统自动定位订单，核对手机号后完成取衣操作。这个功能虽然小，但在论文里可以写成一个独立的“快速取衣”模块，功能界面截图也能多一张。
金额计算这块尤其要小心。程序中一律用BigDecimal计算金额，不要用double或float，否则会出现0.1+0.2不等于0.3的经典问题。前端JavaScript计算金额同样有精度问题，所以实付金额、找零金额都尽量让后端计算返回，前端只负责展示。收衣时录入多件衣物，总金额、折扣金额、实付金额一定要由后端统一计算，避免前端篡改金额提交。
4.4 前端axios封装与路由守卫
axios拦截器建议每个系统都封装一次，不要每次请求都写一遍完整地址和处理逻辑。封装思路是：统一加baseURL，请求拦截器里加Token，响应拦截器里统一处理code字段：
service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) service.interceptors.response.use(res => { const result = res.data if (result.code === 200) { return result.data } else if (result.code === 401) { router.push('/login') return Promise.reject(new Error('登录已过期')) } else { ElementPlus.Message.error(result.message) return Promise.reject(new Error(result.message)) } })这样每个页面里调接口只需要关注返回的业务数据，比如创建订单后拿到订单ID然后跳转，弹错误提示这些脏活累活都交给拦截器统一处理。
前端路由守卫用来控制未登录跳转。beforeEach里判断localStorage有没有Token，没有就跳登录页。这个逻辑虽然简单，但能避免一个很尴尬的场面：页面能打开，一调接口全部401。
在页面组件层面，我习惯把列表查询、弹窗表单、删除确认这些逻辑写成可复用的组合式函数。比如useOrderList负责加载订单列表、操作loading状态、分页参数、刷新列表；新建订单弹窗是一个独立的子组件，父组件监听它的submit-success事件然后刷新列表。这样职责清晰，代码也不容易越写越乱。
5. 论文写作与答辩准备：跑通程序只是第一步，讲清楚设计理由才是高分关键
5.1 论文结构蓝本：每一章该写什么
毕设论文是有基本套路的，但这里说的“套路”不是让你照抄模板，而是让你知道每一章应该放什么素材。拿干洗店系统来说，我建议这样安排：
摘要部分不要写大段背景，直接说清楚“本文设计并实现了一个基于SSM框架和Vue的连锁干洗店后台管理系统，实现了门店管理、会员管理、订单管理、洗衣流程追踪、经营统计等功能，重点解决了多门店订单流转和会员储值一致性两个问题”。摘要就是概括你的实际工作，关键词列四个：SSM框架、Vue.js、管理系统、订单状态流转。
第一章绪论写背景和研究意义，可以从连锁服务业数字化讲起，但两三段就够，不要洋洋洒洒几千字行业报告。国内外研究现状这块，不要吹这个系统多先进，教室和导师都清楚这是教学项目。
第二章需求分析是重点。要画用例图，按照角色分：总店管理员用例、店长用例、员工用例。把每个用例的动作描述清楚，比如“员工创建订单”这个用例，前置条件是员工已登录并选择所属门店，后置条件是订单状态为已收衣、库存明细生成、库存表扣减。需求分析写得不含糊，后面设计部分自然就顺。
第三章系统设计里必须有总体架构图、功能模块图、技术架构图、E-R图、核心业务流程图。架构图用Visio或ProcessOn画，别用截图替代。状态图是把6种订单流转状态之间的关系画清楚。时序图选一个核心场景画，比如“会员储值”的时序图，能体现你对系统运行过程的理解。
第四章系统实现不要贴大段代码。选关键功能贴核心代码片段，比如状态校验的Service方法、动态SQL查询、前端组件间通信的代码，每段代码配一段实现说明。界面放截图，每张截图说明实现了什么功能、操作流程是什么、有什么异常处理逻辑。
第五章测试要写清楚测试环境、测试数据、测试用例和测试结果。用表格列五到八个典型用例，比如“创建订单并生成取衣码”“会员充值后余额正确增加”“订单状态非法流转被拒绝”“非本店员工无法查询其他门店订单”。每个用例写预期结果和实际结果，最后加一句结论：测试全部通过，系统满足需求。
5.2 图和表的含金量：不画流程图，项目看起来就像没设计
因为可以很直接地说，论文里如果缺少高完成度的图和表，评审老师很可能默认你的系统是“代码凑的、论文临时写的”。图不是装饰，它是你把业务逻辑讲清楚的最有效工具。
订单状态图尤其重要。你不需要画得特别复杂，把六个状态画成圆圈，用带箭头的线标出状态切换动作，比如“收衣登记”触发“已收衣”到“洗涤中”，“质检通过”触发“待质检”到“已上架”。这张图画出来，你整个系统的核心逻辑就在纸面上了，答辩时指着图讲，比念代码生动得多。
数据库E-R图不要一股脑画全部表，核心的四五张表关系画清楚就行。表结构表格要列全字段、类型、注释，特别是订单明细、钱包流水这种核心表。测试用例表格用三线表，内容写得具体，不要写“点击按钮检查是否正常”这种没营养的描述，要写清楚输入数据和预期输出。
5.3 系统测试部分：如何写得不像凑字数
很多学生写测试章节就是列几个用例然后说通过，这样显得很敷衍。可以加两类内容让这部分更扎实：一类是异常场景测试，比如会员余额不足时取衣会怎样、订单状态从“已取衣”回退到“洗涤中”会不会被后端拒绝、重复点击提交按钮会不会生成两条订单。把这些边界场景的测试结果写进表格，能很明显体现你做过思考。
另一类是接口测试。用Postman或接口调试工具对核心接口做一轮测试，把结果截图放在论文里，并简单标注请求参数和响应结果。这比只做前端页面点一点更能体现后端工程能力。如果时间紧张，至少把登录、创建订单、会员充值和取衣这几个核心接口测试截图保留好。
5.4 答辩现场的高频问题清单
我总结了这类系统答辩时几乎必被追问的几个问题，可以提前准备好答案：
“为什么用SSM不用SpringBoot？”回答思路：一是课程体系里SSM是最经典的教学组合，二是SSM对Spring源码层面的理解更深；但同时要承认SpringBoot提高了开发效率，毕设选题阶段为了展示完整SSM整合能力所以选了SSM。不要贬低任何一方，态度要客观。
“你的订单状态是怎么保证不乱的？”回答思路：前端控制按钮显示只是一种辅助，核心在后端Service层每个状态变更方法里都有前置状态校验，并且状态变更记录在status_history字段中，可以追溯。
“会员并发充值怎么处理？”回答思路：事务加流水表，可选悲观锁或乐观锁。说明用SELECT ... FOR UPDATE加锁余额行，保证同一时刻只有一个线程在更新同一个会员余额，同时写入流水表，数据库层面的完整性由事务保证。
“如果系统上线，哪些地方需要改进？”可以从高可用部署、消息队列异步处理、Redis缓存热点数据、数据分库分表等角度回答，体现你在关注系统演进。答辩时不要让场面冷掉，这个问题是展示你思考深度的机会，而不是揭短的陷阱。
结尾
把这套系统从头到尾做完，我最大的体会是：毕设项目的重点从来不在于“用了多新的框架”，而在于你能不能把一个具体场景里的业务流程理解透，并用代码把它完整表达出来。连锁干洗店这个题目看起来不像人工智能那么热门，但它把订单状态机、会员钱包流水、多门店隔离这些真实业务里最常遇到的问题集中到了一起，完成它之后，你对SSM和Vue的理解会比看十遍教程都牢靠。
最后再分享一个我建议的节奏：先花两天把所有表结构设计好，再把订单从创建到取衣的主流程后端接口先跑通，然后再回头做门店管理、会员管理这些外围功能。主流程是骨架，外围功能是血肉，骨架立住了，后面填肉就不会乱。如果你正在为这些细节卡壳，不妨先从订单状态流转那张图入手，把它画明白，代码怎么写自然就有底了。
