SSM+微信小程序：美容院预约系统的时间片与并发实战-AI智能范式网

SSM+微信小程序：美容院预约系统的时间片与并发实战

魏文华·2026-10-05·阅读 22 GEO检测（免费）

SSM框架微信小程序预约系统

|难度：普通|阅读约 45 分钟

我整理源码交付文档时又翻出了这套基于SSM框架的美容院预约系统微信小程序工程，编号71851。当时给一位开美容工作室的朋友做这个小程序，起因特别简单：店铺的预约还是靠微信聊天和手写本子，顾客和美容师经常撞时间，忙起来连谁几点到店都说不清。后来我用Spring + SpringMVC + MyBatis搭后端，原生微信小程序做客户端，把项目浏览、美容师选择、时间预约、后台确认这条完整链路都跑通了。这套系统最适合两类人看：一类是学完Java Web想找个完整前后端项目练手的同学，SSM虽然看起来比Spring Boot“老”，但分层结构反而更适合理解业务系统的骨架；另一类是美容、美发、健身这类服务型门店想做线上预约，又不想被市面SaaS平台年费绑死的经营者。它不是什么高深技术，但胜在完整、能跑、能改，拿到源码后可以顺着自己的需求去调整。

1. 美容院预约的业务真相：先拆清楚场景，再谈技术

1.1 传统手工预约模式为什么一定要换掉

做这个系统之前，我在朋友店里蹲了半天，发现手工预约的痛点比想象中严重得多。最典型的就是“撞单”：顾客A打电话约了周六下午3点，美容师顺手在本子上记一笔，结果顾客B在微信上又问同一时段，接待员翻了半天本子没看清，又把3点放出去了。等到店之后，两个顾客大眼瞪小眼，场面非常尴尬。除了冲突，还有电话占线、记录潦草、改期靠口头，以及最头疼的“爽约率”——顾客临时不来，美容师的时间就空在那里，门店当天的营收直接受影响。

预约系统的本质，就是把“具体哪个美容师、在什么日期、哪个时间段、做哪个项目”这一组信息，变成一个不允许歧义的、可被计算机校验的约束。这套系统并不需要多炫酷的人工智能推荐，核心就是把预约资源看成商品，把时间看成库存，谁先把某个时间片的占用记录写进数据库，谁就获得服务资格。

1.2 三类角色与核心业务用例

业务模型我一开始就定成三角结构：顾客、美容师、管理员。

顾客在小程序端完成的操作最重：注册登录、浏览美容项目列表、查看美容师介绍与空闲时间、创建预约、取消预约、查看历史订单。美容师虽然有专属角色，但我没有单独做一套App，而是在小程序里增加“美容师视角”的页签，或者让管理员在后台代查代确认——小团队门店更容易接受后者。管理员负责后端页面：维护美容项目上下架、维护美容师档案、确认预约、查看当日排班、统计某个项目近期的预约量。

表面上业务用例不多，但“创建预约”这一个用例内部就包含多条规则：项目时长决定占用时间片的数量；美容师当天是否有排班；预约时间是否处于营业时间范围内；同一位美容师在同一时间片不能被重复预约。这些规则后面全部落到数据库和事务代码里，所以需求阶段一定不能省。

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

2. SSM + 小程序这套组合，到底图它什么

2.1 很多人说SSM过时了，我却觉得它适合跑通业务

这几年Spring Boot几乎成了Java后端默认选择，SSM确实显得“传统”。但做这个项目我反而觉得SSM有不可替代的学习价值：Spring管对象、SpringMVC管请求分发、MyBatis管数据库访问，每一层的边界非常清楚。你写一个Controller，会天然地思考它属于表现层；写一个Service，会明白事务应该放在这里；写一个Mapper接口和XML文件，会理解SQL为什么要和Java代码分离。换到Spring Boot里，很多配置被自动装配掩盖了，新手往往只会在一个类里写一堆注解，反而不理解请求到底是怎么进来、事务到底是怎么生效的。

