简介这是一套开箱即用的酒店管理系统包含后台管理、官方网站与微信小程序三大版块面向酒店信息化项目开发者、全栈学习者可快速解决实时房间动态、订单管理、订餐管理以及微信支付/退款等核心业务需求。整套工程共1477个文件以js/ts源码、wxss/wxml小程序样式与页面结构、json配置为主附带jpg/png图片、sql数据库脚本、字体和项目配置文件整体为51.88MB的zip压缩包前后端逻辑与目录结构清晰便于直接部署、二次开发和学习。目前已有59人浏览学习尤其适合作为计算机类课程设计或商用系统原型参考。从中可掌握一套完整的前后台分离架构、小程序下单与订餐流程、实时推送及支付退款接口的实现思路并可在现成功能模块上快速扩展大幅缩短从零搭建系统的时间整体设计兼顾教学演示与实际落地值得深入研读。1. 为什么说开箱即用三大端的架构分工与技术选型做酒店管理系统最怕什么我见过太多项目一上来就铺开做十几个模块结果前台、客房、餐饮、财务拧成一团开发到一半互相打架。这个标题里提到的三大版块后台、网站、微信小程序其实是三层完全不同的东西把它们拆清楚项目就成功了一半。先说我的理解后台是给酒店员工用的操作系统网站是给潜在客人看的门面微信小程序是给住店客人用的随身工具。三者服务的人群不同、使用场景不同、技术侧重点也完全不同。后台要的是效率和数据准确性网站要的是展示和转化小程序要的是轻量、快捷、实时。我最终定下来的技术选型是这样的后台用 Vue 3 Element Plus 搭单页应用配合 Spring Boot 做接口层官网走 WordPress 加自定义主题因为内容更新频繁运营人员自己就能维护不会每次改个房型图片都要找开发小程序端用 uni-app 开发一套代码同时兼容微信小程序和未来可能要出的支付宝小程序不用重复写。数据库用的是 MySQL 加 Redis 的组合MySQL 存业务数据Redis 做实时房间状态、在线用户会话、短信验证码这些需要高速读写的场景。特别要说的是项目里所有涉及实时的功能底层基本都依赖 Redis 的键过期通知和发布订阅机制这套组合足够轻量又不会像引入消息队列那样给团队增加不必要的运维负担。开箱即用这四个字我理解不是功能堆得越全越好而是三个端各司其职、数据结构清晰、部署起来不折腾。后面每一块我展开讲讲具体怎么做的。2. 先啃硬骨头实时房间动态的数据流设计2.1 房间状态是怎么从静态台账变成动态数据的酒店的房间状态看起来简单无非就是干净/脏房/维修/入住/空房但你真做进系统里就会发现它其实是整个酒店的业务中枢。前台改一个状态客房部要看到保洁要收到任务小程序端要同步展示官网的预订按钮也要跟着变。任何一端的状态滞后都会引发客诉。我采用的方案是状态机加事件广播。每一个房间有一个当前状态字段同时维护一张状态变更流水表。任何状态变更操作都必须通过统一的服务接口完成不允许业务方直接改数据库字段。这样做的好处是所有变更都有迹可循出了纠纷可以回溯是谁在什么时间把房间从空房改成了维修。具体的数据流是这样的前台在小程序后台或PC后台执行办理入住操作后端服务更新房间状态的同时往 Redis 的房间状态频道发布一条消息消息体里带着房间号、新状态、操作人、时间戳。所有订阅了这个频道的服务端实例不管你有几个节点都会收到这条消息然后各自推送给自己在线的客户端。如果推送失败或者客户端离线Redis 里保留的最近状态就是兜底方案等客户端重新上线后拉取一次全量状态即可。2.2 轮询、WebSocket 还是消息推送不同场景的取舍实时信息推送这块很多教程一到讲实现就只提 WebSocket好像不用 WebSocket 就不配叫实时。但实际做项目不是炫技要看场景选方案。我在这个系统里同时用了三种方式各有各的用途。PC 后台的实时房间动态用的是 WebSocket因为后台操作频繁而且房间状态看板需要秒级刷新用轮询会造成大量无效请求。官网端用的是 Server-Sent Events因为官网只做单向展示客人看房型、看剩余房量不需要往服务端推数据SSE 更轻量断线自动重连也是浏览器原生支持的写起来比 WebSocket 简洁得多。小程序端就比较特殊了。微信小程序在前台时 WebSocket 容易被系统挂起不能依赖长连接做实时更新。我的做法是小程序进入页面时先拉一次全量数据然后根据用户停留在页面的状态决定用不用轮询。比如房态列表页用户停留期间每 10 秒拉一次增量如果是订单详情页靠订阅消息推送订单状态变更通知用户从待支付变成已确认时微信会主动推一条模板消息。这里有个很容易踩的坑不要对小程序端所有页面都做轮询。微信对小程序后台接口的调用频率虽然没有硬性限制但频繁请求会显著增加用户手机耗电和服务器压力。我的经验是只有真正需要实时性的页面才做轮询其他页面用下拉刷新 进入页面拉取就行。2.3 房间状态并发修改的防冲突处理房间状态最容易出的问题就是并发冲突。举个例子客人 A 在前台办理入住同一时刻客人 B 在官网下了同一间房的订单这俩操作如果同时发生系统怎么处理我最初的实现是在修改状态的接口里加一个乐观锁版本号更新前检查版本号是否一致不一致就报错重试。但实际运行中发现在高并发场景下这会导致大量请求重试体验并不好。后来改成了 Redis 分布式锁操作房间状态前先尝试获取房间维度的锁拿到锁才能执行状态变更执行完释放锁。锁的超时时间设置为 3 秒正常情况下一个状态变更操作几十毫秒就完成了几乎不会触发超时。如果某个房间操作特别频繁比如办理入住的客人正在付押金可以适当增大超时时间但要警惕死锁——锁的 key 必须带房间号释放锁的时候要校验是不是自己加的锁防止线程 A 释放了线程 B 的锁。这里的经验总结是实时系统不光要看得快还要保证改得对。速度只是用户体验的一部分数据一致性才是系统活命的根本。3. 订单管理和订餐管理的联动逻辑3.1 订单状态机设计从预订到入住的完整流转订单管理是酒店管理的核心模块但也是最容易做乱的模块。我在这个系统里定义了这样一套订单状态机已创建待支付→ 已支付预订成功→ 已入住 → 已退房 → 已完成另有已取消、已退款、已超时等辅助状态。这套状态机里最需要注意的是已支付和已入住之间的边界。线上支付成功后订单变成已支付但客人可能还没到店此时房间仍然可以卖给其他人吗不行因为已经锁房了。那么一个已支付未入住的订单占着的房间如果客人一直不来什么时候解锁我的方案是设置一个入住截止时间通常是当天 23:59超过时间自动释放房间并触发退款流程。这个设计在最初版本里是没有的被运营吐槽了很久才加上。后来发现酒店管理系统的所谓订单管理核心其实不是记录订单而是管理房间的时间资源。每间房就是一个资源池订单就是这个资源在某段时间内的占用凭证。想清楚这一点很多边界情况就迎刃而解了。订餐管理相对独立但也有自己的状态流点餐 → 已接单后厨确认→ 配送中由服务员送餐→ 已送达 → 已完成。订餐和房态有一个交集点就是送餐到房间的场景这时候需要根据房间号关联到住客订单。所以订餐表里我保存了 room_id 字段这样餐厅的订单和前台系统就打通了客人催单时前台可以直接看到这个房间的餐到哪一步了。3.2 订餐模块的菜品库存扣减订餐模块还有一个被很多人忽视的点菜品库存。酒店餐厅的食材是当天采购的库存量有限。如果客人在小程序下单了一份每日特供菜但后厨发现食材已经用完了怎么办我的做法是菜品表里维护一个每日库存字段每天早上自动重置为当日备货量。客人下单时先扣减库存扣减成功才能生成订单。但这里有个细节——从下单到后厨确认之间存在时间差如果客人支付了但后厨没确认食材不足需要有个异常处理流程。我的解决方案是增加一个退单未确认状态后厨可以一键取消并通知客人系统自动原路退款。这种设计看似增加了很多复杂度但真正运营起来会发现比后厨收到订单才发现做不了再手动打电话沟通要高效得多客人体验也好。4. 微信小程序端的功能与操作要点4.1 小程序端要做的功能取舍微信小程序端的定位是客人的随身工具我最终只保留了四类功能查房态、订房、订餐、查订单。为什么不做成后台的移动版因为手机屏幕太小做不了复杂的数据录入硬做只会让员工端着手机骂骂咧咧。但也有例外。我给酒店前台做了一个独立的小程序入口不是客人端用来处理一些移动场景下的紧急操作比如客人站在走廊里要求换房服务员不用跑回前台掏出手机就能查哪间房空闲、哪间房是脏房。这个入口的界面设计得非常克制只有房态浏览和换房申请两个功能审批在 PC 后台完成。小程序端最让我头疼的是国际化素材管理和图片资源。房型照片在不同设备上的展示效果差别挺大苹果和安卓对图片的渲染也不太一样。我的经验是小程序内的图片要用 WebP 格式压缩率高且各平台兼容性好。图片上传到对象存储后后端根据用户设备返回不同尺寸的压缩图列表页用小图详情页用中图原图只在管理后台查看。4.2 微信支付 v3 对接的几个注意事项微信支付是小程序端绕不开的坎。我接的是微信支付 API v3和老的 v2 相比最大的变化是加解密方式从 MD5 签名换成了 RSA 证书而且多了个平台证书的概念。v3 对接的几个要点第一商户私钥和商户证书是两个不同的东西私钥是商户自己生成的用来签名请求证书是微信下发的用来做身份认证第二回调通知的报文是 AES-256-GCM 加密的需要用 APIv3 密钥解密而不是直接用私钥解密第三退款接口需要用到微信的平台证书用来验证微信返回的响应确实是微信发的这个平台证书会定期轮换要做好自动更新机制。实际操作中我踩过一个坑微信支付回调通知的幂等处理。因为网络原因微信可能会重复发送回调如果后端不做幂等控制同一个支付成功通知可能导致订单状态连续更新两次甚至触发两次发货业务。我的方案是在回调处理接口里用 Redis SETNX 加一个支付单号的去重标记重复通知直接丢弃。4.3 小程序端常见的前端问题键盘遮挡、软键盘和视频组件受小程序违规支付功能暂时无法使用这个热搜词启发我顺便聊两个小程序开发中特别常见的坑。第一个是手机软键盘遮挡输入框。这个问题在订单备注、地址填写这些页面尤其明显。我在 uni-app 里用的是adjust-position属性加页面滚动补偿键盘弹出时监听到keyboardheightchange事件把当前聚焦的输入框滚动到可视区域。有个小细节不同手机的键盘弹出动画时长不一样滚动补偿不能写死一个动画时长否则真机上会有明显的跳跃感我用的是获取实际动画时长后再执行滚动的方案。第二个是 swiper 组件里嵌套 video 组件导致的 iOS 全屏播放错位。这个问题在预订页面展示房型视频时非常容易出现。iOS 上 video 进入全屏后swiper 的transform属性没有失效导致全屏视频被 c、内容偏移、或是黑屏。解决思路是监听视频的fullscreenchange事件进入全屏时给 swiper 加一个display: none的类名退出全屏再恢复。虽然写法有点粗暴但实测是有效的而且不会影响交互。5. 实时信息推送的小程序端链路5.1 微信订阅消息的机制设计与踩坑记录前面提到小程序端不能依赖 WebSocket 做实时推送那实时信息推送在小程序端是怎么实现的答案是微信订阅消息。微信订阅消息有一次性订阅和长期订阅两种。一次性订阅要求用户每次点击授权按钮才能收到一条消息长期订阅需要类目审核通过才能申请。酒店行业能申请到长期订阅的类目很少所以我的方案是引导用户做一次性订阅每次触发购买、退房等动作时弹窗请求订阅授权。这里有一个值得注意的优化技巧订阅授权可以一次性订阅多条。比如客人下单时我可以请求订阅订单支付成功通知和入住提醒两条消息这样客人只需要点一次授权后面两个环节都会收到通知。这样主动获取多个订阅 token 的技巧能把授权摩擦降到最低。实际操作中还有个大坑用户如果点击了总是保持以上选择订阅消息的授权弹窗就不会再出现你只能在用户每次操作的时候判断是否有剩余订阅额度。如果额度用完需要弹出引导页让用户手动去设置里开启服务通知否则后续的支付、订单状态变化都无法触达用户。5.2 推送链路从后端到微信服务器的完整流转订单状态变更时的推送链路是这样的订单服务更新状态后发送一条 RabbitMQ 消息到通知服务通知服务根据推送规则组装微信模板消息调用微信的接口发送。如果调用失败比如用户取消授权、access_token 过期写入失败日志表配合一个定时任务定期重试。这个链路里有个容易被忽视的性能点微信 access_token 的有效期是 7200 秒而且每日获取次数有限制千万不能每一请求都去获取 token。我的做法是用 Redis 存 token快过期时自动刷新加一个分布式锁防止多个实例同时刷新导致 token 失效。每次推送前我会检查一下用户是否处于微信小程序在线状态如果在线就优先走 WebSocket 通道不在线才走订阅消息通道。这样做的原因是订阅消息次数有限能省则省也是一种精细化运营的思路。6. 官网端的定位与落地细节以及容易被忽略的上线细节6.1 官网为什么要用 WordPress运营方的维护成本才是关键官网最终选择 WordPress 有很多现实考虑。用 Vue 或 React 开发官网视觉效果更好但后期运营人员改房型图片、写促销文案、加新建酒店的分店信息全都得找开发一来一回的沟通成本早就超过了技术选型省下的那点页面加载时间。WordPress 我用了自定义文章类型来管理房型和促销信息。房型的各种属性面积、床型、设施通过 ACF 插件添加自定义字段前端用 PHP 模板渲染缓存走对象缓存加 Redis。为了和前台系统的数据打通比如官网展示的实时剩余房量、实时房价官网通过后端提供的 API 获取数据设置 1 分钟的缓存时间。这个方案最大的优势是官网内容和业务数据解耦。内容运营独立维护页面只有房量和价格是从业务系统实时拉取的双方互不干扰。官网的改版也不会影响到订单流程。6.2 快照与回滚上线前必须做好的数据备份说到上线很多人以为代码上线就是把新版本扔上服务器。但酒店管理系统这种全天候在运营的系统任何一次上线失误都可能直接影响客人办入住。我要求团队每次发布前必须做三件事第一备份 MySQL 全量数据和 Redis 的 RDB 快照第二观察接口的慢日志如果某个接口的 p99 延迟突然超过 500 毫秒立刻回滚第三上线脚本要支持一键回滚即代码发布后发现重大问题能 30 秒内把上一个稳定的版本重新拉起来。前阵子遇到过一个 case新版本上线后小程序端订单列表接口偶发超时。因为订单列表接口在旧版本里只查了订单表新版本加了 JOIN 操作同时查订单表和房间表数据量一大索引没用对查询就慢了。当时如果没有备份和老版本镜像用于回滚估计要折腾一下午才能定位问题。从那以后我对所有看起来很小的 SQL 变更都多了一个心眼先在测试环境塞入和生产同等数量级的数据再验证执行计划。7. 上线前后容易忽略的细节账号安全、数据备份、性能监控最后聊几个很多项目收尾时才发现的坑。第一后台账号安全。WordPress 后台和 PC 后台的管理员账号一定不要用admin这种默认用户名。我见过一个酒店项目的 WordPress 后台被爆破管理员莫名其妙多出一个账号挂了恶意插件。后来我在服务器层面加了访问白名单非酒店内网 IP 访问后台会被 WAF 规则拦截。后台登录接口加上验证码和登录失败次数限制失败 5 次锁定 15 分钟这个策略能挡掉绝大多数暴力破解。第二数据备份演练。做好备份不等于能恢复要定期演练从备份中恢复数据库到测试环境的流程。我有一次临时要恢复数据发现备份脚本里的 S3 密钥过期了备份早就断了。后来我加了一个备份完整性检查任务每天检查备份文件的大小和生成时间异常时通过钉钉机器人告警。第三性能监控。前后端都要埋点前端统计页面加载时间和接口调用耗时后端统计每个接口的调用量、耗时、错误率。我用的方案是开源的 Prometheus 加 Grafana数据通过自定义埋点上报。上线之后不需要天天盯着控制台但报警规则要设好——比如订单接口错误率超过 2% 就触发告警工作时间直接打电话。酒店的实时房间动态也好订单管理和订餐联动也好最终考验的是整个系统链路的协作能力。没有哪个模块是孤立存在的也没有哪个细节可以靠运气过关。这个项目做完后我自己最大的体会就是所谓的开箱即用无非是把该想的边界情况都提前想了一遍把该做的保护措施都提前加上了。后续如果要往多门店方向扩展可以把现有的 Redis 通道升级成消息队列把状态机抽成独立的配置中心架构上再做一次分布式事务的加固但目前这套方案在三端联动的中小规模酒店场景里已经相当顶用了。本文还有配套的精品资源点击获取