基于SpringBoot的美发商城系统：从业务设计到部署实战解析-平芜编程栈

最近好多人在折腾毕设和课设，Java后端方向的题目里，“基于SpringBoot的美发商城系统”这类的出现频率是真不低。这套东西通常打包了源码、LW（说明文档）、部署文档和一整套讲解视频，看着挺全。但我也见过不少朋友拿着这套资源，卡在环境配置、业务表设计、甚至启动报错上，半天跑不起来。今天这篇就是专门来讲讲这个东西到底怎么拆、怎么改、怎么顺顺利利跑起来，还会把里面最关键的几个业务逻辑和坑点都扒开说清楚，希望能帮你少走点弯路。

这套系统的核心就是用SpringBoot搭一个美发行业的线上商城，跟普通卖衣服卖数码的电商有点区别，它身上带着很明显的“服务业+零售”双重属性。你打开一个正常的美发商城系统，用户端一般能看到这些功能：在线浏览美发服务项目（剪发、染发、烫发）、查看技师信息与排班、购买美发产品（洗发水、护发素等）、预约到店时间、下单结算、充值会员卡、领取优惠券、积分抵扣。管理后台则负责维护项目分类、库存管理、订单审核、预约排期、会员与营销配置等。整条链路牵扯到服务型商品的虚拟库存、技师的时间段排期、会员储值金额的冻结与扣款，比单纯卖实体商品的商城要多想好几层。

这篇文章会按我们实际做项目时的顺序来展开，先聊整体设计和模块划分，再拆核心代码逻辑和数据库表关系，接着讲部署和初始化数据，最后把高频报错和排查思路整理出来。适合正在做毕设、准备面试项目、以及想快速搞懂SpringBoot商城业务闭环的同学。如果你是零基础刚学完JavaWeb，想拿这个项目来练手，也完全没问题，文中我会把一些前置概念尽量讲得白话一点。

1. 项目定位与整体设计思路

1.1 美发商城和普通电商的区别在哪

很多人拿到这套系统，第一反应就是照着淘宝的架构去看，然后发现怎么对不上。这就是没理解美发商城的业务模型。美发商城卖的东西分为两大类：一类是实体商品（洗护产品、造型工具），走标准电商的SKU、库存、物流逻辑；另一类是服务项目（剪发、染发、烫发、头皮护理），这类商品有几个非常特殊的属性。

服务项目没有实体库存。你不能说“剪发这个商品库存还有5件，卖完就没了”，你得按技师的可用时间段来约束。比如店里3个理发师，每人每天8个时段可以预约，那今天的可售“服务容量”就是24单，这个容量跟商品库存逻辑完全两码事。

服务项目天然绑定时长和人员。染发项目可能耗时2小时，快剪可能只要20分钟。在设计订单项和预约表时，必须存下预计时长、对应技师、对应门店，不然排期没法算。

服务项目的结算往往更复杂。美发行业普遍有会员折扣、储值赠送、套餐划卡这些玩法，一个订单算下来可能是“商品原价 = 服务价格 + 产品价格，然后会员打8折，再减优惠券，再用积分抵现，最后从储值余额里扣”。这个计算链条如果放在代码里硬写，后患无穷。

所以在拿到这套项目源码后，我建议你先把数据库表结构看明白，不要急着跑代码。看明白表结构，业务模型就懂了大半，后面看代码、改功能都会顺手很多。

1.2 技术选型为什么是SpringBoot这一套

毕设和课设场景下，绝大多数人选的不是SpringBoot，而是SSH或SSM这些老框架，或者是SpringBoot这一套。现在用SpringBoot的最大原因就是快，约定优于配置，内嵌Tomcat，一个java -jar就能启动。对于做毕设的同学来说，不需要去折腾Tomcat的独立部署，也不用写一堆XML配置，这点能省下大量时间。

具体到这套美发商城系统，技术栈基本逃不出下面这几样，跟标题和相关热词的高频匹配度也很高：

