春节前后那段时间，我帮朋友的小餐厅做了一个预约点餐的小程序。朋友店不大，但一到饭点高峰期，电话响个不停，要么是问还有没有位子，要么是临时订桌结果到了发现已经被坐满。做之前我调研了一圈，市面上扫码点餐的SaaS挺多，但大多是固定模板：要么只支持菜品下单，要么预约功能做得太浅，商家连“哪个时段放多少桌”“超时多久自动释放”这种基本规则都改不了。干脆直接用SpringBoot写后端，微信小程序做前端，从零搓一套餐厅预约系统。这套系统跑下来，预约到店率明显提升，朋友也第一次感受到了“数据化排班”的爽快感。这篇文章就把整个项目的核心设计、关键代码和踩过的坑全部整理出来，给准备自己动手做同类型项目的开发者一个完整的参考。
1. 整体设计与技术选型：为什么是SpringBoot加小程序这对组合
1.1 技术选型背后的逻辑
先说后端。SpringBoot在这个场景里几乎是最稳妥的选择，不是因为它花哨，而是因为它的生态成熟度和开发效率太适合这种中小型业务系统了。预约系统本质上就是一组CRUD加状态流转，加上一点并发控制，并不需要微服务那套复杂度。SpringBoot自带嵌入式Tomcat、自动装配、spring-boot-starter-data-jpa或者MyBatis-Plus集成，写起来非常顺手。部署也简单：打一个jar包扔到服务器上，java -jar一跑就完事。唯一要留意的是SpringBoot版本问题，后面我会专门讲，因为版本选不对坑起来真的很要命。
小程序端则是刚需。餐厅预约这个场景极具“低频但不临时”的特点——用户不会天天打开，但一旦打开基本都是即时需求，比如“我现在过去还有位子吗”。这种需求如果让用户下载App，转化率基本归零；如果做H5，用户用完即走，下次再找入口又很麻烦。小程序正好卡在两者中间：微信里搜一下就能开，用完可以留在“最近使用”列表里，下次直接下拉就能找到。而且微信提供了wx.login静默登录，用户连注册流程都省了。这套组合的本质逻辑是：后端追求稳定快速交付，前端追求零门槛触达，一重一轻，正好互补。
1.2 系统角色与模块边界
在设计阶段，我把系统分成了三个角色：普通用户、餐厅商家、系统管理员。听起来简单，但这个角色划分直接决定了我后来所有表结构和接口的设计。
用户端看到的功能是：餐厅列表、餐厅详情（包括餐位类型、营业时间、当前排队人数）、提交预约（选日期、时段、人数、备注）、查看我的预约、取消预约。商家端要复杂一些：餐厅基础信息维护、餐位类型管理（比如四人桌、六人桌、包间）、预约时段配置（比如午餐时段11:00-14:00分几个slot）、预约审核/确认、到店核销、预约统计。管理员不多做，主要管用户封禁和全局参数，比如允许提前多少天预约、超时未到店自动取消多久生效。
这样的模块划分有一个关键好处：边界清晰，前端页面和后端接口都能一一对应。我见过很多项目图省事，用户端和商家端混在一个接口里，靠参数区分角色，结果改一处崩一片。宁可前期多建两张表、多拆几个Controller，也别为了省事埋雷。
2. 小程序前端核心功能：从预约流程到列表加载的细节处理
2.1 预约主流程与页面设计
预约是这套系统的心脏。整个流程我串成了四条页面：餐厅列表页 -> 餐厅详情页 -> 预约下单页 -> 我的预约列表页。流程看起来平铺直叙，但每个环节都有细节。
餐厅列表页的排序逻辑直接影响了用户体验。单纯按距离排序看似合理，但用户更关心的是“这家现在还能不能约”。所以我在后端接口里做了一个复合排序：营业状态正常的优先（打烊的直接沉底），今日剩余可预约时段数多的排前面，最后才是距离。这个逻辑放在SQL里做很别扭，我是在Java里取列表后根据当时的时间动态算出来的，因为“剩余可预约时段”是会随着时间变化的，缓存反而麻烦。
餐厅详情页有个小细节很多人容易忽略：营业状态。如果你是做纯预约系统，页面倒还好；但如果餐厅在午休时间，用户预约晚餐时段，你得让用户明确感知到“当前是休息时间，但可以预约晚上”。我的方案是页面顶部显示一个实时状态条，由后端根据餐厅营业配置和时间动态算出并返回，前端拿这个字段做展示，而不是前端自己算，因为餐厅可能有临时歇业等特殊配置，前端算容易不一致。
预约下单页需要同时处理三个维度的状态：日期、时段、人数。我最初的设计是把“人数”放在详情页就让用户选，进了下单页只选日期和时段。结果发现挺多用户会进到下单页才发现人数选错了，又得退回去。后来我把人数选择挪到了下单页第一步，日期第二步，时段第三步，每个步骤一个Picker组件。这样流程更顺，后端校验逻辑也更清晰，因为“某时段某日期下还有没有对应人数的空位”在同一个请求里就能算清楚。
提交预约的按钮必须做防止二次提交处理。这不是什么高级功能，但很实在：用户手抖点了两下，后端收到了两条一模一样的预约请求，如果接口没有幂等处理，用户就看到两个预约单。我的方案是小程序端提交时生成一个UUID作为reqId，后端在Redis里用SETNX做去重，同一reqId只处理一次。没有Redis的话可以用数据库的唯一索引兜底，实战中这招值得每张核心业务表都用上。
2.2 列表加载更多与顶部导航适配
餐厅列表页不可能一次拉全量数据，一是数据可能多，二是一次性渲染几十个餐厅卡片在小程序里会卡顿。所以必须做分页加载。我采用的是最简单的页码分页：page和size两个参数，后端返回当前页数据加一个hasMore标志位。前端用onReachBottom触发下一页加载。
这里有一个新手很容易踩的坑：列表数据的初始加载和下拉加载必须用同一个函数，但loading状态要分开控制。初始加载用骨架屏或整页loading，加载更多用底部“加载中”提示。如果都用一个loading变量，会出现一个典型Bug：用户快速上下滚动，下拉触发加载的时候，全局loading被顶掉，页面整个闪了一下白屏。我的做法是维护两个状态：initLoading和loadMoreLoading，数据渲染也不同——请求返回后拼接数组而不是覆盖数组。
再说顶部导航栏高度这个细节。小程序原生导航栏在不同机型上的高度不一样，尤其是有胶囊按钮的机型，自定义导航栏时如果硬编码一个固定的高度，iPhone和某些安卓机型上就会出现按钮重叠。我的兼容方案是：用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的位置信息，再根据系统信息计算导航栏高度。计算方式是：胶囊按钮的top值减去状态栏高度再加上胶囊高度的一半，得到导航栏中心点，再乘以2得到导航栏总高度。这套公式在小程序社区里已经流传很久，实测兼容性很好。餐厅详情页头部有个返回按钮和店名标题，如果高度适配不对，标题会顶在很靠上的位置，视觉上看非常业余。
3. SpringBoot后端核心实现：表结构、并发控制与接口规范
3.1 核心表结构设计
预约系统的表结构说复杂也复杂，说简单也简单，关键看你想做到什么粒度。我最终是拆成了五张核心表：餐厅表（restaurant）、餐位类型表（seat_type）、预约时段配置表（time_slot）、预约订单表（reservation）、用户表（user_info）。
餐厅表和餐位类型表是一对多的关系：一家餐厅有多个餐位类型，比如“四人桌”库存10张，“包间”库存2个。这张表在初始化时就要把库存这个概念埋进去，因为后面所有的并发控制、剩余量计算都依赖于“库存”。我建表时的几个关键字段摘出来给参考：
CREATE TABLE seat_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, restaurant_id BIGINT NOT NULL COMMENT '餐厅ID', name VARCHAR(30) NOT NULL COMMENT '类型名称，如四人桌', capacity INT NOT NULL COMMENT '可容纳人数', total_count INT NOT NULL COMMENT '总数', reserved_count INT DEFAULT 0 COMMENT '已预约数', sort_order INT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_restaurant (restaurant_id) );time_slot表存的是模板，比如每天的午餐时段拆成几个slot，每个slot起止时间，以及每slot的放号总量。这里有个设计取舍：是把某个日期的某个slot作为一条记录（如2025-06-01 11:00-12:30一条），还是把星期几作为模板（周一11:00-12:30一条），然后预约时再去动态算？如果系统只支持未来一周预约，那每天的slot在凌晨生成任务批量创建是更好的方式，因为每天的库存独立，方便做“今日剩余”统计，也方便设置“某一天临时关闭预订”。我选择了后者：每天凌晨由定时任务给未来7天生成slot记录。这样表里查预约容量、算余量都非常直接，不用在查询时做复杂的时段匹配。
reservation表是重中之重。我除了业务字段外，还特意加了status字段（0待确认、1已确认、2已到店、3已取消、4超时未到店）和version字段（乐观锁用）。为什么不用更复杂的订单状态机？因为预约业务的流转其实是线性的：提交->确认->到店，中间插入取消和超时两个异常分支，状态枚举就够了，上状态机框架属于过度设计。
3.2 并发预约与防超卖
预约系统的并发量远没有秒杀那么夸张，但“防超卖”的需求是一样的。高峰期同一时段可能有几十个人同时在预约，如果都只做简单的先查后插，就会发生：两个人同时查看到还剩1个名额，同时提交预约，结果都成功了，但实际只该有一个人成功。
我的处理思路是三层防线。第一层，Redis预热库存（Lua脚本来保证原子性），适用于高并发时段；第二层，数据库乐观锁，用version字段控制更新；第三层，数据库唯一约束，保证同一用户同一时段只能有一条未取消的预约。对于餐厅这种体量，我实测下来第三层核实已经能解决绝大多数并发问题，但考虑到未来做连锁餐厅、多家分店，还是上了Redis+Lua。
先看最基础的“先查后插”写法为什么有问题：
// 错误示例：先查后插会产生超卖 SeatType seatType = seatTypeMapper.selectById(seatTypeId); if (seatType.getReservedCount() < seatType.getTotalCount()) { seatType.setReservedCount(seatType.getReservedCount() + 1); seatTypeMapper.updateById(seatType); // 创建预约订单 }这个操作用两个线程并发执行时，A和B同时读到reserved_count = 9（总量10），A更新为10，B也更新为10，最后reserved_count还是10，但实际上两个预约都成功了，库存超卖。数据库层面虽然没有报错，业务上却已经错了。
我最终采用的方案是数据库乐观锁更新：
// 先执行更新，返回影响行数 int count = seatTypeMapper.updateReservedCount(seatTypeId, version); if (count == 0) { throw new BizException("手慢了，该时段名额刚刚被抢完"); }对应的SQL是：
UPDATE seat_type SET reserved_count = reserved_count + 1, version = version + 1 WHERE id = #{seatTypeId} AND version = #{version}这里有两个关键点：一是先去更新，更新成功再创建订单，把两个操作放进同一个事务里；二是update时把version作为条件带进去，影响行数为0说明版本号已经变了，即有人在本次查询之后修改过了，于是直接抛出业务异常。这样避免了并发情况下的超卖，而且不需要额外的分布式锁，对于单体应用足够可靠。
如果要用Redis做前置拦截，Lua脚本的核心逻辑是：
local reserved = tonumber(redis.call('HGET', KEYS[1], ARGV[1]) or '0') local total = tonumber(redis.call('HGET', KEYS[1], ARGV[2]) or '0') if reserved < total then redis.call('HINCRBY', KEYS[1], ARGV[1], 1) return 1 else return 0 endRedis库存和数据库库存之间的一致性靠定时对账任务兜底：每分钟扫描一次HASH中当天最新的商户库存，和数据库进行比对，找出不一致的以数据库为准修正，同时补一个对账日志。这套对账逻辑虽然简单，但能避免Redis和数据库在极端场景下越差越大，属于“宁可多做不可不做”的保障。真正做的时候，建议把Redis的库存只作为准入控制，数据库的乐观锁再做一次校验，双保险。
3.3 接口设计与统一返回规范
后端我用的Controller层只做参数接收和返回响应，核心业务逻辑全部下沉到Service。每个接口的返回结构统一是：
public class Result<T> { private Integer code; // 0成功，非0业务错误 private String msg; // 提示信息 private T data; // 业务数据 }重点讲两个接口的设计。第一个是“获取可预约时段”：参数是restaurantId和date，返回一个slot列表，每个slot含有剩余可预约量。这个接口我一开始直接在Service里查数据库，后来发现性能不行——餐厅详情页几乎每个用户进来都会请求一次，如果赶上高峰期，数据库压力不小。后来加了Redis缓存，key设计为“reservation:slot:restaurantId:date”，过期时间设为该日期当天的结束时间，这样当天数据一旦生成就不会频繁查库。唯独“剩余可预约量”这个字段不能缓存太久，因为每产生一个预约都要实时扣减。我的方案是缓存slot的基础信息，剩余量实时查Redis；如果Redis挂了，降级走数据库，保证基础可用。
第二个是“提交预约”：参数包含restaurantId、seatTypeId、date、slotId、人数、备注。这个接口要做三步校验：餐厅是否营业、slot是否开放、剩余量是否充足。三步校验顺序不能乱，先查餐厅状态可以最快拦截无效请求，再查slot是时间维度的精确判断，最后查库存是数量判断。校验全部通过后，进入上面说的乐观锁更新逻辑，然后创建预约订单。整套逻辑放在@Transactional里，保证seat_type的更新和reservation的插入要么都成功要么都失败。这里要注意事务的隔离级别，默认的READ_COMMITTED就够了，不要为了图省事把隔离级别设置成SERIALIZABLE，那样并发性能会断崖式下降。
4. 联调与上线部署：小程序真机调试、域名配置与版本坑
4.1 小程序联调：开发者工具只是开始，真机才是真相
整个项目开发周期里，联调阶段花的时间占比不小。小程序开发者工具的模拟器很好用，但它和真机之间的差异比很多人想象得大。我遇到过的几个典型场景：模拟器上定位正常，真机拿不到位置权限；模拟器上request请求没问题，真机上报“不在以下合法域名列表”中；模拟器上页面滑动流畅，真机上下拉加载更多的时候卡顿明显。
所以我的习惯是：功能在开发工具里调通后，第一时间用真机跑一轮全流程。真机调试有几个准备工作：一是开发者工具右上角“详情”里勾选“不校验合法域名”，但注意这只是开发阶段用的，发布前一定要关掉，然后在小程序后台配置request合法域名；二是用真机配合代理工具抓包看请求，我个人喜欢用Charles，能看到小程序和服务器之间的完整HTTP交互，排查问题效率非常高。
这里想多说一句关于接口联调的细节：小程序端的request封装必须统一处理登录态失效问题。具体做法是在封装的request函数里统一加上token（通常是从wx.login获取的code换来的session），后端返回特定错误码（如401）时，全局拦截并跳转到登录页重新授权登录。如果没有这一层，用户在一个页面停留十分钟后token过期，再点提交预约就会报一个莫名其妙的错误，体验非常糟糕。
4.2 SpringBoot版本选型与部署注意事项
SpringBoot的版本真的是老生常谈，但我还是要重点说，因为我就在这上面栽过跟头。我最初图新鲜用了SpringBoot 3.5，结果发现我的旧版MyBatis-Plus不兼容，不得不换到3.5.1版本才跑通。不是版本越新越好，要看你的核心依赖是否适配。如果团队对Cloud、MyBatis-Plus等生态链没有把握，SpringBoot 2.7.x或者2.9的稳定分支其实更省心。
另外一个常见的启动配置问题是端口冲突。SpringBoot默认8080，但服务器上可能已经跑着别的服务。我习惯在application.yml里显式配置端口、上下文路径和时区：
server: port: 8080 servlet: context-path: /api spring: jackson: time-zone: GMT+8 date-format: yyyy-MM-dd HH:mm:ss datasource: url: jdbc:mysql://localhost:3306/restaurant?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Drivercontext-path设置为/api有几个好处：一是解决多服务反代时的路径区分问题，二是前端请求统一以/api开头，代码里路由前缀清晰，三是生产环境Nginx转发时不用重写路径那么麻烦。时区配置这块千万别省，Java默认时区和MySQL的时区如果不一致，日期字段查询出来会莫名少8小时，排查起来极其痛苦。
部署上线的时候还有一笔账要算清楚：小程序要求所有请求必须是HTTPS。这意味着服务器上必须部署SSL证书。证书可以用云服务商的免费证书搞定，比如阿里云或腾讯云每人都能申请免费的DV证书，一年有效期，到期前有邮件提醒。别忘了小程序后台的request合法域名配置，域名必须是备案过的，且不能带端口号。这是很多人第一次开发小程序时最容易卡住的地方——本地调试没问题，一发布线上就白屏，十有八九就是合法域名没配置或者证书没过期。
4.3 常见问题速查表与排查技巧
整理一份我实际开发过程中踩过的坑，按问题、原因、解决方案列出来，给读者一份可以随时翻查的清单。
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 小程序真机请求失败，开发者工具正常 | 没配置request合法域名 | 在小程序后台配置域名，或开发阶段勾选“不校验合法域名” |
| 后端返回时间比实际少8小时 | MySQL连接串没配serverTimezone | JDBC URL加上serverTimezone=Asia/Shanghai，并设置Jackson时区 |
| 提交预约偶发重复单 | 前端重复点击，接口没做幂等 | 前端生成reqId，后端用Redis SETNX去重 |
| 高峰期时段剩余量显示不准 | 缓存了剩余量字段 | 剩余量字段不缓存，实时查Redis/DB；基础数据才能缓存 |
| 小程序自定义导航栏标题被胶囊遮挡 | 硬编码导航栏高度 | 用getMenuButtonBoundingClientRect动态计算 |
| SpringBoot启动闪退 | 版本过高或过低与依赖不兼容 | 锁定SpringBoot稳定版，配套MyBatis-Plus版本用官方推荐的对应版本 |
| 用户预约后商家不知道有新订单 | 没有通知机制 | 接入了订阅消息，用户在预约成功后请求一次订阅授权，商家审核时触发通知 |
排查问题时我建议按“前端拦截 -> 后端接口 -> 数据库数据”这个顺序逐层排查。先看小程序端的Network请求返回了什么，再看后端日志里有没有业务流程输出的关键节点（比如提交预约时校验的每个步骤是否通过），最后查表确认数据状态。这套顺序在最复杂的联调场景里帮我节省了大量时间。反向排查（先查数据库再找原因）通常会把问题放大，因为你很难判断数据异常是前端传错还是后端逻辑错了。
5. 预约排队与实时通知的进阶处理
基础系统的预约功能跑通之后，需求方通常会追加两个“更人性化”的功能：排队叫号和实时通知。这两个功能是提升体验的关键，也是小程序端和后端技术上有一定挑战的部分。
排队叫号的场景是：餐厅位子已满，用户可以选择进入排队队列，等待有位置空出时微信通知他。这里就涉及到“排队队列如何实现”与“如何发送叫号通知”。我选择的是：用户点击“进入排队”，后端创建一条queue_record，status为waiting；餐厅每完成一个预约的到店核销，就把同类型的排队队列的队头用户状态改为notify_sent，并通过微信订阅消息发一条叫号通知。这里有个简单但有效的做法：不引入消息队列，只用数据库的偏序状态流转。因为餐厅排队量不大，且叫号通知是主动触发的，用数据库记录状态、前台轮询的方式完全跑得动，比自己搭一套Kafka或者RabbitMQ省太多事。
但“轮询”这套方案如果想做得更平滑，可以考虑微信小程序的WebSocket能力。小程序有原生WebSocket支持，后端用Spring的WebSocket端点做推送，用户进入小程序且停留在餐厅详情页时建立连接，服务端有队列变化就直接推过去。SpringBoot整合WebSocket其实很简单，一个@ServerEndpoint注解就能搞定，难点在于管理连接和用户身份绑定。我的做法是：连接建立时通过URL参数传递一个小程序端生成的随机会话标识，后端把这个标识和userId的关联关系写入一个ConcurrentHashMap，推送时根据userId找到对应的WebSocketSession发送。
订阅消息的坑也要单独说。小程序的订阅消息和公众号的模板消息不一样，它是一次性订阅：用户点了订阅授权之后，你只能给他推一次消息。所以预约成功、排队叫号这类消息，要在用户操作的那个节点去请求授权。比如用户提交预约成功后弹出一个邀请授权的对话框，他点击允许，你才有推一次预约结果通知的资格；如果他不点，那这个通知就发不出去。这就意味着消息推送不能作为核心流程的依赖，只能当作锦上添花。
我在实际项目里是这么处理这个限制的：在被推送方（商家）那端用短信代替，因为商家是高频使用方，需要稳定可靠的通知方式；在用户端则明确不依赖订阅消息的送达率，如果用户没收到通知，他打开小程序看到“我的预约”状态变化也能感知到。这个设计既降低了开发成本，又保证了核心体验不崩塌。千万不要试图用订阅消息做“预约成功”之后的强依赖逻辑，送达率无法保证。
实时叫号还有一个效果上的选择：是做数字显示在餐厅大屏上，还是只给用户发通知？如果你的客户是大型连锁餐厅，那可能真的要做个大屏页面让用餐区所有顾客都能看到；如果只是中小餐厅，那给用户发通知就够了，不必增加硬件成本。系统的扩展性体现在这里——不要把功能堆上去，而要根据实际规模做恰当的取舍。
6. 运营数据与预约状态流转的兜底设计
预约系统上线后，商家最关心的是“今天有多少人预约”“哪些时段最热门”“有没有人预约了没来”。所以想尽办法把数据留全，后面数据报表才做得出价值。
预约订单的状态流转我设计了五个状态：待确认、已确认、已到店、已取消、超时未到店。这里有两个容易被忽略的设计细节。
第一个是超时未到店状态的处理。用户预约了晚上7点的位子，如果6点50还没有确认到店，难道要一直等到晚上吗？我在预约时段结束前30分钟跑一个定时任务，把该时段内所有状态仍是“待确认”或“已确认”的订单自动置为“超时未到店”，并把对应餐位库存回补。这个策略对商家非常有用，因为餐位是全天循环利用的资源，一个订了不来的用户空占位子远比损失一个客户的预约更伤。定时任务用的是SpringBoot的@Scheduled注解，corn表达式每天定时扫描，配合状态字段做幂等处理，避免重复扫描和重复回补。
第二个是预约取消的库存回补。用户主动取消预约时，需要把对应时段餐位的已预约数减回去。如果只是把订单状态改为“已取消”，不回去更新seat_type表里的reserved_count，那么随着取消次数增加，库存会越来越少，最终导致系统显示没有位子但实际餐厅空位满满。所以取消的逻辑一定要在同一个事务里做两件事：更新订单状态为取消、回补餐位库存（且这个回补必须是原子操作）。回补SQL和预订时的逻辑对称：
UPDATE seat_type SET reserved_count = reserved_count - 1, version = version + 1 WHERE id = #{seatTypeId}admin端的数据统计模块，我按期初做了一个“预约趋势折线图”和“餐位利用率热力图”，既满足商家对“周一到周日哪个时段最旺”的认知需求，又能用数据反推运营策略。统计接口不追求实时，每天凌晨把前一天的数据汇总进一张统计表，查询时直接读统计表，不做复杂的SQL聚合——既快又减轻数据库压力。
7. 从项目实战到方案沉淀：后续可扩展的方向
系统交付之后，我自己复盘了一下整个设计和开发过程，最大的体会是：预约系统的难点不在写代码，而在“边界”的把握。你要想清楚哪个状态流转需要事务、哪个可以异步；哪个库存要实时扣减、哪个可以容忍短时不一致；哪个通知能作为强依赖、哪个只能做补充。技术选型上，SpringBoot加小程序是一个被验证过无数次的黄金组合，它能用最小的成本覆盖掉餐厅预约的主流场景。如果你正在做类似的项目，我把几个值得扩展的方向列出来供参考。
第一个方向是“预约+点餐”一体化。预约到店后紧接着就是点餐，如果能把预约单和点餐单打通，用户到店后不用再扫一次二维码点餐，商家也能提前备菜。这个场景在多人聚餐、宴会预订时价值特别大。
第二个方向是接入支付押金或定金。对于包间、节假日座位这类稀缺资源，单纯的预约很容易被放鸽子。在预约流程中做一个“预付定金”环节（后端接入微信支付），用经济手段提高履约率。不过微信支付的小程序接入需要额外申请商户号，资质审核流程不短，预算充足才建议做。
第三个方向是闲时流量承接。餐厅的预约系统不只有预约功能，还可以做“闲时套餐”展示，比如工作日下午茶时段、夜宵时段，通过优惠价格引导用户在这些时段预约。这个方向虽然偏向运营，但系统的架构只需要多一个营销模块，收益却是实打实的。
最后补充一点个人经验：做这类中小型系统，代码质量和架构规范固然重要，但更重要的是快速交付、快速验证。初期版本先砍掉复杂的数据统计、砍掉消息队列、砍掉精细的权限控制，把预约的核心链路做扎实，上线跑通后再迭代。我见过太多人花了两周设计表结构、一个月开发管理后台，结果核心预约流程连一次规规整整的联调都没做过。做系统就像做菜，先端出一锅能吃的，再慢慢调味，好过规划了一个满汉全席最后灶台都没开火。
这个项目做完，我自己最大的收获反而不是技术上的——SpringBoot和小程序的知识网上一搜一大把。真正值钱的是那些踩坑踩出来的经验：时区为什么会错8小时、乐观锁在什么场景下真正有效、订阅消息的送达率天花板在哪、小程序自定义导航栏到底怎么适配。这些内容教科书里没有，千里之外的同行也不会专门告诉你。整理出来分享给大家，也是希望后来者能少走几步弯路。
