简介这是一套面向酒店行业开发者与中小连锁酒店经营者的多酒店预订管理系统源码覆盖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_length100) city models.CharField(max_length50) status models.SmallIntegerField(default1) # 1营业 0停用 class RoomType(models.Model): hotel models.ForeignKey(Hotel, on_deletemodels.CASCADE) name models.CharField(max_length80) # 大床房/双床房 base_price models.DecimalField(max_digits10, decimal_places2) total_rooms models.IntegerField() # 该房型总房量 class RoomInventory(models.Model): 按天存房态是并发扣减的核心表 hotel models.ForeignKey(Hotel, on_deletemodels.CASCADE) room_type models.ForeignKey(RoomType, on_deletemodels.CASCADE) date models.DateField() total models.IntegerField() # 当日总房量 sold models.IntegerField(default0) # 已售 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(days90): today date.today() records [] for rt in RoomType.objects.select_related(hotel).all(): for i in range(days): records.append(RoomInventory( hotelrt.hotel, room_typert, datetoday timedelta(daysi), totalrt.total_rooms, sold0 )) RoomInventory.objects.bulk_create(records, ignore_conflictsTrue)扣减时不要用 Python 层的save()直接用数据库原子更新# 下单扣库存带条件的原子更新返回受影响行数 updated RoomInventory.objects.filter( room_type_idrt_id, datecheckin_date, sold__ltF(total) ).update(soldF(sold) 1) if updated 0: raise StockError(该日期房型已售罄)参数说明sold__ltF(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换openidH5 在微信里要用公众号授权出了微信又要账号密码APP 有自己的本地存储和推送。接口层如果按端硬编码分支很快就会变成 if-else 地狱。我的做法是接口只认“渠道标识”把差异收敛到登录和支付两个适配层。业务接口查房、下单、订单详情三端完全共用请求头带X-Client: app|h5|mp后端据此决定返回的支付参数格式。维度APPH5小程序登录态本地 tokenCookie / tokencode 换 session支付原生 SDK公众号 JSAPI小程序支付页面栈原生路由浏览器历史小程序路由缓存本地数据库localStorageStorage 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_length64, uniqueTrue) hotel models.ForeignKey(Hotel, on_deletemodels.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(openidopenid) 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(daysi) inv RoomInventory.objects.select_for_update().get( room_type_idrt_id, dated ) 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(minutes15) orders Order.objects.filter( statuspending, created_at__ltdeadline ) for order in orders: with transaction.atomic(): # 释放逐日库存 for item in order.items.all(): RoomInventory.objects.filter( room_type_iditem.room_type_id, dateitem.date ).update(soldF(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_nopayload[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_deletemodels.CASCADE) room_type models.ForeignKey(RoomType, on_deletemodels.CASCADE) channel models.CharField(max_length20) # ota / direct / corp price_offset models.DecimalField(max_digits8, decimal_places2, default0) # 最终价 room_type.base_price price_offset参数说明channel标识渠道price_offset是在基础价上的加减正数加价、负数折扣。查询时按渠道取对应计划没有计划就回落到基础价。这样加一个新渠道不用改表结构只加一行配置。房量日历是给前台的运营工具按房型展示未来 30 天的total、sold、remain支持手动关房和改价。实现上直接查RoomInventory按日期分组返回。注意关房不是把total改成 0而是加一个closed标记否则历史订单对不上。# 房量日历查询 def room_calendar(room_type_id, start, days30): end start timedelta(daysdays) rows RoomInventory.objects.filter( room_type_idroom_type_id, date__gtestart, date__ltend ).order_by(date) return [{ date: r.date, total: r.total, sold: r.sold, remain: r.total - r.sold } for r in rows]验证方法造一批测试订单覆盖平日、周末、跨天、超时释放然后核对sold是否等于有效订单占用的房量。我习惯在测试环境跑一个对账脚本把订单表和库存表逐日比对差一行都要查清楚。这个习惯帮我提前发现过好几次跨天扣减的边界 bug。最后说个我自己的教训多酒店系统最怕的不是技术难而是“先跑起来再说”的心态。数据模型和隔离逻辑一旦将就后面每加一个门店都是还债。宁可前期多花两天把租户过滤和房态扣减做扎实也别等上线后天天救火。希望帮到你。本文还有配套的精品资源点击获取