后端框架：SpringBoot 2.7.x（稳定，资料多，对应JDK 1.8完全没压力）
持久层框架：MyBatis-Plus（单表CRUD几乎不用写SQL，分页插件好使）
数据库：MySQL 5.7或8.0（注意8.0的驱动和时区配置有点区别）
安全认证：JWT + Spring Security 或拦截器（无状态登录，前后端分离必备）
缓存：Redis（存验证码、Token黑名单、热门服务列表）
前端：Vue 2 + Element UI（后台管理）+ 微信风格的H5或响应式页面（用户端）

用这套组合的原因很现实，一是社区资料最全，不管卡在哪一步，搜索一下都有答案；二是从就业角度来看，SpringBoot + MyBatis-Plus + Vue是一线中小型公司的常见搭配，做这套项目写在简历上，面试官看着不陌生，提问也有抓手。

提示：如果你发现这套源码里的SpringBoot版本是2.7.x，而本地Idea创建的SpringBoot项目默认变成了3.x，能不用就别用3.x。SpringBoot 3最低要求JDK 17，而很多毕设代码是基于JDK 8写的，一升级会有大量依赖不兼容。

1.3 模块划分与数据库设计要点

拿到源码后，第一步看包结构。合理的模块划分应该是这样的：

com.example.hairshop ├── common // 通用工具、统一返回结果、异常处理 │ ├── Result.java │ ├── ResultCode.java │ ├── GlobalExceptionHandler.java │ └── JwtUtil.java ├── config // 配置类 │ ├── MybatisPlusConfig.java // 分页插件 │ ├── RedisConfig.java // Redis序列化配置 │ ├── WebMvcConfig.java // 拦截器注册、跨域配置 │ └── Knife4jConfig.java // 接口文档配置 ├── controller // 接收请求，参数校验，返回结果 │ ├── UserController.java │ ├── ServiceItemController.java │ ├── AppointmentController.java │ ├── OrderController.java │ ├── StylistController.java │ └── AdminController.java ├── service // 业务逻辑层（重点，核心业务都在这） │ ├── OrderService.java │ ├── AppointmentService.java │ ├── MemberService.java │ └── impl/ ├── mapper // 数据访问层，继承BaseMapper<T> ├── entity // 数据库实体类 ├── dto // 前端传输对象（登录请求、下单请求等） ├── vo // 返回给前端的数据对象（订单详情、购物车VO等） └── utils // 日期工具、金额工具

数据库表设计是这套系统能不能跑的根基。我建议重点看这几张表的关系：

表名	作用	关键字段	关联说明
member	用户/会员表	id、phone、password、balance、points、level_id	余额和积分独立存，方便业务使用
member_level	会员等级表	id、name、discount、min_points	折扣在这里配置，不要写死在代码里
stylist	技师表	id、name、avatar、service_ids、status	一个技师能服务多个项目，用逗号分隔或建中间表
service_item	服务项目表	id、name、price、duration、category_id	与技师存在多对多关系（中间表）
product	商品表	id、name、price、stock、status	实体商品，走库存扣减逻辑
appointment	预约表	id、member_id、stylist_id、service_id、date、time_slot、status	预约是美发商城的核心节点，必须设计好
orders	订单表	id、order_no、member_id、total_amount、pay_amount、pay_type、status	订单状态流转很关键
order_item	订单明细表	id、order_id、item_type、item_id、item_name、price、quantity	item_type区分服务或商品，一张表搞定两类商品
coupon	优惠券表	id、name、type、discount_amount、threshold、expire_date	满减券为主，复杂玩法可扩展
member_coupon	用户持有优惠券	id、member_id、coupon_id、status	领取后在用户包内，需绑定用户

细看这几张表你就会发现，它把“服务项目”和“实体商品”统一放到了订单明细表里，靠着item_type字段来区分。这是个很聪明的设计：下单、支付、订单列表查询可以走同一套代码，不需要分别写两套订单逻辑。你后面要是想加“美容项目”或“美甲项目”，只需要在service_item里加数据，代码一行都不用多改。

