Spring Boot+微信小程序：汉服妆造租赁预约系统实战-代码聚汇网

做这类“Spring Boot + 微信小程序”的项目，我前前后后带过不少学生，也自己动手搭过好几套。说实话，市面上的电商类小程序项目一抓一大把，但把“汉服妆造租赁”和“化妆预约”这两件事凑到一起的，确实不算多，而且这个选题放在西安这个城市背景下特别讨巧——文旅属性强、场景明确、业务链条比普通商品下单要复杂一截，拿来当毕设或者项目实战练手，能讲的东西很多。

这篇就把整个系统的设计思路、核心表结构、后端接口实现、小程序端联调，以及我实际运行中踩过的坑，一次说清楚。内容会尽量按“我拿到这个项目会怎么下手”的顺序来写，不管你是准备直接参考源码，还是打算自己复刻一套，都应该能从中找到能直接用的东西。

1. 项目整体思路与业务拆解

1.1 这个项目到底解决什么问题

西安的汉服体验有多火，稍微关注文旅的人都有感觉。大唐不夜城、城墙、芙蓉园，满大街都是穿汉服的小姐姐小哥哥。但线下门店的痛点也很明显：节假日排队、妆造师档期冲突、衣服尺码被反复试穿后弄脏弄乱、还衣服时间没人提醒。传统的电话预约和到店排队，效率太低，而且年轻游客更习惯“手机上看款式、定时间、下单、到店直接穿”。

所以这个系统的核心价值就三个字：约、租、妆。约是预约档期，租是汉服租赁，妆是妆造服务。它把线下门店的接待流程搬到了小程序上，用户先在线看款式、看妆造师、选时间段、下单支付，到店直接体验，结束之后还能评价。对店家来说，档期可管理、订单可追踪、收入可统计，比手工记本子靠谱得多。

1.2 从“租衣服”到“预约化妆”的业务链路

这个项目和普通电商最大的区别在于：普通电商卖的是实物商品，下单之后就进入物流流程；这里卖的是“服务 + 实物”的组合，而且服务有强烈的时间属性。

一条完整的业务链路是这样的：

用户打开小程序，看到首页的汉服列表和妆造方案列表。
点进详情页，查看汉服的尺码、风格、租赁价格，或者查看妆造师的档期。
选择租赁的开始时间和结束时间，或者选择妆造师上的某个可预约时段。
提交订单，填写联系电话、备注（比如身高体重、过敏史）。
在线支付定金或全款。
到店扫码或报手机号核销。
体验完成，归还汉服，释放档期。
用户对这次体验进行评价。

注意这里面有个关键点：租赁订单和化妆预约可以分开，也可以合并。我在设计时会把“汉服租赁”和“妆造预约”做成两个独立的订单类型，但共用一套用户体系和订单主表，这样扩展性最好。后面如果店家想加“跟拍服务”，只需要加一个服务类型字段，不用动表结构。

1.3 用户端和运营端的功能边界

很多同学拿到项目第一步就想写代码，这是不对的。先看清楚功能边界，后面写代码才能少返工。

用户端（微信小程序）：

微信授权登录，获取openid和用户信息
首页轮播图、汉服分类、推荐商品
汉服列表与详情（多图展示、价格、尺码、库存状态）
妆造师列表与详情（作品图、可约时段）
订单创建、支付（微信支付或模拟支付）、取消、评价
个人中心：我的订单、我的收藏、个人信息

运营端（管理后台）：

汉服管理：上下架、库存设置、图片上传、价格维护
妆造师管理：添加化妆师、设定工作时间段
订单管理：查看、核销、退款处理
分类管理、轮播图管理、评价管理

我见过不少同学一上来就写管理后台，结果前端小程序都还没跑通。实际上对于毕设或者项目展示来说，优先把小程序端和核心后端接口做好，后台可以用一个极简的Vue页面甚至Swagger界面演示就够了。这个项目的亮点应该放在“预约逻辑”和“小程序交互”上，而不是后台管理页面做了多少个。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 核心技术链路与环境选型