另外，现实环境里还有大量已经上线的Java项目是SSM架构，学会读懂这类老项目，对找工作或接手维护项目都是实打实的能力。所以我从来不觉得SSM“没用”，它只是从一个时代的主流变成了特定场景下的合理选择。

2.2 为什么客户端选微信小程序而不是H5或App

美容院预约的核心流量完全来自微信生态。顾客在微信里打开一个小程序，不需要下载App、不需要记住网址、用完即走，对门店来说获客成本最低。小程序还自带wx.login能力，可以拿到微信用户的唯一标识openid，免去了短信验证码注册的繁琐流程——这对中老年顾客群体特别友好，很多顾客根本不想输手机号注册。

开发层面，原生小程序上手比想象中的慢不是技术难，而是组件和API比较琐碎。我当时为了赶交付，没有引入第三方UI库，全部用手写样式加flex布局，好处是产物干净、不依赖额外npm包，源码复制到另一个开发者工具里直接就能编译。“附源码”这件事的价值也在这里：你拿到的不只是一堆文件，而是一套已经被验证过能跑通的环境。

2.3 源码工程为什么值得作为起点

我见过太多同学下载了源码打不开、跑不起来、改不动。这个工程在交付时我特地加了一个README说明，从JDK版本、MySQL版本、Tomcat版本、开发者工具版本到导入步骤都列了一遍。这里也想强调一个观点：源码不是给你抄的，是给你拆的。你先把它完整跑起来，再去看它的请求链路，最后再动手改一个小功能（比如把预约时间片从30分钟改成15分钟），能把这个流程走通，比单纯读十遍Spring文档都管用。

3. 数据库建模：30分钟时间片是预约系统的地基

3.1 核心表结构与字段设计

预约系统的数据库设计直接决定后面业务逻辑怎么写。我把表拆成了用户表、美容师表、美容项目表、预约订单表四张核心表，再加一张可选的系统配置表。

用户表存openid作为和微信的唯一关联，昵称头像都是冗余字段，首次登录时从微信接口拉取后会更新。美容师表要存姓名、头像、头衔、简介、擅长项目ID列表，以及一个状态字段——美容师请假或离职时直接下架，不在小程序端展示。美容项目表最关键的是duration字段，因为后面所有时间片计算都依赖它。预约订单表则是整个系统的核心：