2. 核心业务实现：从下单逻辑拆美发商城的难点

2.1 服务类商品的SKU怎么设计

普通商品下单，前端传商品ID和数量，后端查库存、扣库存、生成订单，完事。但服务项目不能这么搞。你去理发店剪头发，选择的是“简约剪发 + 中级技师 + 明天下午3点”这样一个组合。这个组合在数据库里怎么表达？

很多新人会犯的错误是给服务项目造一堆SKU，比如“简约剪发-高级技师-周一上午”对应一个SKU，“简约剪发-高级技师-周一下午”又对应一个SKU。这样做库存管理会爆炸，因为技师和时段是动态排的，你几乎不可能把所有组合全部铺在库存表里。

正确的做法是把服务项目表单独维护，基本属性是价格、时长、分类；技师的可用时段放在预约表里动态判断。用户下单时，请求参数应该长这样：

{ "memberId": 1, "stylistId": 3, "serviceIds": [12, 15], "appointmentDate": "2025-06-20", "timeSlot": "15:00-16:00", "productItems": [ { "productId": 5, "quantity": 1 } ], "useBalance": true, "couponId": 8 }

后端要做两件事：第一，校验这个技师这个时段是不是已经被预约了；第二，把serviceIds对应的服务项目价格加上productItems的商品价格，算出一笔总账。

校验预约的核心SQL就是查appointment表，看这个stylist_id、这个date、这个time_slot有没有status != '已取消'的记录。在SpringBoot里既可以用MyBatis-Plus的QueryWrapper直接查，也可以通过自定义SQL用排他锁（SELECT ... FOR UPDATE）来防止并发下单同一个时段。

我个人的建议是，在这种场景里老老实实用数据库唯一约束或者加锁查询。如果项目用了Redis，可以按“stylistId + date + timeSlot”作为key加一个分布式锁，但那是提高并发上限的优化，毕设和中小门店压根不需要。你直接把预约写入SQL放在一个事务里，先查后插，再加个联合唯一索引（stylist_id, appointment_date, time_slot），在数据库层把并发问题防死，这是最稳妥也最好跟面试官解释的方案。

实操心得：数据库表加联合唯一索引这件事，是我在真实项目里被坑出来的。刚开始只靠代码里先查询再插入，测试时用postman同时发两个请求，结果两条预约都进去了，技师同一时间被约了两次。后来加上唯一索引，第二次插入直接报DuplicateEntry异常，再用全局异常处理器把提示改成“该时段已被预约”，问题彻底解决。

2.2 预约时段与技师排班如何落地

预约模块是美发商城系统跟普通电商差异最大的一块。普通电商的下单流程是“选商品 -> 下单 -> 支付 -> 发货”，美发商城多了一步“选服务 -> 选技师 -> 选时段 -> 下单预约 -> 支付 -> 到店核销”。

时段怎么设置？常见做法是把一天按固定间隔切成若干个时段，比如每30分钟或1小时一个时段，数据库里不太需要单独建时段表，直接在接口层做逻辑判断就行。核心判断逻辑需要校验两件事：一是所选开始时间不能小于当前时间（不能预约过去的时间），二是开始时间加上该服务项目的预计时长，不能超过技师当天的最晚可约时间。

举个例子，系统设定最晚可约时间是晚上8点。某个染发项目预计时长是120分钟，用户想约晚上7点，那7点到9点超出了最晚8点，这个预约就应该被拒绝。这种校验不是写在SQL里，而是在Service层写代码判断。对应的时间计算工具方法可以放在utils包下：

public boolean isWithinBusinessHours(LocalDateTime start, int durationMinutes, LocalDateTime latestEnd) { return start.isAfter(LocalDateTime.now()) && start.plusMinutes(durationMinutes).isBefore(latestEnd.plusMinutes(1)); }