2.1 后端框架：为什么是Spring Boot

这个项目用Spring Boot几乎是顺理成章的选择。Spring Boot本身就是为了解决Spring配置繁琐的问题，内嵌Tomcat，启动就用一个main方法，配合Starter机制，加依赖就能用，特别适合做小程序这种前后端分离项目的后端接口层。

版本选择上，我强烈建议用 Spring Boot 2.7.x + JDK 8，别跟风上3.x。很多刚入门的同学一上来就装最新的JDK 17甚至21，结果发现Spring Boot 3.0以上版本要求JDK 17起步，很多老教程里的代码写法都变了，druid数据源、MyBatis-Plus的兼容性也可能出问题，网上搜到的解决方案大多还是针对2.x的，排查起来非常痛苦。热词里那个“springboot版本太高”的搜索量一直不小，说明很多人都在这里栽过跟头。项目能跑起来比什么都重要，版本选型保守一点不丢人。

2.2 持久层：MyBatis-Plus真香，但不是必须

持久层我推荐MyBatis-Plus。它的好处是单表CRUD几乎不用写SQL，有个BaseMapper就能搞定，内置了分页插件、条件构造器，能省掉大量重复的Mapper XML。在这个项目里，用户表、收藏表、评价表都是典型的单表操作，用MyBatis-Plus的LambdaQueryWrapper写查询条件非常舒服。

不过要注意一点：MyBatis-Plus只擅长单表，一旦涉及多表关联查询，比如订单表join商品表，它就显得比较笨拙。我的处理方式是多表查询时老老实实写XML里的自定义SQL，单表操作走MyBatis-Plus，两者结合，效率和可读性都能兼顾。

2.3 小程序端：原生还是uni-app

小程序端有两个选择：微信原生开发，或者uni-app跨端开发。

如果你只做微信小程序，我建议原生。原因很简单：原生开发的调试体验最好、文档最全、你搜到的问题答案大部分都是原生的写法。uni-app的优点是以后可以一套代码编译成App和H5，但多一层编译就意味着多一层问题，比如某些微信API在uni-app里要先封装，出了问题还不好定位。

热词里有一个“h5 能调用微信小程序当前经纬度不”，这其实是很多人对跨端能力边界不清晰造成的困惑。如果纯H5想在微信里拿定位，走的是公众号网页授权的链路，跟小程序定位完全是两套东西，千万别混。这个项目如果要做“附近门店”功能，直接用小程序原生的wx.getLocation就行，简单直接。

2.4 数据库和中间件

数据库用MySQL 5.7或8.0都行，8.0对JSON类型支持更好，但如果你是新手，装5.7反而少很多麻烦（时区、驱动、字符集问题都更少）。我自己的习惯是8.0 + mysql-connector-java 8.0.x，只要在连接串里带上serverTimezone=Asia/Shanghai，基本没坑。

Redis在毕设场景下不是必须的。我知道很多同学想在项目里加Redis证明自己会缓存，但说实话，像这种体量的系统，数据库查询本来就很快，加了Redis反而要多写一堆序列化和缓存更新逻辑。如果非要加，我建议只用在“微信登录token”和“首页轮播图缓存”这两个场景，这两个是收益最高的。项目文档里可以提“设计了Redis缓存方案”，代码里做不做就看答辩需求了。

微信支付同理。个人开发者和很多学生的资质根本申请不下来微信支付，所以项目里通常会做成“模拟支付”：点击支付按钮后，弹窗确认，直接调用一个后端接口把订单状态改成已支付。这一点很现实，不要硬着头皮去接真实支付，演示效果是一样的，还能避免一堆证书和回调的麻烦事。

3. 数据库设计与核心表结构

3.1 一张图看明白核心表关系

