做美发商城这个项目起因特别简单我常去的那家理发店老板还在用本子记预约会员余额靠手写月底对账的时候焦头烂额。他跟我吐槽了几句我索性就把它当成了一个完整的Spring Boot实战项目来做。这个系统的核心目标是把美发店的用户端商城、预约排班、会员卡管理和后台订单处理全部串起来形成一个可以直接上线运营的管理闭环。技术选型上我没有犹豫直接用了Spring Boot。原因很简单Spring Boot在Java后端领域的生态太成熟了内嵌Tomcat、自动配置、起步依赖这套机制能让我把精力放在业务逻辑而不是繁琐的配置上。项目本身涉及用户登录、商品下单、预约排班、订单超时处理、会员余额变动这些典型场景几乎涵盖了企业级应用开发会遇到的所有基础问题。如果你正在学Spring Boot想找一个能写进简历的完整项目这个选题非常合适——它不是一个玩具级的CRUD而是有真实业务复杂度在里面的。在开始动手前我把自己代入“这个系统的实际运营者”的角色把需求逐条列了出来。然后根据需求去反推数据结构、接口设计和页面交互。整个过程走下来我最大的感受是系统的难点从来不在Spring Boot本身而在于你怎么把现实世界的业务规则翻译成表结构、状态机和事务边界。1. 需求拆解与技术选型先把业务边界画清楚1.1 美发店的真实痛点是什么不做需求调研就写代码写出来的大概率是自嗨。我去跟几家美发店老板聊过他们的痛点高度一致预约经常撞车顾客到店要等半小时会员卡余额多少、有效期到哪天全凭收银员的记忆想搞个促销活动新客来了也没办法快速转化每天做了多少单、哪个项目最赚钱基本靠月底翻账本。所以这个系统的核心需求不是“做一个商城”而是“帮老板理清三件事”预约安排得明明白白、会员资产记得清清楚楚、经营数据看得明明白白。围绕这三点我再把功能拆成两条线——C端用户能预约、能买卡、能下单B端管理员能管员工、管服务项目、管订单、管数据报表。1.2 为什么坚持用Spring Boot而不是其他框架我见过很多人纠结SSM和Spring Boot我觉得这根本不应该成为一个纠结的点。Spring Boot本质上就是把Spring框架的配置自动化了内嵌容器、自动装配、健康检查、外部化配置这些能力直接省掉了传统SSM项目里一堆的XML配置。对于美发商城这种中小型系统Spring Boot是性价比最高的选择。除了框架本身版本选择也得花点心思。我用的组合是Spring Boot 2.7.x JDK 8这两个版本搭配非常稳定网上资料也多碰到问题几乎都能搜到解决方案。MySQL用的8.0Redis用的6.xMyBatis-Plus用的3.5.x。这组搭配经过了大量生产项目验证踩坑成本最低。Spring Boot 3.x确实已经出了强制要求JDK 17。如果你的学习环境或者公司技术栈还没有升级到JDK 17我建议还是先用2.7.x等JDK版本跟上节奏了再迁移也不迟。1.3 持久层选型为什么用MyBatis-PlusORM框架我毫不犹豫选了MyBatis-Plus。它的ActiveRecord模式和条件构造器能让单表CRUD变得极其简洁同时又保留了XML写SQL的能力对于那些需要多表联查、复杂统计的场景我可以直接写原生SQL控制执行计划。JPA虽然开发效率也很高但遇到复杂查询时那个SQL自动生成的逻辑调试起来是真的头疼。MyBatis-Plus还有一个特别好用的功能是分页插件一行配置就搞定物理分页。商城系统的商品列表、订单列表全是分页场景这个插件帮我省了大量重复代码。代码生成器也很好使我直接用MyBatis-Plus Generator根据数据库表反向生成entity、mapper、service、controller骨架代码秒出然后专心写业务逻辑。2. 数据库设计与核心模块拆解地基不能歪2.1 核心数据表都有哪些这个系统的数据库我设计了两张核心的交易类大表——预约表和订单表围绕它们展开会员、商品、员工、服务项目这些基础表。下面我把关键表的结构和业务含义梳理一下表名核心字段业务说明userid, nickname, phone, password, balance, level用户表balance存余额level存会员等级employeeid, name, title, avatar, service_ids员工表service_ids存该员工能提供的服务项目ID集合service_itemid, name, duration, price, category服务项目表剪发、染发、烫发等appointmentid, user_id, employee_id, service_id, appointment_time, status预约表status有PENDING/CONFIRMED/COMPLETED/CANCELLEDmember_cardid, user_id, card_type, balance, discount_rate, expire_time会员卡表存储余额和折扣率productid, name, price, stock, sales, image商品表洗护用品等有库存字段ordersid, order_no, user_id, total_amount, status, create_time订单表总表order_itemid, order_id, product_id, quantity, price订单明细表记录每件商品快照service_item和product要分开设计这点很重要。服务项目是“人的技能时间”的售卖商品是实体物品的售卖两者的库存逻辑完全不同——服务项目没有库存但你得考虑员工的时段冲突商品则是纯粹的数量扣减。不区分清楚后面写业务逻辑的时候一定会打架。2.2 预约冲突检测这个SQL是核心中的核心预约系统最难的一个点就是“同一时间段的冲突检测”。某个发型师一天的时间是固定的如果你在9点到10点已经被预约了那新的预约就不能再落到这个区间。我第一次实现的时候是在Java代码里先把该员工当天的所有预约查出来再一个个判断时间段是否重叠。数据量小的时候没毛病但一旦某天预约量大了这种写法效率堪忧。后来我把冲突检测直接下沉到了SQL层用一个很经典的重叠区间查询SELECT COUNT(*) FROM appointment WHERE employee_id #{employeeId} AND status IN (PENDING, CONFIRMED) AND appointment_time #{endTime} AND DATE_ADD(appointment_time, INTERVAL #{duration} MINUTE) #{startTime}这个SQL的思路就是如果一条已存在的预约的开始时间早于新预约的结束时间并且它的结束时间晚于新预约的开始时间那这两个区间必然重叠。用这个条件去查只要count大于0就该提示用户换时段。理解了区间重叠判断等于拿下了所有预约类系统的核心逻辑这个思路放到医院挂号、会议室预订上一样成立。2.3 为什么订单要设计成主从表结构商城购物车下单的时候一个订单可能包含好几个商品如果每个商品都直接挂在orders表里加一行后面要查“某个订单有哪些商品”或者“某个商品在哪些订单里出现过”写出来的SQL全是噩梦。所以我设计了orders和order_item两张表orders只存订单的公共信息order_item存每个商品的数量和当时的快照价格。快照价格这个细节非常关键。商品价格是会变的如果订单里只存了商品ID等用户查看历史订单时去关联查product表的价格一旦这期间商品做过促销或者改价订单金额就对不上了。所以在order_item里必须冗余一份“下单那一刻的价格”和商品名称这在电商系统里叫做“订单快照”能有效避免金额纠纷。3. 核心功能实现与关键代码把业务规则变成可执行逻辑3.1 预约模块从创建预约到状态流转的完整实现预约是美发系统的门面功能用户的操作路径是选发型师 → 选服务项目 → 选时间 → 提交预约。后端在处理这个流程时需要同时操作两张表appointment表插入预约记录同时还要考虑用户使用会员卡折扣后的实际支付金额。预约状态下单的核心逻辑我用一个事务方法包起来Transactional(rollbackFor Exception.class) public AppointmentResult createAppointment(AppointmentCreateDTO dto, Long userId) { // 1. 校验用户是否存在且状态正常 User user userMapper.selectById(userId); if (user null || user.getStatus() ! 1) { throw new BizException(用户不存在或已被禁用); } // 2. 校验员工是否能提供该服务 Employee employee employeeMapper.selectById(dto.getEmployeeId()); String[] serviceIds employee.getServiceIds().split(,); if (!Arrays.asList(serviceIds).contains(String.valueOf(dto.getServiceId()))) { throw new BizException(该员工不提供此服务项目); } // 3. 校验时间段是否冲突用上面的重叠区间SQL ServiceItem service serviceItemMapper.selectById(dto.getServiceId()); Integer count appointmentMapper.checkTimeConflict( dto.getEmployeeId(), dto.getStartTime(), service.getDuration()); if (count 0) { throw new BizException(该时间段已被预约请更换时间); } // 4. 生成预约单初始状态为PENDING Appointment appointment new Appointment(); appointment.setUserId(userId); appointment.setEmployeeId(dto.getEmployeeId()); appointment.setServiceId(dto.getServiceId()); appointment.setAppointmentTime(dto.getStartTime()); appointment.setStatus(PENDING); appointmentMapper.insert(appointment); // 5. 推送提醒异步处理不阻塞主流程 asyncNotifyService.notifyEmployee(employee.getPhone(), 您有新的预约); return AppointmentResult.success(appointment.getId()); }这个方法的操作要点有两个。第一事务注解写的是rollbackFor Exception.class不这么写的话运行时异常虽然默认回滚但自定义异常和某些非运行时异常其实不会被回滚踩过一次就长记性了。第二异步通知不要放在主链路里否则短信服务超时会拖垮整个请求。3.2 会员卡与余额支付折扣计算与并发扣款美发店最常见的会员场景是“充值赠送”和“会员折扣”。我设计的member_card表里存了discount_rate这个字段0.8代表打八折。用户下单的时候系统先算出原价然后根据会员等级享受折扣再把扣款操作和余额更新放在同一个事务里执行。扣款这个操作有个大坑——并发问题。如果用户同时提交两个订单两次请求都读到余额是100元然后分别扣了80元最后余额就变成-60元了。经典的解决方案是“乐观锁”在SQL更新的时候带上余额条件Update(UPDATE user SET balance balance - #{amount} WHERE id #{userId} AND balance #{amount}) int deductBalance(Param(userId) Long userId, Param(amount) BigDecimal amount);这个SQL的关键在于WHERE条件里带了balance #{amount}如果余额不够这条update语句影响的行数就是0在Java代码里判断返回值只要等于0就直接抛异常提示余额不足。这种“数据库层面的原子扣减”比我之前在代码里先查再算再更新要安全得多也是目前主流的做法。3.3 高并发下的库存扣减秒杀场景的降级方案商城模块里有个高频问题库存扣减怎么保证不超卖“先查库存再update”这种写法肯定不行两个请求同时查到库存还有1件然后都执行扣减最后库存就变-1了。我用的方案跟余额扣减思路一致直接把库存判断塞进update语句里Update(UPDATE product SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{productId} AND stock #{quantity}) int reduceStock(Param(productId) Long productId, Param(quantity) Integer quantity);这里还有一道防线在创建订单前我先通过select查询判断库存是否充足真正扣减库存这个动作放在支付成功之后。也就是说下单只是占住库存不真正扣减。系统里我配合了“订单超时自动取消”机制如果用户下单后30分钟内没有支付定时任务会把订单置为CANCELLED同时把预占的库存加回去。真要做高并发秒杀项目的话Redis预扣库存 消息队列异步落库才是终极方案。但在美发商城这种量级下SQL层面的乐观锁扣库存已经足够稳定过度设计反而增加系统复杂度。3.4 订单状态机从下单到完成每个状态变更都有的放矢订单模块是商城的心脏我设计的状态流非常清晰PENDING待支付 → PAID已支付 → COMPLETED已完成 ↓ ↓ CANCELLED已取消 REFUNDED已退款这一步我用一个枚举来管理状态public enum OrderStatus { PENDING(0, 待支付), PAID(1, 已支付), COMPLETED(2, 已完成), CANCELLED(3, 已取消), REFUNDED(4, 已退款); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } // getter... }状态机的核心思想是每一次状态转移都是在特定业务动作触发下发生的不能允许订单跳状态。比如CANCELLED状态不能直接变成PAIDCOMPLETED不能直接变成REFUNDED后台如果手动改订单状态也得按状态机的通路走。为了做实状态机限制我在Service层写了状态校验逻辑不合法直接抛异常不给脏数据留后门。3.5 定时任务订单超时自动取消与预约到期提醒订单30分钟不支付要自动取消预约前1个小时要提醒用户到店。这两个需求都是典型的时间驱动型任务我直接用Spring自带的Scheduled注解实现。Component public class OrderTimeoutTask { private static final Duration TIMEOUT Duration.ofMinutes(30); Scheduled(fixedRate 60000) // 每60秒执行一次 public void cancelTimeoutOrders() { LocalDateTime deadline LocalDateTime.now().minus(TIMEOUT); ListOrders timeoutOrders orderMapper.selectList(new LambdaQueryWrapperOrders() .eq(Orders::getStatus, OrderStatus.PENDING.getCode()) .lt(Orders::getCreateTime, deadline)); for (Orders order : timeoutOrders) { order.setStatus(OrderStatus.CANCELLED.getCode()); orderMapper.updateById(order); // 还原预占库存 productMapper.restoreStock(order.getId()); } } }这里有个细节值得注意定时任务加了fixedRate属性意思是“上次任务开始执行后每隔60秒执行一次”。如果任务本身执行耗时较长fixedRate可能导致下一次任务立即开始有任务堆积风险所以任务逻辑要尽可能精简可以用try-catch包裹单个订单处理避免一个订单异常导致整个批处理中断。4. 安全控制与系统性能别让细节拖垮整个项目4.1 JWT认证与接口权限控制商城涉及用户资产和订单数据这些接口必须做权限控制。我用了JWTJSON Web Token做无状态认证用户登录成功后服务端生成一个签名Token后续请求在Header里带上这个Token拦截器解析Token拿到用户ID把用户信息放到ThreadLocal里供业务代码随时取用。拦截器是个好东西把“这个接口需要登录才能访问”这种横切逻辑统一收口。我在项目里配了两个拦截器规则/auth/** 不做拦截比如登录、注册、验证码业务接口统一拦截带着Token才能放行管理后台接口额外校验用户角色非管理员直接返回403。接口返回格式我也做了统一封装Result对象里包含code、message、data三个字段。code为200表示成功其他码对应各种业务异常。这样做的好处是前端处理响应时只需要判断code就能统一走错误提示逻辑不至于每个接口单独写一套异常处理。4.2 参数校验与全局异常处理接口层参数的校验我用了Spring Validation框架的Validated注解配合JSR-303规范DTO里直接写注解public class RegisterDTO { NotBlank(message 手机号不能为空) Pattern(regexp ^1[3-9]\\d{9}$, message 手机号格式不正确) private String phone; NotBlank(message 密码不能为空) Size(min 6, max 20, message 密码长度需在6到20位之间) private String password; }加上全局异常处理器RestControllerAdvice把参数校验异常、业务异常、系统异常统一拦截转换成标准Result返回。前端拿到的永远是结构一致的错误响应这在前后端联调的时候省了太多沟通成本。没有全局异常处理的项目一旦线上有个空指针返回给用户的就是一片堆栈信息基本等于把系统内部结构暴露给用户这不但是体验问题还是安全问题。4.3 Redis缓存热点数据的性能加速美发商城的商品列表和首页Banner这类数据有个明显特点读多写少且不要求实时性。每次请求都去打数据库完全没必要我用Redis做了缓存查询时先查Redis缓存没有再查数据库查到后回填Redis并且给缓存设置了过期时间防止脏数据常驻。商品详情缓存我设的是30分钟首页运营位的缓存是5分钟。这里要特别注意缓存穿透的问题如果某个商品ID根本不存在查询会一直打数据库。我的防护方案是查询结果为null的也往Redis里写一个空值设置较短的过期时间比如2分钟这样恶意用不存在的ID刷接口时Redis能在内存里直接挡住大部分请求。这招治标不治本但对付普通情况完全够用。4.4 SQL性能优化索引怎么建才能不踩坑商城业务里查询最频繁的几张表我建索引的时候分了两类唯一索引和普通联合索引。手机号是用户唯一标识直接在user表的phone字段建唯一索引订单号唯一orders表的order_no建唯一索引预约表的employee_id appointment_time经常一起查建联合索引employee_id, appointment_time。建索引的核心原则是“最左前缀法则”。联合索引(a, b, c)能走索引的查询条件是a、ab、abc如果你上来就查b那这个联合索引是发挥不了作用的。我在排查慢SQL日志时发现一次预约列表查询走了全表扫描就是因为查询条件是appointment_time而单独在appointment_time上没建索引。后来补了一个单列索引查询时间从1.2秒降到了50毫秒以内这种优化效果是立竿见影的。5. 部署上线与常见问题排查纸上谈兵不如动手跑一遍5.1 本地环境搭建与运行步骤在本地跑起来这个项目环境准备比你想象的简单。我建议步骤是——先装MySQL 8.0建好数据库库导入项目里的SQL初始化脚本再装Redis默认端口6379启动改application.yml里的数据源配置把MySQL的用户名密码改成你自己的最后用IDEA打开项目等Maven依赖下载完运行主启动类即可。如果启动时报端口冲突八成是8080端口被占用了。Windows下用netstat -ano | findstr 8080查看占用进程PID然后去任务管理器把这个进程结束或者在application.yml里把server.port改掉比如改成8081。这类小问题看着不起眼但能卡住新手一上午。前端页面我采用的是模板引擎加静态资源的方式没有做前后端分离。管理后台用的H5页面放在src/main/resources/static目录下跟后端打成一个包。这样部署起来就一个jar包特别适合个人项目和中小型团队内部系统。5.2 云服务器部署的完整流程开发完以后部署到云服务器我用的Linux Docker的方式。先把项目用Maven打成jar包然后写一个DockerfileFROM openjdk:8-jdk-alpine VOLUME /tmp ARG JAR_FILEtarget/haircut-mall.jar COPY ${JAR_FILE} app.jar ENTRYPOINT [java,-Djava.security.egdfile:/dev/urandom,-jar,/app.jar]然后通过docker build构建镜像docker run启动容器端口映射到宿主机的8080。MySQL和Redis同样用Docker跑通过docker-compose编排所有中间件一条docker-compose up -d命令就能把整个环境拉起来。最开始部署的时候我死活连不上MySQL排查了半天发现是没在MySQL容器里设置端口映射宿主机访问不到容器内部端口——遇到问题的时候先检查网络通不通再查账号权限这是部署排错的第一原则。5.3 高频Bug与解决方案速查表我把项目开发过程中最常遇到的问题整理成了一张表新手照着查就行问题现象根本原因解决方案请求接口返回401Token丢失或过期检查前端请求头是否带上AuthorizationToken过期则重新登录预约一直提示时间冲突区间重叠SQL条件写错用start newEnd AND end newStart这个标准重叠判断公式用户充值后余额没变事务没生效或扣款SQL返回0检查Service方法是否有Transactional打印update返回值商品库存变成负数扣库存SQL没加number条件update语句中补上AND stock #{quantity}条件定时任务不执行启动类没加EnableScheduling主类上加EnableScheduling注解列表查询越来越慢索引缺失或失效用EXPLAIN分析执行计划根据实际查询条件补索引中文乱码数据库连接URL没指定编码JDBC URL上加上characterEncodingutf8日期时间差了8个小时时区设置问题JDBC URL上加上serverTimezoneAsia/Shanghai这张表里的每一个问题我自己都碰到过。尤其是时区问题我印象最深刻——开发环境一切正常部署到服务器后所有时间都差了8个小时查了三小时才发现是MySQL连接参数少了serverTimezone。中文乱码和时区问题部署上线必查项提前配置好省得线上翻车。6. 项目后续还能怎么扩展进阶方向留给你这个系统的主体功能已经完整但真要面向真实的门店运营还有不少可以深挖的点。第一个是支付对接把微信支付或支付宝的接口接进来用户就可以在线充值、在线支付这是商城系统商业化运转的最后一环我在代码里预留了PayService的接口后面接一个实现类就行。第二个是消息通知预约成功、订单支付、营销活动推送这些场景都可以接短信或者微信模板消息提升用户的感知体验。第三个是营销工具美发店最常见的玩法是次卡、拼团、新人立减券围绕这个可以展开一个完整的营销中心模块。数据报表也值得单独做一个独立的模块把每天的营收、预约量、客单价、热门项目排行这些指标用图表展示出来可以集成ECharts做一个管理驾驶舱。老板打开后台就能看到昨天的经营情况这个功能比花里胡哨的各种动画页面实在得多。我在这个项目里花的时间大头不是Spring Boot本身而是一遍遍推演业务规则——一个预约状态该在哪个时机变一笔退款该怎么跟库存联动一个用户被删了以后他的历史订单还能不能查。做这个项目最大的收获是理解了“技术服务于业务”这句话的真正含义。如果你也在做类似的管理系统项目建议你不要照抄网上现成的代码自己从零建表、自己定接口把每一个业务规则想透彻遇到了bug就当场排查解决这些过程比最终跑通的结果更有价值。遇到困难卡住的时候去官方文档翻翻去技术社区搜搜把这个项目的每个模块都亲手实现一遍你会发现Spring Boot的大门已经为人打开了一大半剩下的路就是在一个个真实业务场景里慢慢走出来的。