判断时段是否被占用的逻辑，除了前面说的联合唯一索引，还有一个细节要注意：每个时段不能只存一个“开始时间”字段，还要把结束时间算出来存进去。比如一个技师下午2点到3点被约了快剪（30分钟），那这个技师可用的时间不是从3点开始，而是从2点30分开始。如果下一个预约是染发（120分钟），哪怕显示2点半开始，实际上他2点半开始染发，要做到4点半，这跟下一个预约的占用又会冲突。所以数据库里的appointment表建议存一个start_time和end_time，判断冲突时只要检查（newStart < oldEnd && newEnd > oldStart）即可，这是最经典也最不容易出错的重叠判断公式。

2.3 会员卡、积分、优惠券的三层折扣计算

美发行业最赚钱的其实不是单次服务费，而是会员储值和套餐卡。所以这套商城的定价模块一定要设计得灵活一点，不然上线之后发现改个折扣规则得动Java代码，那就很痛苦了。

推荐的设计是在订单结算时按固定顺序执行折扣链：

计算原始总金额：遍历订单明细，服务项目加商品，计算出totalAmount。
会员等级折扣：查询member表关联的level_id，再到member_level表拿discount值（比如0.8），把totalAmount乘以折扣，得到levelDiscountedAmount。
优惠券抵扣：判断用户选择的coupon是否满足使用门槛。比如满200减30，当前的levelDiscountedAmount如果大于200，就直接减30。
积分抵扣：积分和现金的兑换比例可以设置，比如100积分抵1元，在计算时做一次除法，然后把本次使用的积分记录下来。
最终支付金额：payAmount = 会员折后金额 - 优惠券金额 - 积分抵现金额。

这里有一个很关键的问题：计算过程中每一步的金额精度怎么处理？Java里用double算钱会出大事，0.1 + 0.2 = 0.30000000000000004这种事情在金额场景是不可接受的。项目里所有涉及金额计算的地方必须使用BigDecimal，并且要指定舍入模式：

BigDecimal totalAmount = BigDecimal.ZERO; // 累加时统一使用setScale(2, RoundingMode.HALF_UP) totalAmount = totalAmount.add(itemPrice.multiply(quantity)).setScale(2, RoundingMode.HALF_UP);

优惠券表和会员等级表尽量都做成数据库配置，不要写死在代码里。如果这个项目为了演示方便把会员折扣写死成固定值，我建议你改成从数据库查询，这样面试时可以说“折扣规则是动态配置的，后续可以做运营后台来调整”，这个点很加分。

会员储值余额的扣款，核心逻辑是事务性的。用户下单时勾选“使用余额”，后端先判断balance的bigdecimal值是否大于等于payAmount，如果不够就提示“余额不足，请更换支付方式”。够的话直接扣余额、更新订单状态为已支付。这里边的坑在于，如果后面用户取消订单要退款，你得把余额还回去。所以订单表里必须存两个字段：实际支付金额pay_amount和余额抵扣金额balance_amount。退余额的时候只退balance_amount那一部分，pay_amount走其他支付渠道原路退回。很多新手在这个地方不注意，一退订单把整个pay_amount从余额里退回去，商家直接倒贴钱。

2.4 订单状态机：从预约到完成的流转

订单状态设计得好不好，直接决定后面写代码顺不顺畅。美发商城的订单状态不能按传统电商那套搞，传统电商是“待支付 -> 待发货 -> 待收货 -> 已完成/已取消”，美发商城要加上预约动作和到店核销：

状态	含义	触发动作
PENDING_PAYMENT	待支付	下单成功，此时预约记录是“已锁定”状态，给用户30分钟支付时间
PAID	已支付/待预约	支付完成，此时还没有绑定具体的技师和时段
APPOINTED	已预约/待服务	用户选择了具体的服务项目和技师时段
COMPLETED	已完成	用户到店经过核销，服务结束
CANCELLED	已取消	用户主动取消或超时未支付
REFUNDED	已退款	取消后完成退款的最终状态

一个很常见的简化做法是：用户在下单时已经直接把预约信息和订单一起提交了，也就是下单和预约是一体的。如果是这个流程，状态机可以压缩为“待支付 -> 已支付(预约成功) -> 已完成 -> 已取消”。这种简化在毕设里完全够用，但你要知道真实门店场景中用户往往是想先买张团购券，再打电话或在小程序里预约具体的到店时间，所以两个版本都有市场。