我最怕看到学生一上来就设计二十多张表，然后大部分都是空的。这个项目核心表就6张：

user：用户表
hanfu：汉服商品表
makeup_artist：妆造师表
appointment_order：预约订单表（核心中的核心）
evaluation：评价表
favorite：收藏表

再加上一些辅助表：banner轮播图、category分类、appointment_time_slot时间槽，总共9张左右，完全够用，逻辑也清楚。

3.2 核心表结构详解

用户表

sql复制CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `openid` varchar(64) NOT NULL COMMENT '微信openid',
  `nickname` varchar(64) DEFAULT NULL COMMENT '昵称',
  `avatar_url` varchar(512) DEFAULT NULL COMMENT '头像',
  `phone` varchar(20) DEFAULT NULL COMMENT '手机号',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_openid` (`openid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意几个细节：openid一定要加唯一索引，这是用户身份的唯一凭证；手机号不在登录的时候强制填，而是在下单的时候让用户填，这样用户体验更顺滑；create_time不用在代码里set，让数据库默认值去处理。

汉服表

sql复制CREATE TABLE `hanfu` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID',
  `name` varchar(128) NOT NULL,
  `description` text COMMENT '描述',
  `cover_image` varchar(512) DEFAULT NULL COMMENT '封面图',
  `images` varchar(2000) DEFAULT NULL COMMENT '多图，逗号分隔',
  `price_per_day` decimal(10,2) NOT NULL COMMENT '日租价格',
  `deposit` decimal(10,2) DEFAULT NULL COMMENT '押金',
  `stock` int(11) NOT NULL DEFAULT '1' COMMENT '库存',
  `rent_count` int(11) DEFAULT '0' COMMENT '累计租赁次数',
  `status` tinyint(4) DEFAULT '1' COMMENT '1上架 0下架',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里images字段存逗号分隔的多图路径，是很多视频教程里的做法，简单但不优雅。如果你想让项目看起来更专业，可以拆一张hanfu_image子表，但说实话，对于这个体量的系统，逗号分隔完全够用，写代码还更省事。追求毕业设计分数可以提“后续可优化为子表存储”，然后就够了。

预约订单表（核心）

