做连锁洗衣店的业务管理系统是不是听起来很简单不就是把送来的衣服登记一下、洗完了再登记一下取走吗真要把这个项目从零写出来你会发现里面藏着一整套业务逻辑会员储值、订单流转、衣物状态跟踪、门店对账、员工权限每一个环节都在考验你对Java Web开发的理解。这个项目用的是Java SSM框架也就是Spring、Spring MVC、MyBatis这套经典组合。我身边很多人在做课程设计或者准备实习项目时都会选类似题目因为它不像电商、秒杀那样被写烂了但又足够覆盖企业级应用的核心知识点。这篇就当一次完整的项目复盘从需求拆解到环境搭建、从核心代码到常见坑点我把能讲的细节都摊开来说希望对正在写Java课程设计、或者想补一个靠谱项目经验的你能有实际帮助。1. 项目定位与功能拆解——连锁洗衣店到底需要管什么洗衣店单店模式很简单但一旦挂上“连锁”两个字系统复杂度的提升是跨维度的。老板不会只关心今天洗了几件衣服他要看的是所有门店的营收汇总、每个门店的订单趋势、会员储值带来的现金流、甚至某个洗护品类在哪个区域更受欢迎。这些需求落到系统头上就得靠功能模块一层层支撑起来。1.1 从行业痛点倒推系统需求我做这个项目前先去旁听了一个开干洗店的朋友讲他的日常运营发现真正管理一家洗衣店远没有想象中省心。衣物混淆是最大的风险顾客送来羽绒服、西装、毛衣形态相似如果没有编号和标签系统洗错、弄丢就是赔偿纠纷。会员管理也麻烦储值卡、次卡、折扣卡规则各不相同纯手工记账根本对不上。这些痛点倒推出来的需求其实非常清晰多门店数据集中管理总店能看到所有分店的实时营业情况分店只能看到自己的数据。衣物唯一标识与状态追踪每件衣物入库生成唯一编号状态从“待洗涤”到“洗涤中”到“待取件”全程可查。会员储值与计次消费支持预充值余额、积分累计、等级折扣结账时自动计算。灵活计价规则按件计费、按重量计费、不同面料不同价格还要支持加急费、上门取送费。门店营收统计与对账按日、按月汇总订单金额、实收金额、优惠金额、储值消耗。员工角色与权限隔离收银员只能操作前台业务店长能看到门店报表管理员才能维护基础数据。把这六条想清楚再去看系统需要哪些表、哪些接口心里就有底了。很多同学写项目一上来就建表结果做到一半发现业务逻辑接不上本质上是需求没有拆解到位。先花时间把痛点列出来再倒推功能这个顺序不能反。1.2 角色设计与核心业务流程系统里的角色我建议这样划分系统管理员、店长、收银员前台、洗涤员工、会员客户。没必要再拆得更细再多就过度设计了。每个角色对应一套功能权限集合比如收银员能操作收衣、取衣、会员开卡但看不到门店营收统计店长在收银员基础上多了报表查看和员工管理管理员则掌握系统参数、店舖信息、洗衣项目的增删改。核心业务流程上一单完整的生意大概是这样的顾客到店或者通过电话预约→前台按会员手机号查档有卡就开单没卡就先办卡→录入衣物信息并选择洗护项目→系统自动计算金额支持储值余额抵扣→打印收衣小票衣物生成唯一编号进入洗涤队列→洗涤员工按编号完成各道工序并更新状态→状态变为待取件后通知顾客→顾客到店前台验证身份完成取件结算。这套流程串起来之后系统的核心表结构基本就明朗了会员表、订单主表、订单明细表、洗衣项目表、门店表、员工表、充值记录表。主表和明细表的设计在我的项目里是分开的订单主表只存订单号、门店ID、会员ID、金额汇总、状态明细表一行一件衣物记录每件衣服的具体款式、洗护方式、价格。这样设计的好处是以后想扩展“退洗一件”“加洗一件”的操作时只需要操作明细表不需要动主表的整体结构。1.3 为什么选SSM而不是Spring Boot这是每个做这个项目的人都会纠结的问题。我的观点是如果目标是学东西、走一遍Java企业级开发的完整链路SSM反而是比Spring Boot更好的选择。Spring Boot把Tomcat内嵌、自动配置、依赖管理全部藏起来了你写一个Controller就能跑确实爽但“为什么能跑”这个环节是缺失的。SSM要求你手动去整合三套框架Spring管理对象和事务、Spring MVC负责请求分发、MyBatis处理SQL映射。你在配置里写的每一行比如SqlSessionFactoryBean的创建、MapperScannerConfigurer的扫描路径、视图解析器的前后缀都会让你对框架之间的边界有真实的体感。这些体感在面试时极其重要因为面试官一旦问到“Spring Boot自动配置的原理”你没组装过SSM就没法真正理解那些约定大于配置的东西。另外很多企业里的老项目、外包项目中SSM存量非常大你进公司维护的不一定都是全新Spring Boot项目。会SSM切换到Spring Boot只需要一两周手感的适应但只会Spring Boot碰到老项目真的会两眼一抹黑。2. 核心技术选型解析——SSM框架在项目里的实际分工SSM三个框架在项目里的角色用一句话概括就是Spring管对象、Spring MVC管请求、MyBatis管数据库。这三件事在代码层面是层层嵌套的理解了它们各自的边界项目再乱也不会乱到哪里去。2.1 Spring对象管理与事务的“大管家”洗衣店项目里对象太多Controller、Service、Mapper、DataSource、事务管理器如果全部手动new光是管理依赖关系就能把人绕晕。Spring的IoC容器把这些Bean全部收编要什么就注入什么。它的另一个大杀器是声明式事务这是这个项目里最不能缺的能力。洗衣店一次下单操作涉及的操作起码有三步向订单主表插入一条记录、向订单明细表插入多条衣物记录、更新会员的储值余额。如果第二步失败了第一步和第三步不会跟着回滚那数据库里就会出现一头是订单、一头钱没扣的脏数据。要解决这个问题不加思考的“手动commit/rollback”极其冗余。而Spring里只需要在Service方法上标注Transactional它就通过AOP机制在方法执行前后帮你把事务边界画好方法跑完才提交过程中抛了RuntimeException就整体回滚。这也正好解释了面试高频题“Java怎么保证数据一致性”在企业项目里的一种落地答案——靠数据库事务靠框架层的声明式事务管理再配合后面的行锁机制保证并发扣款不出错。2.2 Spring MVC请求分发与参数绑定Spring MVC的核心是DispatcherServlet。浏览器发来的每一个请求比如“POST /order/create”带着一堆表单参数先落到DispatcherServlet再由它拿着HandlerMapping找到对应的Controller方法。具体到项目里Controller方法做的事情很少接收前端参数、把参数组装成DTO或实体、调用Service、拿到返回结果后指定视图。这里有一个非常实用的设计习惯Controller里的代码要“瘦”只做路由和参数绑定不要掺业务逻辑。判断一个方法的业务逻辑该放哪有个简单的标准——如果同一个操作既可能在Controller触发也可能在定时任务或另一个Service里触发那就必须下沉到Service层。洗衣店项目的“订单创建”就是典型的业务逻辑下沉案例我后面写代码时会演示。2.3 MyBatisSQL与对象的映射MyBatis在这个项目里承担的是数据访问层。很多人纠结为什么不直接用JPA而选MyBatis我的理由非常朴素洗衣店项目的查询条件太多了。订单列表可能要按门店查、按会员查、按状态查、按时间范围查这种动态拼接SQL的场景MyBatis的if标签用起来得心应手。而且MyBatis的SQL是自己写的可控性强。比如下面这段根据条件动态查询订单的SQLselect idpageQuery resultTypecom.laundry.entity.Order select * from orders where if teststoreId ! null and store_id #{storeId} /if if testmemberId ! null and member_id #{memberId} /if if teststatus ! null and status ! and status #{status} /if if teststartTime ! null and create_time gt; #{startTime} /if /where order by create_time desc /select这个SQL的where部分是动态生成的有查询条件才拼进去没有就不拼。换成纯JDBC去写的话你就得在Java代码里反复拼接字符串还要小心空格和and的位置维护体验差很多。2.4 数据库设计几张核心表如何定数据库设计是这个项目的地基我建议核心表控制在7张左右不要多、不要少。除了前面提到的orders主表和order_item明细表重点说说会员相关的设计。会员表的设计里要注意几个关键字段balance表示储值余额类型用DECIMAL(10,2)而不是FLOAT因为金额计算最忌讳浮点误差points表示积分默认0level用TINYINT表示会员等级1普通会员、2银卡、3金卡等级高低可以直接影响折扣时计算的方式。手机号字段建议加唯一索引因为顾客到店第一件事就是报手机号查档。充值记录表的字段大致是id、member_id、充值金额、赠送金额、操作员工ID、充值时点。这张表非常重要因为一旦发生储值纠纷后台人员要能查到每一笔充值流水这也是财务对账的基础。还有一张容易被忽略的表是操作日志表。连锁门店里员工操作需要追溯到人谁在什么时间给哪个会员充了值、谁修改了订单金额这些审计信息都可以记录在日志表里。虽然会增加代码量但对一个要展示企业级开发规范的项目来说这个表的存在感极强。3. 核心模块实现与实操要点模块划分直接决定了代码好不好写、后期好不好扩展。我按业务域把代码分成了会员模块、订单模块、衣物跟踪模块、门店员工模块、统计报表模块。下面挑几个容易写歪、写错的地方细致展开。3.1 会员开卡与充值逻辑并发扣款的正确姿势会员充值和消费扣款是这个项目里最容易出脏数据的地方也是最值得拿出来讲的亮点。很多人第一次写扣款语句是这样Member m memberMapper.selectById(id); if (m.getBalance() amount) { int newBalance m.getBalance() - amount; m.setBalance(newBalance); memberMapper.update(m); }这段代码单机串行跑没有任何问题但在真实场景里同一个会员可能同时从线下收银台和线上小程序发起两笔扣款请求。两个线程同时读到余额是500同时判断余额够同时扣100最终数据库里余额变成400而不是300——这就是经典的并发超扣问题。正确的做法是不要把“读余额→判断→更新”拆成三步而是直接交给数据库去原子执行int count memberMapper.deductBalance(memberId, amount); if (count 0) { throw new BusinessException(余额不足); }对应的SQL就一句update t_member set balance balance - #{amount} where id #{memberId} and balance #{amount}这条update语句的where条件带上了balance #{amount}数据库的行锁会让并发请求排队执行第二个请求执行时余额已经不够影响行数为0代码里就能感知到异常并抛出业务提示。这个模式叫“乐观锁思想在余额扣减上的应用”面试官看到这个写法一般都会眼前一亮。3.2 收衣与订单创建一次业务的完整链路以“收衣下单”为例把一次完整的前后端调用链路讲透。前端页面提交表单表单字段包括会员手机号、门店ID、一个包含多件衣物信息的数组、衣物名称、洗护类型、是否加急等。Controller层拿到请求后把参数转成DTO传给ServiceController RequestMapping(/order) public class OrderController { Autowired private OrderService orderService; RequestMapping(value /create, method RequestMethod.POST) public String create(OrderCreateDTO dto, Model model) { try { orderService.createOrder(dto); model.addAttribute(msg, 下单成功); } catch (BusinessException e) { model.addAttribute(msg, e.getMessage()); } return order/result; } }真正的业务在OrderServiceImpl里。创建订单的方法我建议用事务包裹起来流程是按手机号查会员如果不存在直接抛异常生成订单号插入订单主表遍历DTO里的衣物列表逐条生成订单明细记录扣减会员储值余额用刚才的行锁式SQL如果余额不够抛异常让事务整体回滚。这一段逻辑就是整个项目最大的核心亮点Transactional(rollbackFor Exception.class) public void createOrder(OrderCreateDTO dto) { Member member memberMapper.selectByPhone(dto.getPhone()); if (member null) { throw new BusinessException(会员不存在请先开卡); } Order order new Order(); String orderNo generateOrderNo(dto.getStoreId()); order.setOrderNo(orderNo); order.setStoreId(dto.getStoreId()); order.setMemberId(member.getId()); order.setStatus(0); // 0表示待洗涤 order.setCreateTime(new Date()); orderMapper.insert(order); for (WashItemDTO item : dto.getItems()) { OrderItem orderItem new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setItemName(item.getItemName()); orderItem.setWashType(item.getWashType()); orderItem.setPrice(item.getPrice()); orderItem.setStatus(0); orderItemMapper.insert(orderItem); } BigDecimal totalAmount calcTotalAmount(dto.getItems()); int count memberMapper.deductBalance(member.getId(), totalAmount); if (count 0) { throw new BusinessException(储值余额不足请联系前台充值); } order.setPaidAmount(totalAmount); orderMapper.updatePaidInfo(order.getId(), totalAmount); }订单号生成也有门道不要用自增ID直接当订单号展示给顾客太容易暴露当日单量。我用的方案是日期门店编号四位随机数比如2025060810230001这样做的好处是光看订单号就能判断出哪个门店、哪一天的订单捡起来排查效率会高很多。3.3 洗衣状态流转与衣物跟踪衣物状态是这个项目里容易做糊的部分。我在订单明细表里加了一个独立的状态字段每件衣物在当前订单下的生命周期是这样的0待洗涤、1洗涤中、2待取件、3已完成、4异常比如洗坏了需要沟通处理。订单主表的status字段和明细表status字段的联系是只有明细表所有衣物都是待取件状态主表才显示为待取件只要有一件还在洗涤主表状态就不能变。收衣时打印的小票上会有一个衣物编号通常就是明细表的自增ID。这个编号打印成条码后贴袋子上洗涤工人在每个环节都扫一下、更新状态顾客来电询问时前台输入编号就能定位衣物现在到哪个工序了。这个功能实现起来不复杂但在总结项目经验时非常加分因为它很直观地解决了连锁洗衣店最容易出现的“衣服不知道洗到哪去了”的痛点。3.4 门店与员工权限控制连锁模式的数据隔离连锁店系统里最容易被忽视的问题是数据隔离。如果不做隔离石家庄某门店的收银员登录系统后能查到北京某门店的订单明细这绝对是不行的。所以我在员工表里设计了store_id字段所有订单表里也都有store_id字段。查询时Controller从登录Session中取当前员工所属的storeId传给ServiceService作为查询条件传给Mapper在SQL层面完成数据过滤select idselectStoreOrders resultTypecom.laundry.entity.Order select * from orders where store_id #{storeId} if teststatus ! null and status ! and status #{status} /if /select登录拦截用Spring MVC的HandlerInterceptor实现。重写preHandle方法检查Session中有没有当前登录用户没有就重定向到登录页有就继续放行。对不同角色的功能入口可以对每个菜单按钮做角色编码校验但放在项目里不用做太复杂只要保证“店长只能看见本店数据”和“员工必须登录才能操作”这两条底线就已经达标了。4. 从0到1跑通这个项目——环境搭建与部署实战这个项目从空环境到能本地跑起来我建议完全按照下面的顺序来做能给你省掉无数次瞎折腾的时间。4.1 环境版本搭配版本兼容是SSM项目第一个拦路虎。我实测下来比较稳的一套组合是JDK 1.8SSM项目的老搭档不要图新鲜去用JDK 17老框架在某些版本下会出现奇怪的兼容问题比如源发行版17需要目标发行版17这类编译错误。Maven 3.6.3依赖管理工具3.6以上版本对旧项目的兼容性比较好。Tomcat 8.5支持Servlet 3.1SSM项目部署完全没有问题。MySQL 5.7使用范围最广教程最多遇到问题更容易搜到答案。IDEA开发工具不解释。4.2 项目目录结构与Maven依赖标准SSM项目一定要按包结构分层不要图省事把Controller和Service写在一起。我的结构是这样com.laundry ├── controller ├── service │ └── impl ├── mapper ├── entity ├── dto ├── common │ └── interceptor └── exceptionpom.xml里的核心依赖大概有这些spring-webmvc、spring-jdbc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databind以及JSP需要的jstl和servlet-api。版本号建议统一用Spring 5.2.x、MyBatis 3.5.x这两个大版本之间的兼容性已经非常成熟。4.3 三个核心配置文件怎么协同SSM项目里配置文件的角色经常把人绕晕。我用自己的理解给你捋一遍web.xml整个Web应用的入口。它负责两件事一是注册ContextLoaderListener加载Spring根容器二是配置DispatcherServlet并指定加载spring-mvc.xml。spring-mvc.xmlSpring MVC专属配置。component-scan只扫描Controller包配置InternalResourceViewResolver视图解析器关联JSP页面的前缀后缀。再配上注解驱动mvc:annotation-driven/。applicationContext.xmlSpring核心配置。配置数据源DruidDataSource配置SqlSessionFactoryBean并指定MyBatis核心配置文件和Mapper XML路径配置MapperScannerConfigurer扫描mapper包最后配置DataSourceTransactionManager事务管理器并开启事务注解驱动。这三个配置文件各管一段不要堆到一起。我在很多同学的项目里看到过他们把数据源和Controller扫描写在一起能跑但后续维护起来非常头疼。4.4 从启动到联调跑通整个项目的关键步骤新项目第一次启动不要试图把所有模块同时都测一遍那样出了问题根本定位不到。我推荐按下面这条链路来测第一步验证数据库层先直接写一个MyBatis测试通过Mapper查出一条会员记录输出到控制台。这一步通了说明数据库连接池、SqlSessionFactory、Mapper代理全部没问题这是整个项目的地基。第二步验证Spring MVC层写一个最简单的Controller方法返回固定字符串页面浏览器访问看能不能正常打开。通了说明DispatcherServlet的映射逻辑没错。第三步验证登录功能从登录页开始输入账号密码走一遍完整的Controller→Service→Mapper链路。这一步通了说明三层框架的联动已经没问题。第四步验证核心业务再造一个会员、充一笔值、下一笔订单、走一遍取件。这四步全跑通这个项目的主流程就已经完整了。实测过程中最容易卡住的点就是各个版本之间的兼容性。我踩过的最深的坑是把Spring升级到6.0结果javax.servlet包全部变了整个项目报错报成一片红。所以这里强调一句SSM项目别追新稳妥优先。5. 常见问题与排查技巧实录做SSM项目运行期最常见的坑就那么几个。我把它们集中列出来并给出可以直接套用的排查思路。5.1 数据库连接失败与驱动坑现象是启动时日志报Cannot create PoolableConnectionFactory或者Access denied for user。前者大概率是连接URL配置不对后者是用户名密码不对。我的连接URL是这样的jdbc:mysql://localhost:3306/laundry?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue没有useSSLfalse和serverTimezone这两个参数MySQL高版本连接时会报SSL和时区错误。useUnicodetruecharacterEncodingutf8则直接决定了中文能不能正常写入数据库这个参数忘掉的话页面上显示的中文可能全是问号。5.2 Maven依赖冲突与缺失典型报错是启动Tomcat时出现NoClassDefFoundError或ClassNotFoundException。一半以上的情况是依赖版本冲突导致某些类没有被加载进来。我的建议是统一在pom.xml的properties里声明版本号别一个依赖一个版本号乱写。重点检查spring-core、spring-webmvc、spring-jdbc这三个包的版本是否一致不一致会出现奇怪的方法找不到异常。5.3 404和500的排查思路404分两种。一种是页面文件不存在检查页面是否放在webapp/WEB-INF/views/目录下视图解析器的前缀后缀是否匹配另一种是请求路径映射不匹配检查Controller的RequestMapping和前端提交的action是否完全一致连末尾的斜杠都不能不同。500错误看异常堆栈比看页面更直接地朝着自己找servlet异常还是Spring容器初始化异常。如果是容器初始化就失败了重点排查配置文件加载顺序、包扫描路径有没有写错。5.4 中文乱码的完整治理中文乱码是个“多段联动”的问题不是改一处就完事。我的治理策略是一口气把四处全部设置好JSP页面设置UTF-8页面顶部写% page contentTypetext/html;charsetUTF-8 languagejava %。请求参数编码在web.xml里配置CharacterEncodingFilterforceEncoding设置为true。数据库连接URL加useUnicodetruecharacterEncodingutf8。数据库表编码建表时统一用utf8mb4。这四处缺一处都可能在某个不起眼的环节冒出来乱码等跑上线再回头找就晚了。5.5 事务不生效的经典原因这是Java面试的高频考点也是实际项目里的大坑。如果你给Service方法加了Transactional却发现数据没有回滚优先排查下面几件事类内部直接调用同类中一个方法调用另一个加事务的方法事务会失效。因为Spring AOP代理只能拦截从外部进入的方法调用。方法被catch住了事务方法内部抛了异常但调用方把异常吞掉没有继续往外抛Spring感知不到异常就不会回滚。方法不是publicSpring的声明式事务基于代理非public方法不会被代理拦截。没有配置事务管理器只加了注解但applicationContext.xml里没有配置DataSourceTransactionManager和注解驱动注解是不生效的。这四条我能背得滚瓜烂熟因为在项目里真的每一行都踩过。排查顺序也固定先去applicationContext.xml看事务管理器和tx:annotation-driven/配置再确认方法的修饰符和调用链最后看异常是不是被吞了。这套顺序能解决九成以上“事务不生效”的问题。做一个连锁洗衣店管理系统真正有价值的地方不在于功能多花哨而在于你通过它把Java Web开发的主干知识串成了一条完整的线。Spring的IoC和事务机制、Spring MVC的请求处理链路、MyBatis的SQL映射、数据库的事务和并发控制这些知识点在面试题里背得再多都不如亲手在一个完整项目里遇到问题再去解决来得深刻。我在写这个项目时最真实的体会是遇到报错不要急着搜答案先看完整的异常堆栈定位到具体哪一行出了事再去看配置、看依赖、看SQL一步步拆下来问题往往没那么可怕。后续你可以尝试把它往两个方向扩展一个是把前端换成小程序或Vue改成前后端分离的架构另一个是引入Redis缓存门店的洗护项目和会员信息这也是很自然的演进方向。如果这个项目帮你跑通了第一版那恭喜你你的Java Web基础已经打得非常扎实了。