代码层面的状态流转建议只允许单向，不要封装一个通用的updateStatus方法到处调用，那样状态会乱飞。正确做法是写专门的状态变更Service方法，比如cancelOrderByUser、completeOrderByStore，每个方法里校验当前状态是不是期望的前置状态，再更新数据库。这一个细节在面试时提出来会显得你很有工程意识。

3. 部署与运行：从源码到上线全流程

3.1 环境准备与版本匹配

很多人在拿到源码后第1步就炸了：“明明代码没问题，怎么启动就报错？”这类问题十有八九是环境版本对不上。一套SpringBoot项目的运行环境，在开始之前就要明确锁定。

首先搞清楚JDK版本。看项目pom.xml里spring-boot-starter-parent的版本。2.x的SpringBoot配JDK 8或11都可以，3.x的SpringBoot必须JDK 17以上。如果你的电脑里装了多个JDK版本，Idea里记得检查Project Structure的Project SDK和Modules里的Language Level，必须保证是同一个版本。曾经见过一个同学，Project SDK选的是Java 17，结果Modules里language level还是5，编译直接报错，折腾了一下午。

数据库方面，需要确认MySQL版本。如果项目里配置的是com.mysql.jdbc.Driver，那对应的是MySQL 5.x时代的老驱动，需要换成com.mysql.cj.jdbc.Driver才能兼容MySQL 8.0。如果项目本身用的就是8.0驱动，而你本地装的是5.7，基本也能跑，但建议尽量保持一致。

Redis如果项目里有用到，需要先启动Redis服务，Windows直接启动redis-server.exe，Mac或Linux用redis-server。这里有个坑，Redis默认是只有本机能访问，安全组也不要对外开放，否则容易被入侵。

前端部分如果是Vue项目，需要Node.js环境。跑起来之前先看package.json里的scripts，一般是npm install然后npm run dev。node_modules安装失败的时候，把node_modules目录删掉重新install，比在那里冥思苦想原因实在得多。

3.2 配置文件里的那些坑

SpringBoot的配置文件通常叫application.yml或application.properties。一套能直接跑起来的配置，最小集合是这样：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hairshop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 database: 0 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto

重点提醒一下url里的serverTimezone参数。MySQL 8.0的驱动要求必须显式设置时区，否则会报“The server time zone value”相关的错误。你直接抄上面这段把Asia/Shanghai写上绝对没问题。

数据库名hairshop如果不存在，项目启动时会报错。所以一定要先执行项目里附带的sql文件。正常来说源码包里的sql目录下会有一个hairshop.sql或init.sql，用Navicat或MySQL命令行执行一遍即可。执行完成后，检查是否能查到数据库中的关键表，比如member、service_item，确认表里有没有初始化的管理员账号。

注意：别拿到源码就急着改代码，先把数据库、Redis、JDK这些环境准备到位，用源码自带的管理员账号登录一遍后台，走通流程再开始改功能。这个习惯能让你少加一周的班。

3.3 初始化数据与演示账号

一套完整的商城系统，数据库里必然要有一批演示数据，不然你登进去看到的是个空荡荡的页面，连买个东西都没法操作。正常来说，sql文件里会包含以下几类初始化数据：管理员账号和密码（存在admin表或member表里通过role字段区分）、分类数据（服务分类如剪发、染发；商品分类如洗护产品）、服务项目数据（比如“总监级剪发 ¥128”）、技师数据（姓名、头像、擅长项目、排班信息）、商品数据（洗发水、发膜等）、优惠券模板数据、会员等级数据。

拿到源码后第一件事是登录后台，如果文档没写初始账号，去看sql文件里的INSERT语句。有的源码密码是明文，有的用了MD5加密，数据库里存的是一串32位的哈希值。如果是加密的，你直接用文档里给的初始密码登录就完事了，千万别在数据库里把密码改成明文，除非你知道代码里的验证逻辑是什么格式。