sql复制CREATE TABLE `appointment_order` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL,
  `user_id` int(11) DEFAULT NULL,
  `beautician_id` int(11) DEFAULT NULL,
  `item_id` int(11) DEFAULT NULL,
  `appoint_date` date DEFAULT NULL,
  `time_slot` varchar(16) DEFAULT NULL,
  `status` tinyint(4) DEFAULT 0 COMMENT '0待确认 1已确认 2已完成 3已取消 4已爽约',
  `remark` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_ba_time` (`beautician_id`, `appoint_date`, `time_slot`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

order_no生成规则我直接用日期加随机数，比如20250315加四位随机数字，避免暴露订单量业务数据。status字段是一个小型状态机，后面单独展开讲。这个建表语句看起来简单，但那张唯一索引uk_ba_time是整个预约系统第一道防冲突屏障。

3.2 为什么使用“日期 + 时间片”而不是存一个datetime

一开始我也纠结过：直接存appoint_time一个datetime不就完了吗？但加上真实业务之后就发现行不通。美容院排班的最小单位是半小时，所有项目时长都是30分钟的整数倍，比如基础补水护理60分钟、全身SPA 90分钟、深层清洁45分钟（这里通常也会圆整到60分钟）。如果直接存datetime，那么“9:00到9:30”“9:30到10:00”这两段是不同记录，但它们在业务上的连续性必须靠程序计算。而存appoint_date加time_slot（比如用字符串"09:00"代表从09:00开始的半小时片），配合项目时长，才能准确判断一个项目占用了哪几个连续时间片。

3.3 唯一索引是防撞单的底线

在数据库层面加上uk_ba_time唯一索引，是防止并发撞单的最简单可靠手段。它的原理类似“悲观锁的数据库实现”：两个请求同时尝试往 (beautician_id=3, appoint_date='2025-04-12', time_slot='15:00') 插入数据，InnoDB引擎会保证只有一个请求能成功，另一个会抛DuplicateKeyException。

但这里有一个容易被忽略的细节：一个时长60分钟的项目要占用15:00和15:30两个时间片，如果只插入一条主记录，唯一索引只能锁住第一个时间片，15:30这段仍然可能被另一个请求插进去。解决思路有两种：要么在插入前先做一次“区间探查”，统计目标时间片范围内已存在的记录数；要么干脆把每个被占用时间片都拆成一条独立的占位记录，预约成功后一次性写入多行。考虑到这个项目的代码量，我最终采用的是“事务内先查询占用区间，再插入订单”的方式，同时用唯一索引兜底防并发，两种手段一起上才让人放心。

4. SSM后端分层与预约接口的完整实现链路

4.1 工程目录结构与三层职责

拿到源码后，我建议你先看目录结构，一眼就能分清SSM的三层：

text复制src/main/java
├── com.example.beauty
│   ├── controller        // 接收小程序请求，返回JSON
│   ├── service           // 业务逻辑，事务边界在这里
│   ├── dao               // MyBatis Mapper接口
│   ├── entity            // 对应数据库表
│   ├── dto               // 前端入参对象
│   ├── vo                // 返回前端的数据视图对象
│   └── common            // 统一响应体、异常处理、工具类
src/main/resources
├── mapper                // MyBatis XML文件
├── spring-mvc.xml
├── spring-mybatis.xml
└── jdbc.properties

Controller层做的是“翻译”工作：把HTTP参数包装成对象，调用Service，再把结果统一包成{ code: 0, msg: 'success', data: {} }这样的响应体。Service层是核心，所有事务和业务规则都在这里。DAO层只负责最简单的增删改查，复杂查询写到XML里用动态SQL拼条件。这样的分层带来的直接好处是：小程序端接口变化时，通常只改Controller；预约规则变化时，只改Service；SQL优化时，只改Mapper。

4.2 登录接口到底做了什么

小程序端的登录流程很多人第一次接触会被绕晕。微信小程序调用wx.login()拿到的code，本质是一次性凭证，有效期很短。后端拿这个code去微信接口换取openid和session_key，其中openid才是用户的唯一身份标识。我的实现是这样写的：

java复制@PostMapping("/api/user/login")
public Result login(@RequestBody LoginDTO dto) {
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appId
            + "&secret=" + appSecret + "&js_code=" + dto.getCode()
            + "&grant_type=authorization_code";
    String resp = restTemplate.getForObject(url, String.class);
    JSONObject json = JSON.parseObject(resp);
    String openid = json.getString("openid");

    UserInfo user = userMapper.selectByOpenid(openid);
    if (user == null) {
        user = new UserInfo();
        user.setOpenid(openid);
        user.setNickname("微信用户");
        userMapper.insert(user);
    }
    String token = UUID.randomUUID().toString().replace("-", "");
    // token存入Redis或内存Map，后续请求通过header携带
    tokenStore.put(token, user.getId());
    return Result.success(token);
}

注意这里面有一个安全细节：session_key千万不要返回给小程序端，因为它能解密用户的手机号等敏感信息，业务系统只需要openid就够了。而且code只能用一次，后端换过之后再用会报错，所以小程序端每次登录都要重新调用wx.login()。

4.3 预约下单接口：事务、区间探查、订单落库

预约接口是我整个Service里最核心的方法，代码量不大，但每一行都有实操考量：

java复制@Transactional(rollbackFor = Exception.class)
public AppointmentResult createAppointment(Long userId, Long beauticianId, Long itemId,
                                           LocalDate appointDate, String startSlot) {
    ServiceItem item = itemMapper.selectById(itemId);
    Beautician beautician = beauticianMapper.selectById(beauticianId);
    // 1. 校验基础信息
    if (item == null || beautician == null || beautician.getStatus() != 1) {
        throw new BizException("项目或美容师不可预约");
    }
    // 2. 计算项目需要占用的时间片序列
    int needSlots = item.getDuration() / SLOT_MINUTES;
    List<String> slotList = buildSlotList(startSlot, needSlots);
    // 3. 区间探查，防止连续时间片被部分占用
    int occupied = appointmentMapper.countOccupied(beauticianId, appointDate, slotList);
    if (occupied > 0) {
        throw new BizException("该时间区间已被预约，请选择其他时间");
    }
    // 4. 生成订单并落库
    AppointmentOrder order = buildOrder(userId, beauticianId, itemId, appointDate, startSlot);
    appointmentMapper.insert(order);
    return new AppointmentResult(order.getId(), order.getOrderNo());
}

这段代码有几个关键点。第一，@Transactional必须加在Service方法上，这样区间探查和插入订单在同一个数据库事务里，不会出现“查的时候没占用、插的时候被抢”的中间状态。第二，buildSlotList根据项目时长把起点时间片扩展成多个连续时间片，比如"15:00"加60分钟时长得到["15:00", "15:30"]。第三，countOccupied对应的SQL用IN查询：

mysql复制SELECT COUNT(*) FROM appointment_order
WHERE beautician_id = #{beauticianId}
  AND appoint_date = #{appointDate}
  AND time_slot IN
  <foreach collection="slotList" item="slot" open="(" separator="," close=")">
    #{slot}
  </foreach>
  AND status IN (0, 1)

把已取消的订单排除在外很重要，否则用户取消后又想约同一个时段，会被自己之前的取消记录挡住。

4.4 MyBatis动态SQL处理项目列表查询

项目列表在前端有两个入口：首页默认展示全部美容项目，分类tab点击后按分类过滤。如果为每种场景各写一个Mapper方法就浪费了，MyBatis的<where>加<if>组合刚好解决：

xml复制<select id="selectItemByPage" resultType="com.example.beauty.vo.ItemVO">
    SELECT id, name, cover, duration, price, monthly_sales
    FROM service_item
    <where>
        <if test="categoryId != null">
            AND category_id = #{categoryId}
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
        <if test="keyword != null and keyword != ''">
            AND name LIKE CONCAT('%', #{keyword}, '%')
        </if>
    </where>
    ORDER BY sort_order ASC
    LIMIT #{offset}, #{pageSize}
</select>

我额外加了一个monthly_sales字段，初期数据是从历史预约单里汇总出来的。它是用一条UPDATE模拟的，开发阶段没必要接复杂的聚合统计服务，但前端展示“本月已预约xx单”的效果就得靠它。真要做实时统计，再写一个定时任务按天跑汇总即可。

5. 小程序端：从页面结构到预约交互的真实细节

5.1 页面清单与导航结构

小程序的页面我按用户核心操作路径拆成了五个tab和三个二级页面。tab分别是首页、项目分类、预约、订单、我的。二级页面有项目详情、美容师详情、预约填写页。整体目录长这样：

text复制pages/
├── index/index          // 首页：轮播图、热门项目、美容师推荐
├── category/category    // 分类页：按项目类目展示
├── booking/booking      // 预约页：核心交互页面
├── order/order          // 订单列表：区分状态tab
├── mine/mine            // 我的：头像昵称、历史预约、取消预约入口

和市面上大多数小程序一样，tab栏用的是微信原生的tabBar配置，图标是切好的81px小图标。很多新手会觉得tabBar限制页面结构，但美容院场景用户路径极其清晰，五个tab足够覆盖所有需求了，没必要为了“酷炫”强行自定义导航栏。

5.2 首页项目列表的动态渲染

项目的下拉刷新我直接用了enablePullDownRefresh配置，没有自己写触底函数。列表数据从后端分页接口拉取，用onReachBottom监听触底加载下一页。这里有个小程序开发常见的坑：onReachBottom只有在页面滚动到底部时才触发，如果你把列表放在一个固定高度的scroll-view里，这个事件就不灵了，必须改用scroll-view自带的bindscrolltolower。我在源码里给项目列表用了原生页面滚动，所以直接监听onReachBottom就行，注释里写了这个区别，免得后面改代码的人踩坑。

项目列表每一项的渲染是一个典型的wxml模板：

html复制<view class="item-card" wx:for="{{itemList}}" wx:key="id" bindtap="goDetail" data-id="{{item.id}}">
  <image src="{{item.cover}}" mode="aspectFill" class="item-cover"></image>
  <view class="item-info">
    <text class="item-name">{{item.name}}</text>
    <text class="item-duration">{{item.duration}}分钟</text>
    <view class="price-row">
      <text class="price">¥{{item.price}}</text>
      <text class="sales">已约{{item.monthlySales}}次</text>
    </view>
  </view>
</view>

mode="aspectFill"很关键，不做这个处理，网络图片比例不一致时列表会变得歪歪扭扭。网络图片的域名问题后面章节再展开，本地开发者工具里那种“图片全裂”的现象，基本都是域名没配白名单导致的。

5.3 预约三步曲：选项目、选美容师、选时间片

预约填写页是整个交互最复杂的地方。我先做了一个“从上一步带参数”的设计：用户从首页或分类页点“立即预约”时，url里带上itemId；如果是从美容师详情页进入，则带beauticianId。页面onLoad根据参数决定初始选中项，没有参数时默认展示可预约项目列表让用户自己选。

时间选择部分是这个页面的重点。用户选择日期后，要向后端请求一次“该美容师当天可预约时间片”：

javascript复制wx.request({
  url: BASE_URL + '/appointment/slots',
  method: 'GET',
  data: {
    beauticianId: this.data.beauticianId,
    appointDate: this.data.date
  },
  header: { 'Authorization': getApp().globalData.token },
  success: (res) => {
    const slots = res.data.data;
    this.setData({ slotList: slots });
  }
})

后端接口返回的是一个字符串数组，比如['09:00', '09:30', '10:00', ...]，已经是过滤掉占用时间段后的结果。前端用一个scroll-view横向平铺这些时间片，用户点选后高亮。这里我没让前端算“哪些时间片连续可用”，而是把计算压力放到后端——前端只负责展示和提交，业务规则集中在后端才是对的架构。

提交预约时，我做了二次确认弹窗，把项目名、美容师名、日期、时间片、价格汇总展示一遍。这个小细节大大降低了误操作率，顾客能看到“你要约的是90分钟的全身SPA，时间段是15:00到16:30”，比直接提交要安心很多。

5.4 订单列表与取消预约的状态流转

订单列表按状态分tab展示：待确认、已确认、已完成、已取消。用户最关心的操作是“取消预约”，而取消按钮只出现在待确认和已确认状态的订单上。我前端是这样控制的：

javascript复制cancelAppointment(e) {
  const id = e.currentTarget.dataset.id;
  wx.showModal({
    title: '取消预约',
    content: '确定要取消这个预约吗？取消后该时间片会释放。',
    success: (res) => {
      if (res.confirm) {
        wx.request({
          url: BASE_URL + '/appointment/cancel',
          method: 'POST',
          data: { orderId: id },
          header: { 'Authorization': getApp().globalData.token },
          success: (resp) => {
            if (resp.data.code === 0) {
              wx.showToast({ title: '已取消', icon: 'success' });
              this.loadOrderList();
            }
          }
        });
      }
    }
  });
}

取消预约在后端要做两件事：把订单状态改成3，同时释放对应时间片。因为我的表结构里一条订单占用多个时间片是靠“起始时间片+时长”推导的，释放操作并不需要删记录，只要把状态改成已取消，countOccupied查询时把它排除掉即可。这套设计把数据一致性控制在一个状态字段上，比“取消订单还要物理删除占位记录”的方案简单得多。

6. 并发抢单、状态机与超时处理：预约系统最容易被问倒的部分

6.1 两个用户同时抢同一时间片会发生什么

这个是预约类系统绕不开的问题，也是答辩或面试时最常被追问的点。假设两个顾客同时提交预约，都选了美容师3号周六15:00，如果后端没有并发控制，两个请求同时读到“该时间片空闲”，然后同时插入订单，数据库里就会出现两条本该互相冲突的记录。我在第3章通过唯一索引解决了精确时间片的冲突，而更复杂的区间冲突则用事务内的countOccupied加DuplicatedKey异常兜底解决。

但如果你希望更严格地控制并发，还可以在查询空闲时间片之前使用悲观锁——把美容师记录锁住，让同一美容师的预约请求串行化：

sql复制SELECT * FROM beautician WHERE id = #{beauticianId} FOR UPDATE

这个方案的风险是把所有预约请求都排队，高并发下吞吐量受影响，但美容院这种场景并发量极低，悲观锁反而简单可靠。源码里我最终用的还是“事务内查询加唯一索引兜底”，因为这样不用引入额外锁，代码也更短。建议你拿到源码后，把两种方案都尝试一下，并发测试结果一对比，理解立刻深一层。

6.2 订单状态机：四种状态如何流转

订单状态我用status字段管理，取值含义是：0待确认、1已确认、2已完成、3已取消、4已爽约。状态机流转规则如下：

当前状态	可触发动作	新状态
0 待确认	管理员确认	1 已确认
0 待确认	用户取消	3 已取消
1 已确认	服务完成	2 已完成
1 已确认	用户取消	3 已取消
1 已确认	到点未到店（定时任务）	4 已爽约
2 已完成	无操作	-

实际业务中我让预约创建后默认就是“待确认”状态，管理员在后台看一眼排班表后点“确认”，相当于给顾客一个确定的回复。你也可以改成“创建即确认”，那就把系统初始化流程简化，少一个状态。但对于美容院来说，美容师临时请假、调整设备是很常见的事，保留“待确认”状态，给门店留一个缓冲空间，更贴近真实运营。

6.3 超时未到店的调度处理

爽约是美容院最深的痛点，一个顾客预约了90分钟SPA，结果没来，美容师那90分钟就彻底空转了。系统里我加了一个简单的定时任务，每天营业时间结束后扫描当天“已确认但未完成”的订单，过了预约时间30分钟就自动置为“已爽约”，并释放该时间片给后面想插队的顾客。

定时任务在SSM里用Spring Task @Scheduled就很方便，配置一个cron表达式，比如每30分钟扫一次：

java复制@Scheduled(cron = "0 */30 * * * ?")
public void autoMarkNoShow() {
    List<AppointmentOrder> orders = appointmentMapper.selectNeedNoShow(new Date());
    for (AppointmentOrder order : orders) {
        order.setStatus(4);
        appointmentMapper.updateStatus(order);
    }
}

需要提醒的是，@Scheduled方法默认是单线程执行的，扫描途中如果遇到异常要加try-catch，不能让一次异常导致整个调度链路中断，后续订单就永远扫不到了。

6.4 并发压测怎么做才靠谱

开发完后我用JMeter简单压了一轮，不为什么大流量，纯粹验证冲突处理是否生效。测试方法是：用500个线程并发预约同一个美容师的同一个时间片，预期结果应该是第一个线程成功，其余全部返回“该时间段已被预约”的业务异常。跑完后看数据库，确认只有一条订单记录存在，唯一索引和事务都起作用了。这个测试结果截图我放进了项目的README，后面自己改逻辑时可以重新跑一遍做回归验证。

7. 从源码到线上运行：环境配置与部署避坑实录

7.1 本地环境怎么快速跑起来

源码工程默认大家用的是：JDK 8、Tomcat 8.5、MySQL 5.7、微信开发者工具最新稳定版。导入步骤我写得很机械，因为真的太多人在环境上卡住：

先建数据库beauty_db，执行项目根目录sql/init.sql，会建好四张表并插入演示数据。
改jdbc.properties里的数据库账号密码，注意MySQL 5.7的useSSL=false参数要保留。
用IDEA导入Maven工程，等待依赖下载完成。如果网络慢，换阿里云镜像源，这个在pom.xml里已经预留了注释。
配置Tomcat的Deployment，把工程打war包部署并启动。
打开微信开发者工具，导入mini-program目录，把utils/config.js里的BASE_URL改成http://localhost:8080。
微信开发者工具右上角“详情-本地设置”，勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。这是本地联调的标准操作，只有勾选后小程序才能访问非HTTPS的本地接口。
编译运行，首页能出数据就说明后端和小程序打通了。

整个流程里最重要的就是第6步，不勾选那个校验选项，你会在控制台看到一堆“request:fail url not in domain list”的报错，其实后端一切正常，只是小程序的安全策略挡住了非白名单域名。

7.2 上线时必须处理的HTTPS和域名问题

本地调试可以跳过域名校验，但一旦要发布体验版或正式版，小程序强制要求接口走HTTPS，且域名必须备案。我的处理方案是：一台云服务器上装Nginx，监听443端口，配置SSL证书，然后把请求反向代理到内网的Tomcat 8080端口。Nginx配置核心段大概这个样子：

nginx复制server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate     /etc/nginx/ssl/example.pem;
    ssl_certificate_key /etc/nginx/ssl/example.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

然后去微信公众平台“开发管理-开发设置-服务器域名”里添加request合法域名为https://api.example.com。图片如果也是自己服务器存的，还要在downloadFile合法域名和图片域名里一起配上，否则项目列表里的图片还是裂的。这一步是上线最容易被忽略的坑。

7.3 三个值得专门记录的调试问题

第一个坑是JSON日期格式。Java后端用Jackson序列化LocalDateTime时，默认输出格式是一串数字时间戳，小程序端拿到的字符串完全不可读。解决办法是在实体类日期字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")，以及全局配置里设置ObjectMapper的时间格式。但更推荐的做法是前端接yyyy-MM-dd和HH:mm这两种简化格式即可，展示时直接用字符串拼接，不依赖Date对象解析，省事很多。

第二个坑是图片上传和后端静态资源映射。小程序端无法直接读取本地文件系统，开发阶段我临时把图片放在Tomcat的webapps目录下，通过http://localhost:8080/upload/xxx.jpg访问。但这只是权宜之计，上线前一定要迁到对象存储服务，或至少换成独立的静态资源服务器，不能把图片存在Tomcat里，不然容器重启或重新部署时图片可能被清掉。

第三个坑是MySQL 8.0的驱动差异。如果你本地装的是MySQL 8.0，需要把com.mysql.jdbc.Driver换成com.mysql.cj.jdbc.Driver，同时连接串里加serverTimezone=Asia/Shanghai，否则会因为时区问题直接报错。源码里我放的是兼容性写法并加了注释，但如果你是从网上找的旧版源码，这个问题非常大概率会遇到。

7.4 上线前应该补的最小安全清单

最后列几个我实践后认为不能省的安全措施。第一，小程序登录接口必须限制频率，防止有人拿你的AppID去刷接口，给后端造成无谓压力。第二，所有业务接口都要校验token，除了登录和获取基础配置之外，不能有任何裸奔接口。第三，管理员接口不能让普通用户调用，后台上要加角色鉴权，哪怕简单到用一个role字段加拦截器判断就行。第四，SQL参数全部走MyBatis预编译，绝对不能拼接字符串——项目列表里那个LIKE CONCAT('%', #{keyword}, '%')就是标准写法，不要为了图省事改成'%' + keyword + '%'字符串拼接。

我个人做这个项目最大的体悟是：预约类系统的核心从来不在界面多漂亮，而在于如何把“时间片、冲突、状态”这三个字处理干净。数据库唯一索引、事务内区间探查、状态机流转，这三样东西想明白了，换个领域再做会议室预约、理发店排队、健身房团课，骨架都是一样的。后续如果你想扩展，可以加微信服务通知提醒顾客到店、给美容师做一个独立的小程序端查看自己的日程、预约成功后自动扣款或押金支付。这个项目目前的价值是给你一个可以放心改的起点，所有扩展都从理解那几张表和那一层事务开始。