sql复制CREATE TABLE `appointment_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单号',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `order_type` tinyint(4) NOT NULL COMMENT '1租赁 2妆造 3租赁+妆造',
  `hanfu_id` bigint(20) DEFAULT NULL COMMENT '汉服ID',
  `artist_id` bigint(20) DEFAULT NULL COMMENT '妆造师ID',
  `appointment_date` date DEFAULT NULL COMMENT '预约日期',
  `start_time` varchar(16) DEFAULT NULL COMMENT '开始时间段',
  `end_time` varchar(16) DEFAULT NULL COMMENT '结束时间段',
  `total_amount` decimal(10,2) NOT NULL COMMENT '总金额',
  `deposit` decimal(10,2) DEFAULT '0.00' COMMENT '押金',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待支付 1已支付 2已核销 3已取消 4已评价',
  `customer_phone` varchar(20) DEFAULT NULL COMMENT '联系电话',
  `remark` varchar(255) DEFAULT NULL COMMENT '备注',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_hanfu_id` (`hanfu_id`),
  KEY `idx_artist_id` (`artist_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表是整个系统的心脏。我的建议是把租赁和妆造合并成一张表，靠order_type字段区分，而不是拆成两张表。原因是：用户在提交一个“下午3点，租汉服 + 做妆造”的订单时，这是一个完整的事务操作，拆成两张表会出现中间状态不一致的风险，合并成一张表反而简单，查询“我的订单”列表也只需查一张表，不用做union。

3.3 时间冲突检测的SQL写法

预约系统最核心的算法就是判断某个时间段是否已被占用。

比如用户想租某件汉服，预约时间是2025-06-01的10:00-18:00，我们需要查这个时间段内有没有已经占用的订单：

sql复制SELECT COUNT(*) FROM appointment_order
WHERE hanfu_id = #{hanfuId}
  AND appointment_date = #{date}
  AND status IN (1, 2)
  AND start_time < #{endTime}
  AND end_time > #{startTime}

这段SQL的逻辑是：只要现有订单的开始时间早于用户期望的结束时间，且现有订单的结束时间晚于用户期望的开始时间，就说明存在重叠。这是一个很经典的重叠区间判断方式，建议直接背下来，很多预约类项目都能用。

妆造师的时间冲突判断同理，只是把hanfu_id换成artist_id。我一开始写这个查询的时候也想过要不要加一个专门的时间槽表，后来发现完全没必要，订单表本身就是最权威的排期表，直接查订单就行。

4. 后端核心接口设计与实现

4.1 微信登录：从code到session

小程序端点击登录按钮后，wx.login()会拿到一个临时code，这个code需要传给后端，由后端调用微信的接口换取openid。完整流程是：

小程序端wx.login()获取code
小程序把code、昵称、头像等信息通过wx.request传给后端
后端调用https://api.weixin.qq.com/sns/jscode2session，用appid + secret + code换openid和session_key
后端拿openid查数据库，没有就注册新用户
生成一个token返回给前端

后端Controller的核心代码：

java复制@RestController
@RequestMapping("/api/auth")
public class AuthController {

    @Autowired
    private UserService userService;

    @PostMapping("/login")
    public Result login(@RequestBody LoginRequest request) {
        // 1. 调用微信接口换openid
        String url = "https://api.weixin.qq.com/sns/jscode2session?appid="
                + appid + "&secret=" + secret + "&js_code=" + request.getCode()
                + "&grant_type=authorization_code";
        // 这里建议用RestTemplate或Hutool的HttpUtil发起GET请求
        JSONObject sessionInfo = HttpUtil.get(url);
        String openid = sessionInfo.getStr("openid");
        if (StrUtil.isBlank(openid)) {
            return Result.error("登录失败，code已失效");
        }
        
        // 2. 查用户是否存在
        User user = userService.getOne(
            new LambdaQueryWrapper<User>().eq(User::getOpenid, openid));
        if (user == null) {
            user = new User();
            user.setOpenid(openid);
            user.setNickname(request.getNickname());
            user.setAvatarUrl(request.getAvatarUrl());
            userService.save(user);
        }
        
        // 3. 生成token
        String token = UUID.randomUUID().toString().replace("-", "");
        // 维护一个token到user的映射，可以用Redis，也可以用内存Map
        
        return Result.success(token);
    }
}

热词里“小程序获取登录后的微信用户失败”是个高频问题。造成这个问题的原因不少，最常见的是：在模拟器里调试时，wx.getUserProfile弹窗授权被用户拒绝过，导致拿不到用户信息。这个问题的排查思路很简单：先在onLoad里确认wx.login的code拿到了没有，再确认后端用code请求微信接口有没有报错（通常是invalid code、appid和secret不匹配），最后确认自己的appid是不是测试号。很多同学把appid填成了小程序的AppID，但secret填的是开放平台的，这俩对不上，一定会失败。

4.2 拦截器：JWT还是简单Token

现在很多教程爱用JWT，把用户ID加密在token里，后端解析token就能拿到用户身份。

实际做毕设项目，JWT其实有点过度设计。JWT的核心理由是“无状态”，适合分布式场景，但如果你只部署一台服务器，直接在Redis里存一个token -> userId的映射，效果一样，而且想踢人下线、想清理过期token都非常方便。

我的建议是：用一个简单的拦截器，拦截/api/user/**、/api/order/**这些需要登录的路径，从Header里取token，再查一下Redis或者内存Map里有没有对应的userId，有就放行，没有就返回401。

java复制public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (token == null || token.isEmpty()) {
            response.setStatus(401);
            response.getWriter().write("未登录");
            return false;
        }
        Long userId = TokenStore.getUserId(token);
        if (userId == null) {
            response.setStatus(401);
            response.getWriter().write("token已过期");
            return false;
        }
        request.setAttribute("userId", userId);
        return true;
    }
}

这里可以先不引入Spring Security，那玩意配置起来太重了，而且学起来很费劲，毕设项目完全用不到那么重的安全框架。

4.3 下单接口的实现细节

订单接口是核心的POST接口，前端会传一个JSON，大概长这样：

json复制{
  "orderType": 3,
  "hanfuId": 1,
  "artistId": 2,
  "appointmentDate": "2025-06-01",
  "startTime": "10:00",
  "endTime": "18:00",
  "customerPhone": "138xxxx1234",
  "remark": "身高160，体重90斤"
}

后端要做的事按顺序来：

校验用户是否已登录（从token里取userId）
根据orderType校验业务参数，比如选了租赁必须传hanfuId，选了妆造必须传artistId
查库存：汉服是否在架、库存是否大于0、妆造师是否存在
时间冲突校验：执行3.3里的SQL，有冲突就返回“该时间段已被预约”
计算金额：汉服租赁价格 + 妆造价格，加上押金
生成订单号，格式建议：日期 + 随机数，比如20250601103012456
插入订单表，初始状态为待支付

这里重点说一下金额计算。汉服租赁按天计费还是按小时计费，价格模型完全不一样。我的建议是：按小时计费更灵活，默认4小时起租，超过4小时按每小时加收费用。这个逻辑写在Service层：

java复制public BigDecimal calcRentAmount(Hanfu hanfu, String startTime, String endTime) {
    // 计算小时差
    LocalTime start = LocalTime.parse(startTime);
    LocalTime end = LocalTime.parse(endTime);
    long hours = Duration.between(start, end).toHours();
    if (hours <= 4) {
        return hanfu.getPricePerDay();
    }
    BigDecimal extraHours = BigDecimal.valueOf(hours - 4);
    BigDecimal extraPrice = hanfu.getPricePerDay()
        .multiply(BigDecimal.valueOf(0.15));
    return hanfu.getPricePerDay().add(extraPrice.multiply(extraHours));
}

这套逻辑写下来，答辩的时候问“这个价格是怎么算的”，你至少能讲三分钟，比“就是商品价格存数据库里”有说服力得多。

4.4 订单状态机：别再写了十几个if

订单状态流转是这类系统的重点和难点。最原始的做法是在每个接口里各种if判断：能不能取消？能不能评价？能不能退款？每个地方都写一遍判断逻辑，代码到处都是，而且特别容易漏。

推荐用一个最简状态机来管理：

状态定义：

0 待支付
1 已支付（待体验）
2 已核销（体验中）
3 已取消
4 已评价（已完成）

合法的状态流转：

0 -> 1 支付
0 -> 3 取消
1 -> 2 商家核销
1 -> 3 退单（超时或用户申请）
2 -> 4 评价完成

把这个流转规则集中放在一个类里管理，每次修改状态都调用一个方法：

java复制public class OrderStatusMachine {

    private static final Set<String> TRANSITIONS = new HashSet<>(Arrays.asList(
        "0->1", "0->3", "1->2", "1->3", "2->4"
    ));

    public static boolean canChange(int from, int to) {
        return TRANSITIONS.contains(from + "->" + to);
    }
}

这样不管你在哪个接口里改订单状态，只要先调用canChange校验一下，就不会出现“从已取消变成已完成”这种bug。代码量少了，思路也清晰，答辩老师看到状态机这个词，通常都会觉得你考虑得比较周到。

5. 小程序端核心页面与交互

5.1 登录按钮背后的完整流程

小程序端的登录不能像网页那样写个redirect。微信给的官方建议是：每个页面都可能需要用户身份，所以登录按钮一般放在“我的”页面上，用户进入个人中心或者下单时，再触发登录。

核心代码如下：

javascript复制// 页面里点击登录按钮
handleLogin() {
  wx.login({
    success: async (res) => {
      const code = res.code
      const userProfile = await this.getUserProfile()
      // 把code和用户信息一起发给后端
      wx.request({
        url: 'https://yourdomain.com/api/auth/login',
        method: 'POST',
        data: {
          code: code,
          nickname: userProfile.nickName,
          avatarUrl: userProfile.avatarUrl
        },
        success: (resp) => {
          const { token } = resp.data.data
          wx.setStorageSync('token', token)
          wx.setStorageSync('userInfo', userProfile)
          // 刷新页面
        }
      })
    }
  })
}

一个很常见的坑：wx.getUserProfile只能在用户点击事件里调用，不能在onLoad或者wx.login回调里直接调用，否则会直接进fail回调。另外，2022年之后微信调整过这个接口的返回规则，用户在拒绝一次之后，再次点击需要重新触发，而且头像昵称会返回默认的灰色头像。这个只能通过引导用户重新授权来解决，没有别的办法。

5.2 首页和列表页的数据加载

首页一般包括轮播图、分类导航、热门汉服推荐这几个模块。这里有一个经验：不要在一个onLoad里同时发好几个请求，3个接口并发请求，总会有一个先返回一个后返回，加载的顺序不好控制。我的习惯是做一个统一的页面数据加载器：

javascript复制onLoad() {
  this.loadBanners()
  this.loadCategories()
  this.loadHotHanfu()
}

三个方法分别请求三个接口，每个方法内部处理自己的loading状态。这样任何单个接口挂了，页面也不会白屏，用户能看到的错误信息也更明确。这里涉及和图片相关的服务器配置，后面会专门说。

列表页最需要注意的就是分页。不要一次性把所有汉服列表全部拉到前端，数据量小的时候看着没事，一旦商品涨到几百条，小程序渲染会非常卡。正确做法是后端用MyBatis-Plus分页插件，前端用onReachBottom触底加载下一页：

javascript复制onReachBottom() {
  if (this.data.hasMore) {
    this.setData({
      page: this.data.page + 1
    })
    this.loadHanfuList()
  }
}

5.3 最容易被忽略的图片存储问题

小程序里展示的图片，需要用网络URL，不是本地文件路径。学生在做完这个项目后，经常遇到一种情况：在小程序开发者工具里上传一张本地的图片，发现真机预览的时候图片加载不出来。

原因很简单：开发工具能访问本地图片，但真机上的小程序是运行在微信客户端里的，它无法访问你电脑上的本地文件。解决这个问题有两个方案：

方案一：使用自建服务器存储图片，配置Spring Boot的静态资源映射：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/images/**")
                .addResourceHandler("file:" + uploadPath);
    }
}

图片上传到服务器的/data/upload/目录，访问路径就是http://服务器IP:8080/images/xxx.jpg。小程序端图片URL直接拼这个地址，前提是手机和服务器在同一网络，或者服务器部署在云上。

方案二：使用云存储。比如阿里云OSS，七牛云对象存储，把图片传到OSS，返回一个公网URL。这个方案更接近生产环境，但是要花几块钱实名认证和开通服务。对毕设来说，方案一足够用，在答辩时还可以说“图片存储已设计可切换为OSS存储方案”。

5.4 订阅消息是另一个深坑

热词里有“微信小程序推送消息方案”，这确实是很多人做完项目后想加的一个功能：用户预约成功之后，给用户推一条“您的预约已确认”的模板消息。

但目前微信的模板消息早就下线了，现在只有订阅消息。而且订阅消息的规则很严格：用户点击一次按钮授权，小程序才能给用户推送一条订阅消息。也就是说，用户不主动点击授权，后端无法给用户推送消息。这意味着想做到“用户下单后自动推送”，从机制上就行不通。

可用的替代方案：

用户在确认订单页加一个“允许预约结果通知”的订阅按钮，拿到用户的一次性授权。
预约状态变更时，后端调用订阅消息接口推送给用户。

这个流程能在演示时说清楚机制，就已经比大多数毕设项目高一个档次了。

6. 项目启动、部署与常见问题排查

6.1 本地运行全流程记录

我按照最常见的运行方式，把整个流程捋了一遍，照着做基本一步到位：

导入源码：用IDEA打开后端代码，等待Maven下载依赖。这一步经常会卡很久，建议换阿里云镜像，不然下载Spring Boot依赖要等半天。
建库：在MySQL创建数据库hanfu_db，导入项目里提供的hanfu_db.sql文件。
改配置：打开application.yml，把数据库用户名密码改成自己的，Redis如果有配也要改成自己的地址。大概率还要改一下端口，别跟本机其他服务冲突。
启动后端：直接运行Application类，看到Tomcat started表示启动成功，可以先用浏览器访问http://localhost:8080/api/hanfu/list测试一下。
打开小程序：用微信开发者工具导入小程序前端目录，在app.js或config.js里把baseUrl改成http://localhost:8080。
关闭域名校验：开发状态下，在微信开发者工具右上角“详情 -> 本地设置”勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。
编译运行小程序：在开发者工具里就可以看到首页数据正常加载了。

这里面最容易出错的就是第6步，很多同学辛辛苦苦把后端跑起来，小程序一请求报url not in domain list，然后就蒙了。实际上开发阶段不需要配置合法域名，直接关掉校验就行。但要注意：这个设置只在开发者工具里有效，真机预览的时候，如果不配置request合法域名，请求会失败。真机预览调试时可以在“小程序后台 -> 开发管理 -> 开发设置 -> 服务器域名”里配置，先把IP地址或域名加到request合法域名列表。

6.2 高频异常与排查速查表

我把这个项目里学生遇到最多的问题整理成一个速查表，建议收藏：

现象	大概率原因	解决方案
启动报`Access denied for user 'root'@'localhost'`	数据库密码配置错误	检查application.yml里的username和password
启动报`Unknown database 'hanfu_db'`	数据库没创建	先执行`CREATE DATABASE hanfu_db`再导SQL
小程序请求报`url not in domain list`	开发者工具没关域名校验	详情 -> 本地设置 -> 勾选不校验合法域名
小程序请求报`Network Error`	地址填错或后端没启动	用浏览器访问一下接口地址，确认可访问
登录报`invalid code`	code只能使用一次	检查登录逻辑，确认没有重复发送同一个code
查询数据中文乱码	数据库字符集不是utf8mb4	连接串加`characterEncoding=utf8mb4`，表字段也检查一遍
图片访问404	静态资源配置错误	检查`addResourceHandlers`里的物理路径是否存在
订单支付后状态没变	模拟支付接口没调用	前端确认支付按钮正确调用后端`/api/order/pay`接口
分页数据重复或缺失	page参数从0开始还是从1开始	统一page从1开始，后端PageHelper处理时注意计算

6.3 “Spring Boot版本高”的一类坑，一次性说清楚

前面说了推荐用2.7.x。但如果你已经用了Spring Boot 3.x，这里有三个你几乎一定会遇到的差异点：

javax包名全部改成jakarta，比如javax.servlet变jakarta.servlet。
MyBatis-Plus要引入适配3.x的starter，老版的mybatis-plus-boot-starter可能起不来。
Spring Security 6的配置方式跟5完全不同，Lambda写法大改。

所以，我的建议始终是：如果你是拿这个项目练手或者做毕设，直接用JDK 8 + Spring Boot 2.7.x的经典组合，网上能找到的教程最多、遇到问题最不容易卡住。等到把项目做熟练了，再自己尝试升级到3.x，那个时候你已经有能力解决升级带来的各种问题了。

7. 项目文档、答辩演示与二次扩展经验

7.1 文档和运行视频你该怎么用

我注意到这个项目的交付物里包含源码、文档、运行视频、讲解视频。很多学生拿到手就开始跑代码，这是不科学的。

我建议的使用顺序是：

先看讲解视频，搞清楚项目功能模块和业务逻辑。
再看运行视频，确认整个跑起来的流程。
然后打开文档，重点看“需求分析”和“数据库设计”两章，这会让你对系统的理解上一个台阶。
最后再打开源码，对照文档看代码，这样不用把全部代码都看一遍才能在答辩里讲清楚。
改代码之前，先备份一份。这句话我说了很多遍，但就是有人不听，直到把数据库配置改坏才发现救不回来。

拿到源码之后，一定要自己把项目启动起来、操作一遍、再动手改一两处小功能（比如把首页轮播图改成动态加载，加个搜索框）。这样做一方面避免答辩时被问到细节答不上来，另一方面也可以在这个过程中发现一些问题，提前解决。

7.2 答辩和面试时最容易被问到的三个问题

这类项目的答辩或者面试，评委大概率会问这三个问题。提前准备好，就不会慌。

问题一：这个项目你主要负责什么？

说清楚你负责了从需求分析、数据库设计到后端接口开发、小程序前端联调的完整过程。如果是在团队里做，也要说清楚你负责的具体模块，以及你和别人怎么对接（比如你定义接口数据结构）。

问题二：为什么用Spring Boot + 微信小程序这个组合？

这题的思路要从“场景匹配”来答：微信小程序不用安装、扫码即用，适合西安旅游这种低频、即时的消费场景；Spring Boot开发效率高、生态成熟，能快速提供稳定的后端接口；MySQL负责结构化数据存储，整个技术栈满足项目规模，成本低、部署简单。

问题三：系统最大的难点是什么？

标准回答：预约业务的时间冲突处理。这个问题的完整思路是：首先分析业务需求（同一件汉服、同一个妆造师同一时间段不能重复预约），然后设计查询（重叠区间判断SQL），最后答出边界情况（比如用户取消后释放档期、管理员手工调整档期）。能把这个讲明白，这个问题就过关了。

7.3 这个项目还能往哪些方向扩展

这个系统的底子打好之后，扩展方向其实很丰富，我说几个实际操作中比较有价值的方向：

加一个商家端小程序：用户端是小程序，商家端也用小程序，共用同一个后端。商家端做核销、上下架、查看营收统计。
做智能推荐：根据用户的历史浏览和租赁记录，推荐风格相似的汉服。这个功能用简单的标签匹配就能实现，不一定要上机器学习。
加一个基于时间轴的管理日历：后台用一个日历视图展示每天每个妆造师的预约情况，这对门店运营来说非常实用。
对接真实微信支付：等资质和条件具备后，把模拟支付替换为真实的微信支付，代码层面只需要改支付接口那一块。

我还见过有学生把预约档期做成可配置化的，比如节假日每天多开放两个时段、妆造师临时请假可以批量关闭某几天的时段。这些都是和“运营效率”有关的小功能，但加上之后，整个项目的商业逻辑就更加完整了。

最后再分享一个小经验。这个项目我前后跑过好几轮，每一步都踩过坑，也看着很多学生从“第一次启动项目报错500”到“能自己加一个功能页面”，成长路径是非常清晰的。如果你也是刚开始接触这类全栈项目，我的建议是不要贪多，先把预约这条主链路吃透，把时间冲突算法理解透，再考虑加花活。技术上并没有太多高深的东西，更多是细心与耐心，一步步把链路跑通、把逻辑理顺。这个系统做到最后，你会发现收获最大的并不是那几行代码，而是“如何把一个真实场景抽象成数据结构和接口”这种思维习惯，这个习惯在后面的学习和工作中，都会一直受用。

Spring Boot+微信小程序：汉服妆造租赁预约系统实战