如果你发现初始化数据太粗糙，比如就四五条商品记录，想多加几条，直接在数据库里插就行了。注意对应好表字段的格式，时间字段别传空字符串，数字字段别传字符串，外键别关联到不存在的记录。还有一点，插入服务项目时注意category_id是否正确，不然前端按分类筛选时商品会显示不出来。

3.4 前后端联调与接口验证

登录后台之后，接下来要验证核心链路通不通。我建议按下面这个顺序走一遍，每条记录都仔仔细细看返回数据：

用户注册 / 登录：验证JWT能正常签发，登录后本地能看到token。
浏览服务项目和商品：验证列表接口数据库连接正常、图片能正常加载。
添加商品到购物车：验证区域隔离逻辑和购物车表的写入。
下单结算：选服务项目 -> 选技师 -> 选时段 -> 提交订单。
支付：如果有支付沙箱配置就走沙箱，没有的话一般是在测试环境点“模拟支付成功”。
查看订单详情：确认订单状态更新正确，预约记录已生成。

如果联调过程中发现接口返回报错，先不急着看代码，直接看控制台日志。SpringBoot的报错堆栈会把问题原因打在最前面。最常见的几类报错无非是SQL语法异常（Mapper里的SQL写错了）、空指针异常（返回了结果为null的对象，调了它的方法）、参数绑定异常（前端传的参数名跟后端DTO的属性名对不上）。

联调阶段可以通过Knife4j或Swagger来测试接口，启动项目后访问/doc.html，就能看到所有的接口文档，可以直接在网页上发起请求，不必依赖前端页面的完整流程。就算前端还没写完，后端接口已经能用文档验证逻辑了。

4. 常见问题与排查技巧实录

4.1 SpringBoot版本太高导致的问题

这种问题几乎每隔段时间就能遇到一次。网上下的源码可能是两年前写的，SpringBoot用的2.3或2.4，你本地Idea新建模块时选了Spring Boot 3.2，然后把老代码往里一堆，报错报得怀疑人生。

老项目升SpringBoot 3.x的代价很大。首先javax.servlet包变成了jakarta.servlet，凡是用到HttpServletRequest、HttpServletResponse、Cookie这些老类的地方全部要改import。其次Spring Security 5升级到6，配置写法完全变了一套。再一个就是JDK最低要求17，很多用JDK 8的代码可能本身就没法在新版本下编译过去的。

你要是这份源码是用来交作业的，老老实实跟着项目原来的版本走。在项目根目录的pom.xml里，把SpringBoot版本改成2.7.18。这个版本是2.x系列的最终版，稳定得不行，资料也多。然后把JDK切成1.8或11，再把Maven的settings.xml里阿里云镜像配好，基本就不会再出什么幺蛾子。

4.2 端口占用、数据库连接失败等环境问题

端口占用是启动报错里出现频率最高的问题之一。SpringBoot默认的8080端口经常被其他程序占用。报错信息一般长这样：“Port 8080 was already in use.”。排查方法也很简单，先看看是哪个进程占用了端口才能确定解决方案。

在Windows下打开cmd，执行netstat -ano | findstr "8080"，找到占用端口的PID，再在任务管理器里找到这个PID的进程把它关掉，或者直接改配置文件里的server.port。改端口最省事，8000、8081、8888都可以，只要不跟其他服务冲突。

数据库连接失败就是另一种景象了。常见的是Caused by: com.mysql.cj.exceptions.InvalidConnectionAttributeException: The server time zone value，这个事情我在前面说过了，url里加serverTimezone=Asia/Shanghai就能解决。还有一种Communications link failure提示，大概率是MySQL服务没启动，Windows下要看服务列表里MySQL服务是否运行，Mac下要检查是否在系统设置里开启。

Redis连不上的报错也很典型，启动日志里刷一堆Unable to connect to Redis，让你怀疑是不是密码不对。先确认本地有没有启动Redis进程，再看application.yml里redis.host和port配得对不对，最后再确认密码字段。这三点排查完，99%的Redis连接问题都能解决。

