简介：这是一套面向酒店行业开发者与中小连锁酒店经营者的多酒店预订管理系统源码，覆盖APP、H5与小程序三端，可解决分店扩张、房态同步、会员营销与内部协同等实际业务问题。资源包共2582个文件，约80.13MB，以1428个PHP业务代码为核心，辅以126个HTML页面、101个SCSS与49个CSS样式文件、66个JS脚本，并包含126个MP3语音提示素材、122张JPG与58张PNG图片资源，以及SQL脚本、JSON配置和Markdown说明文档，前后端与素材基本齐备。系统功能涵盖无限创建分店、入住与换房、预订管理、房态实时展示、语音播报、图表数据、预警提示、短信营销、会员与商品管理、报表中心、财务及设备管理；客户端支持酒店预订、点餐、叫服务与店内服务，另附内部员工App。目前已有392人学习下载，适合需要快速搭建多酒店运营平台、研究三端联动与后台管理架构的开发者参考复用。
1. 多酒店预订系统：为什么“一套后台管所有门店”比你想的更难
很多团队接酒店项目时，第一反应是“不就是把房态、订单、支付串起来吗”。真动手才发现，单店系统和多酒店系统根本是两个物种。单店可以硬编码一个 hotel_id，多酒店从第一天起就要面对数据隔离、房态同步、渠道价格差异、订单归属、结算分账这一连串问题。APP、H5、小程序三端同时接入，意味着同一份房态要在三种客户端、多个门店、多个渠道之间保持一致，任何一处状态不同步，用户看到的就是“明明显示有房，下单却失败”。
这个标题讲的是：用一套后端支撑多个酒店，通过 APP、H5、小程序三个入口完成查房、下单、支付、确认的完整预订链路。它适合正在做酒店管理系统毕业设计的学生、接中小连锁酒店外包的团队，以及想把单体酒店系统升级成 SaaS 多租户形态的开发者。核心难点不在页面，而在“多酒店”这三个字带来的数据模型和并发一致性。下面按我实际做过的路径，从数据模型一路讲到三端接入和排错。
2. 多酒店数据模型：租户隔离和房态表怎么设计
2.1 为什么不能只加一个 hotel_id 字段
最常见的偷懒做法是：所有表都加一个hotel_id，查询时where hotel_id = ?。单看功能没问题，但一旦涉及“集团统一查看所有门店订单”“跨店会员积分”“渠道价按门店覆盖”，这种平铺结构就会让 SQL 越来越长，权限判断散落在每个接口里，后期加一个门店就要改一堆代码。
我一般会把“酒店”抽象成租户（tenant），在数据访问层统一注入租户上下文，而不是让每个业务方法自己拼hotel_id。这样做的直接好处是：越权查询在 DAO 层就被拦住，而不是靠每个开发记得加条件。常见做法是用 MyBatis 拦截器或 Django 的 manager 做自动过滤，下面给一个 Django 侧的思路。
# models.py —— 多酒店核心表结构（简化） class Hotel(models.Model): name = models.CharField(max_length=100) city = models.CharField(max_length=50) status = models.SmallIntegerField(default=1) # 1营业 0停用 class RoomType(models.Model): hotel = models.ForeignKey(Hotel, on_delete=models.CASCADE) name = models.CharField(max_length=80) # 大床房/双床房 base_price = models.DecimalField(max_digits=10, decimal_places=2) total_rooms = models.IntegerField() # 该房型总房量 class RoomInventory(models.Model): """按天存房态，是并发扣减的核心表""" hotel = models.ForeignKey(Hotel, on_delete=models.CASCADE) room_type = models.ForeignKey(RoomType, on_delete=models.CASCADE) date = models.DateField() total = models.IntegerField() # 当日总房量 sold = models.IntegerField(default=0) # 已售 class Meta: unique_together = ('room_type', 'date') # 关键约束逻辑说明：RoomInventory按“房型 + 日期”一行存房态，而不是每次下单去 count 订单表。unique_together保证同一房型同一天只有一条记录，避免并发插入重复行。参数上，total是当日可售总量，sold是已售数量，剩余房量 =total - sold。下单时用update ... set sold = sold + 1 where sold < total这种带条件的原子更新，而不是先查再改，这是防超卖的关键。
2.2 房态扣减的原子操作与库存预热
多酒店场景下，房态不是实时算出来的，而是提前“铺”出来的。我一般会写一个定时任务，把未来 90 天的房态按房型批量生成，避免下单时才发现当天没有库存记录。生成逻辑用bulk_create加ignore_conflicts，重复执行不会报错。
# 房态预热：为每个房型生成未来 N 天库存 from datetime import date, timedelta def warm_up_inventory(days=90): today = date.today() records = [] for rt in RoomType.objects.select_related('hotel').all(): for i in range(days): records.append(RoomInventory( hotel=rt.hotel, room_type=rt, date=today + timedelta(days=i), total=rt.total_rooms, sold=0 )) RoomInventory.objects.bulk_create(records, ignore_conflicts=True)扣减时不要用 Python 层的save()，直接用数据库原子更新：
# 下单扣库存：带条件的原子更新，返回受影响行数 updated = RoomInventory.objects.filter( room_type_id=rt_id, date=checkin_date, sold__lt=F('total') ).update(sold=F('sold') + 1) if updated == 0: raise StockError("该日期房型已售罄")参数说明：sold__lt=F('total')是数据库层的比较，保证不会超卖；update返回受影响行数，为 0 说明没抢到。这里要注意，如果一次订单跨多天，必须在一个事务里逐天扣减，任何一天失败就整体回滚，否则会出现“入住日扣了、离店日没扣”的脏数据。
2.3 多酒店权限与数据隔离的落地方式
数据隔离有两种常见做法：一种是共享库共享表靠hotel_id过滤，另一种是每个酒店独立 schema。中小连锁我推荐前者，成本低、运维简单；门店数量上百、有强合规要求时再考虑分库。关键是隔离逻辑要收敛到一处，不要散落。
# 统一租户过滤：请求进入时确定当前 hotel_id class TenantMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): # 从登录态或子域名解析当前酒店 request.hotel_id = resolve_hotel(request) return self.get_response(request)逻辑说明：resolve_hotel可以从 JWT 里的 hotel_id 取，也可以按子域名映射（如a.example.com对应 A 店）。后续所有查询通过封装好的 manager 自动带上hotel_id，业务代码不再手写过滤条件。这样即使新人写查询忘了加条件，也不会查到别家酒店的数据。
3. APP、H5、小程序三端接入：一套接口怎么喂三种客户端
3.1 三端差异到底在哪，别被“一套代码”忽悠
APP、H5、小程序虽然都能调同一套 REST 接口，但差异集中在登录态、支付、页面栈和缓存策略上。小程序没有 Cookie，登录靠code换openid；H5 在微信里要用公众号授权，出了微信又要账号密码；APP 有自己的本地存储和推送。接口层如果按端硬编码分支，很快就会变成 if-else 地狱。
我的做法是：接口只认“渠道标识”，把差异收敛到登录和支付两个适配层。业务接口（查房、下单、订单详情）三端完全共用，请求头带X-Client: app|h5|mp，后端据此决定返回的支付参数格式。
| 维度 | APP | H5 | 小程序 |
|---|---|---|---|
| 登录态 | 本地 token | Cookie / token | code 换 session |
| 支付 | 原生 SDK | 公众号 JSAPI | 小程序支付 |
| 页面栈 | 原生路由 | 浏览器历史 | 小程序路由 |
| 缓存 | 本地数据库 | localStorage | Storage API |
这张表不是让你照抄，而是提醒：真正需要分端处理的只有登录和支付，其余接口强行分端只会增加维护成本。
3.2 统一预订接口的设计与参数约定
查房接口三端共用，入参固定为酒店、入住日期、离店日期、人数。返回结构里带上每个房型的剩余量和价格，前端自己决定怎么渲染。
// 统一查房接口返回结构 { "code": 0, "data": { "hotel_id": 12, "checkin": "2025-06-01", "checkout": "2025-06-03", "room_types": [ { "room_type_id": 301, "name": "高级大床房", "price": 388.00, "remain": 5, // 剩余可售 "dates": [ // 逐日房态，跨天订单要用 {"date": "2025-06-01", "remain": 5}, {"date": "2025-06-02", "remain": 3} ] } ] } }参数说明：remain取的是跨天里最小的剩余量，因为只要有一天不够，整单就下不了。dates数组给前端做日历展示，也方便后端下单时逐天校验。注意价格要按日期返回，周末和节假日价格不同，不能只给一个均价。
下单接口要幂等，防止用户连点或网络重试导致重复下单。常见做法是前端生成一个request_id，后端用它做唯一约束。
# 下单幂等：request_id 唯一约束 class Order(models.Model): request_id = models.CharField(max_length=64, unique=True) hotel = models.ForeignKey(Hotel, on_delete=models.CASCADE) # ... 其他字段逻辑说明：同一个request_id第二次进来会触发唯一约束异常，捕获后直接返回第一次的订单结果，而不是再扣一次库存。参数上request_id由客户端生成，建议用 UUID，长度 64 足够。
3.3 三端登录与支付适配的最小实现
小程序登录：前端wx.login拿 code，后端调微信接口换openid和session_key，再签发自己的 token。H5 在微信内走公众号授权拿openid，微信外走手机号验证码。APP 走账号密码或短信登录。三端最终都落到同一张用户表，用union_id或手机号做关联。
# 小程序登录换 token（示意） def mp_login(code): resp = requests.get(MP_LOGIN_URL, params={ 'appid': APPID, 'secret': SECRET, 'js_code': code, 'grant_type': 'authorization_code' }).json() openid = resp.get('openid') if not openid: raise AuthError(resp.get('errmsg')) user, _ = User.objects.get_or_create(openid=openid) return issue_token(user)参数说明：js_code是小程序端wx.login返回的临时凭证，只能用一次；openid是小程序内用户唯一标识。注意session_key不要下发给前端，它只用于后端解密敏感数据。支付适配层同理，三端各自调起支付，但订单状态回调用同一个接口处理，回调里根据渠道标识验签。
4. 订单与房态一致性：并发下单和超时释放怎么处理
4.1 并发下单为什么会超卖，锁加在哪一层
超卖的根因是“查库存”和“扣库存”之间有时间差。两个请求同时查到剩余 1 间，都以为能下单，结果各扣一次。解决办法不是加 Python 线程锁，因为多进程部署下锁不住；要用数据库层的原子操作或行锁。
前面 2.2 给的update ... where sold < total就是乐观锁思路，靠数据库保证原子性。如果业务复杂到需要先读再判断，就用select_for_update加行锁，但要注意锁的范围和顺序，避免死锁。
# 行锁方式：在事务内锁定库存行 from django.db import transaction @transaction.atomic def create_order(hotel_id, rt_id, checkin, nights): for i in range(nights): d = checkin + timedelta(days=i) inv = RoomInventory.objects.select_for_update().get( room_type_id=rt_id, date=d ) if inv.sold >= inv.total: raise StockError(f"{d} 已售罄") inv.sold += 1 inv.save()逻辑说明：select_for_update在事务内锁定该行，其他事务要等锁释放。参数上nights是入住天数，逐天锁定。注意锁的获取顺序要一致（都按日期升序），否则两个跨天订单可能互相等锁形成死锁。
4.2 未支付订单的超时释放
用户下单后不付款，库存一直被占着，别人就订不了。常见做法是下单时扣库存，同时写一条延迟任务，15 分钟后检查订单状态，未支付就释放库存并把订单置为已取消。
# 超时释放：定时扫描待支付订单 def release_expired_orders(): deadline = timezone.now() - timedelta(minutes=15) orders = Order.objects.filter( status='pending', created_at__lt=deadline ) for order in orders: with transaction.atomic(): # 释放逐日库存 for item in order.items.all(): RoomInventory.objects.filter( room_type_id=item.room_type_id, date=item.date ).update(sold=F('sold') - 1) order.status = 'cancelled' order.save()参数说明：deadline是超时阈值，15 分钟是行业常见值，可按酒店要求调整。释放库存用sold - 1，注意要防止重复释放，所以订单状态判断和释放必须在同一事务里。更稳的做法是用消息队列的延迟消息，但中小项目用定时任务扫描足够，扫描间隔建议 1 分钟。
4.3 支付回调与订单状态机
订单状态不能随便改，要有明确的状态机：待支付 → 已支付 → 已确认 → 已入住 → 已完成，以及待支付 → 已取消、已支付 → 已退款。支付回调是外部触发的，必须验签、幂等，且只允许从“待支付”转到“已支付”。
# 支付回调处理（示意） def handle_pay_callback(payload, sign): if not verify_sign(payload, sign): return fail("签名错误") order = Order.objects.select_for_update().get( order_no=payload['out_trade_no'] ) if order.status != 'pending': return success() # 幂等：已处理过直接返回成功 order.status = 'paid' order.paid_at = timezone.now() order.save() return success()逻辑说明：select_for_update防止回调并发重复处理；状态判断保证幂等，重复回调直接返回成功，避免支付平台反复重试。参数上out_trade_no是商户订单号，必须和下单时一致。注意回调接口不要做耗时操作，确认订单、发短信这类动作丢给异步任务。
5. 避坑与排查：多酒店预订系统最容易翻车的 5 个点
5.1 房态显示有房，下单却提示售罄
现象：列表页显示剩余 3 间，点进去下单失败。原因通常是列表页查的是缓存或预计算值，下单查的是实时库存，两者不同步。解决：列表页的剩余量也走同一张RoomInventory表，或者缓存过期时间设短（如 10 秒），并在下单失败时给前端明确提示“房量已变化，请刷新”。
5.2 跨天订单只扣了第一天
现象：用户订 6 月 1 日到 3 日，结果只扣了 1 日的库存，2 日还能被订。原因是扣减逻辑只处理了入住日，没循环到离店前一天。解决：跨天订单必须逐天扣减，循环范围是[checkin, checkout)，离店日不占房。这个边界我踩过，血泪经验是写单元测试专门覆盖“住 1 晚”和“住 3 晚”两种情况。
5.3 小程序登录态过期后接口全部 401
现象：用户在小程序里停留久了，再操作提示未登录。原因是小程序session_key会过期，但前端没做静默重新登录。解决：接口返回特定错误码时，前端自动调wx.login重新换 token 并重试原请求，而不是直接弹登录页。注意重试要限制次数，避免死循环。
5.4 多酒店越权：A 店管理员看到 B 店订单
现象：后台列表里混入了其他酒店的订单。原因是某个查询忘了加hotel_id过滤。解决：把租户过滤收敛到 manager 或中间件，禁止业务代码裸写Order.objects.all()。上线前专门写一个越权测试用例，用 A 店账号请求 B 店订单详情，必须返回 403。
5.5 支付回调重复触发导致重复确认
现象：同一笔订单被确认多次，发了多条短信。原因是支付平台会重试回调，而处理逻辑没有幂等。解决：回调入口先查订单状态，非“待支付”直接返回成功；同时用select_for_update锁行，防止并发。短信这类副作用放到异步任务里，并给任务加去重键。
6. 进阶：用渠道价和房量日历把多酒店系统做扎实
把基础预订跑通只是及格线，真正拉开差距的是渠道价和房量日历。多酒店通常要对接 OTA、协议客户、前台散客，同一房型不同渠道价格不同，还可能有渠道专属房量。我的做法是在RoomType和RoomInventory之间加一层“价格计划”（rate plan），每个计划绑定渠道和价格策略。
class RatePlan(models.Model): hotel = models.ForeignKey(Hotel, on_delete=models.CASCADE) room_type = models.ForeignKey(RoomType, on_delete=models.CASCADE) channel = models.CharField(max_length=20) # ota / direct / corp price_offset = models.DecimalField(max_digits=8, decimal_places=2, default=0) # 最终价 = room_type.base_price + price_offset参数说明：channel标识渠道，price_offset是在基础价上的加减，正数加价、负数折扣。查询时按渠道取对应计划，没有计划就回落到基础价。这样加一个新渠道不用改表结构，只加一行配置。
房量日历是给前台的运营工具，按房型展示未来 30 天的total、sold、remain，支持手动关房和改价。实现上直接查RoomInventory，按日期分组返回。注意关房不是把total改成 0，而是加一个closed标记，否则历史订单对不上。
# 房量日历查询 def room_calendar(room_type_id, start, days=30): end = start + timedelta(days=days) rows = RoomInventory.objects.filter( room_type_id=room_type_id, date__gte=start, date__lt=end ).order_by('date') return [{ 'date': r.date, 'total': r.total, 'sold': r.sold, 'remain': r.total - r.sold } for r in rows]验证方法：造一批测试订单，覆盖平日、周末、跨天、超时释放，然后核对sold是否等于有效订单占用的房量。我习惯在测试环境跑一个对账脚本，把订单表和库存表逐日比对，差一行都要查清楚。这个习惯帮我提前发现过好几次跨天扣减的边界 bug。
最后说个我自己的教训：多酒店系统最怕的不是技术难，而是“先跑起来再说”的心态。数据模型和隔离逻辑一旦将就，后面每加一个门店都是还债。宁可前期多花两天把租户过滤和房态扣减做扎实，也别等上线后天天救火。希望帮到你。
本文还有配套的精品资源，点击获取