4.3 首次启动报错排查思路

我第一次带着学生跑这套项目的时候，前前后后处理过大概二十多种稀奇古怪的启动报错。这里我把排查思路整理成一个可复用的流程，能帮你省掉大量试错的时间。

第一，看启动日志的报错堆栈。SpringBoot的报错信息算是Java框架里最友好的了，一般最后一行会直接告诉你原因。不要从头翻日志找半天，直接从最后的ERROR或Caused by开始往上翻。

第二，看到BeanCreationException，优先怀疑自动装配的依赖没配齐。比如RedisTemplate创建失败，一定是Redis没配好；DataSource创建失败，一定是数据库连接参数不对。

第三，看到ClassNotFoundException或NoClassDefFoundError，大概率是Maven依赖没导完整。这时候在Idea右侧的Maven面板点一下刷新按钮，让依赖重新拉取。如果还是不行，把本地仓库里对应的依赖目录删掉，重新刷新下载，强制拉最新包。

第四，启动成功了但页面白屏或404，多数情况是前端静态资源路径不对或没配置静态资源映射。SpringBoot默认把static目录下的文件作为静态资源映射，如果你把前端页面放在WEB-INF目录下，那就访问不到了，需要加个配置类实现WebMvcConfigurer，addViewControllers指向对应的页面。

4.4 部署文档里没写的那些事

有很多同学毕业设计答辩的时候会被要求演示项目部署。这里说几个容易被忽视的点，也是部署文档里通常不会详细写清楚的东西。

第一个是Maven仓库配置。如果本地的Maven用的是中央仓库，在国内下载依赖会慢到怀疑人生。回头看看Maven安装目录下conf/settings.xml，把阿里云镜像配上去。很多遇到过的问题都可以从这一步开始排查，依赖都下不下来后面所有操作都是空中楼阁。

第二个是数据库初始化脚本的执行顺序。有些sql文件里包含了创建数据库的语句，有些没有。你要先去文件里看一下，如果有CREATE DATABASE就整个文件直接执行一遍；如果没有，先在Navicat里手工创建一个数据库，再选择这个库执行sql文件里的表结构和数据。顺序搞反了数据库就会缺失。

第三个是演示时的数据准备。答辩当天千万别用刚初始化完的空数据去演示，最好提前在系统里造一批带业务状态的订单数据，待支付的、已支付的、已完成的各来几条，演示到不同功能时能直接展示，省得现场操作半天。这是一个看起来很小但特别提升效果的点。

第四个是接口文档的演示价值。答辩时直接打开Swagger或Knife4j，比你去点前端页面更能让老师信服。老师看到你有完整的接口测试能力，往往在这块的印象分会高一些，因为你展示的是工程化开发能力，而不仅仅是前端页面能点两下。

结尾的个人经验

聊了这么多，我把这套基于SpringBoot的美发商城系统的核心逻辑和部署流程都过了一遍。从我带项目的经验来看，如果一个同学能把这里面的业务模型、状态流转、折扣计算和并发预约逻辑跟面试官说清楚，这个项目的含金量完全不输一个大厂的CRUD项目。它表面上是一个商城，实际练到了不少接地气的业务抽象能力。

最后分享一个我做这套项目时觉得最值回票价的学习方式：不要把所有代码从头到尾读完，而是挑三个核心业务闭环读透，第一个是会员下单完整流程（从选服务到支付成功），第二个是预约时段冲突校验，第三个是优惠计算链路。这三块读透并能在不看代码的情况下自己讲出来、写出来，项目答辩基本就能很从容了。如果时间允许，还可以试着自己加一个小功能，比如“技师排行榜”或者“会员生日折扣”，改动不大，但能体现出你对这套系统的掌控力是真实的，而不是照着文档念的。这也是我把这套系统推荐给想做Java实战项目的人的原因，它足够好玩也足够有挑战，是那种能让你确实学到东西、而不会沦为机械跑通的项目。