做酒店管理系统我最早其实是拿ThinkPHP硬写的单页应用前端全靠jQuery拼改一个页面动全身上线之后被老板催着改需求差点没把人逼疯。后来换成了php uniapp的组合前端用小程序同时兼顾微信端后台继续用PHP出接口才终于把开发和维护的节奏理顺。这篇就是把当时踩过的坑、总结的设计思路和可以直接抄的代码思路整理出来给正在做课程设计、毕业设计或者想给自家小酒店做一套管理系统的朋友参考。这个小程序能干什么一句话说清楚面向住客的微信小程序负责订房、查房、退房PHP后端负责管房态、算账、出报表数据库维护所有房间和订单数据。适合谁看要么是学生党要做毕设要么是想低成本给民宿、快捷酒店搭一套轻量系统的开发者。下面前面讲整体拆解和数据库设计中间给核心接口和前端实现最后是真正上线时必须面对的坑。1. 项目整体拆解与落地思路1.1 先别急着写代码把需求按场景切开我做这个项目第一件事不是装环境而是先把“有哪些人要用”列清楚。酒店管理系统最典型的三类角色是住客、前台/管理员、老板。住客在微信小程序里看房、下单、查订单前台在后台确认入住、办理退房、处理打扫状态老板关心的是每天卖了几间房、收了多少钱所以要的是统计报表。按照这个逻辑系统就把功能拆成了三个主要模块小程序端、PHP接口端、数据库端。小程序端负责展示和操作入口接口端负责业务逻辑和数据处理数据库负责最终落盘。每一层只做自己的事后续要加功能比如加一个房间售卖小商城也不会把代码搅成一锅粥。给需求分层的时候有一个容易忽略的点**民宿类的小系统房间数一般在20间以内并发量根本不需要考虑分布式但“状态一致”必须一开始就设计好。**最常见的问题是同一间房被两个小程序用户同时选中结果都下单成功了后面只能靠人工取消。这个问题后面会专门讲。1.2 为什么选PHP uniapp而不是Java Android或纯Web选PHP当后端主要原因是快。用户注册、订单增删改查、统计报表这些都是典型CRUD加一点运算逻辑PHP一个文件就能出一个接口开发效率确实高。特别是配合ThinkPHP或者Laravel这种框架路由、参数校验、ORM模型都现成了不用自己造轮子。做毕设也好、做小系统也罢用PHP能把大量时间省在业务实现上而不是搭地基。选uniapp则是为了“一套代码多端运行”。同一套页面编译出来能跑微信小程序也能跑H5和安卓App。我实际用下来90%的代码是共享的只有平台差异化的小功能需要单独做条件编译。对个人开发者来说这比同时维护小程序原生的一套加上Vue Web一套要划算得多。还有一个关键点是生态。微信小程序端的UI组件库uView Plus、uv-ui这类都是基于uni-app的现成的表单、日期选择、弹窗都不需要自己写。我最早用原生小程序写过一个日历房态组件写了三天换到uniapp用插件市场现成的组件半天就接完了。做通用型系统会借力比会造轮子更实际。1.3 整体数据流和目录结构设计我的目录结构是这么拆的后端ThinkPHP项目application/api/controller/放对接小程序的控制器application/api/model/放数据模型输出统一JSON格式。前端uniapp项目pages/index/放小程序首页pages/room/放房间详情和预订pages/order/放订单列表和管理pages/user/放登录和个人中心。数据库脚本单独放一个SQL文件方便别人部署时直接跑。接口数据流可以简单理解为小程序发起请求 → PHP路由接受参数 → 模型查数据库 → 业务层处理 → 返回JSON → 小程序渲染页面。“接口返回格式统一”这件事从一开始就要定死。我的格式是{ code: 200, msg: success, data: [] }code为200代表成功4xx是客户端传参有问题5xx是服务端异常。小程序端收到非200就直接弹msg避免每个页面都写一套错误处理。2. 数据库设计与核心表结构2.1 房间、房型、订单、用户四张核心表怎么设计只要是一套业务系统数据库设计就是天花板。表没设计好后面代码写得再漂亮也会卡在查询上。酒店类系统核心表就是四张房型表、房间表、订单表、用户表再加一张可选的房间清扫记录表。房型表不直接面向房间而是面向“出售的产品”比如大床房、双床房、套房。一张房型对应多个物理房间。字段我就放得比较简单id、name、price、area、bed_type、max_people、pic、description。价格直接放这张表好处是前台展示房型价格只用查一次。房间表才是实实在在的房间资源每个房间一行。字段是id、room_type_id、room_no、floor、status。其中status我最开始是用字符串存的available/occupied/cleaning后来发现还是用数字更好维护0空闲、1入住中、2待打扫、3维修。为什么用数字因为前端要判断状态图标后端要做统计数字范围可控不容易拼错。订单表信息量最大需要考虑好。核心字段大致包括id、order_sn订单号房间下单的时候要生成唯一订单号user_id下住客IDroom_id实际入住的物理房间IDroom_type_id下单时锁定的房型IDcheck_in_date、check_out_date入住和退房日期nights入住晚数total_amount订单总金额status状态机用数字。0待支付、1已支付待入住、2已入住、3已退房、4已取消、5已退款用户表除了常规的手机号、昵称、头像之外我会额外存一个openid字段用来关联微信登录。openid是微信小程序里识别用户的唯一凭证同一个用户在不同的小程序里openid不一样所以在哪家小程序下单就用哪个小程序授权得到的openid。2.2 最隐蔽的坑房价日历和预订冲突这套设计里最隐蔽的坑就是“一笔订单跨多个日期”造成的房态判断。很多人第一版设计房价时只想着房间表当前状态结果入住日期和退房日期的房间库存没法判断。我的做法是加一张“房态日历表”room_calendar字段是id、room_id、date、is_booked。当一个订单支付成功后就把这笔订单覆盖的所有日期在日历表里全部标成已预订。这样用户查询的时候只要查某一天某个房间的is_booked状态就能判断能不能订。有人会问为什么不直接看订单表里有没有重叠日期看订单表也可以但SQL写起来要处理多个日期条件而且一旦加了取消/退款逻辑查询条件会复杂很多。用日历表相当于把“房间在某天有没有被占”这个高频问题做了一个缓存查询性能更好代码也更直白。生成日历数据的时候注意一个细节**订单覆盖的是入住日到退房日的前一天。**比如入住10月1日退房10月3日实际占用的应该是1号和2号两天3号可以继续卖给新的住客。我见过有人在这个地方把退房当天也算作占用导致明明有空房却订不进去等退房当天客人还没走新客人又在门口了造成线下冲突。3. 后端接口设计与核心实现3.1 接口清单列全了再动手写动手写代码前我建议先把接口清单列出来前后端根据这个来对齐效率会高很多。我的接口清单大致是这样模块接口说明用户POST /api/user/login微信登录用code换openid返回token用户GET /api/user/info获取个人资料和订单数量房型GET /api/room/types获取房型列表小程序首页展示房间GET /api/room/available根据日期筛选可订房间订单POST /api/order/create创建订单抢房时的核心接口订单GET /api/order/list当前用户的订单列表订单POST /api/order/cancel取消订单释放房态日历订单POST /api/order/pay模拟支付或真实微信支付后台POST /api/admin/login管理员登录后台PUT /api/admin/room/status修改房间状态接口清单的意义在于让前后端都能看到全貌不会出现前端等着后端接口后端以为前端不需要这种尴尬。实际开发中我把这套接口定义在文档里前端按文档模拟数据就能并行开发。3.2 登录鉴权小程序登录不是简单拿个用户名密码小程序端的登录我推荐用“微信授权登录 后端签发token”的方式而不是自己写一套用户名密码注册。原因是微信小程序天然有身份体系用户点一下“微信授权”就能完成身份识别注册表单的门槛一降低订单转化率会明显提升。整个流程是这样的小程序端调用uni.login()拿到一个临时code这个code有效期只有几分钟把它传给后端后端拿着code加上小程序的AppID和AppSecret去微信的jscode2session接口换openid和session_key拿到openid后去用户表查有没有这个人没有就自动注册有就更新登录时间最后后端用openid签发一个token返回给小程序后续请求都带上这个token识别身份。token的生成我用的是简单可复现的方式// 生成token并缓存这里不做复杂JWT直接用hash function createToken($userId) { $token md5($userId . time() . uniqid()); // 存到redis或者数据库session表设置7天过期 return $token; }这里说一句我没用JWT而是用缓存token主要考虑到是小型系统做成token存Redis后端要在鉴权时查一下实现简单踢人也方便。如果追求无状态APIJWT也是好选择但刷新和吊销机制会复杂一点。注意AppSecret绝对不能存到小程序前端代码里因为小程序代码包可以被人扒开看曾经就有开发者把AppSecret写在前端被同行拿去刷接口损失惨重。AppSecret只存在于PHP后端环境变量或配置文件中。3.3 预订接口如何防止“多人抢同一间房”这是整个系统最关键的业务逻辑。正常逻辑是这样用户选好入住日期和退房日期后前端调/api/room/available把可订房间列出来用户看了房型点了“立即预订”后端要做的第一件事不是直接写订单而是“校验房态”。我的实现思路是加了一个“预占”环节用数据库事务把创建订单和锁定房间串在一起public function createOrder($userId, $roomId, $checkIn, $checkOut) { $res Db::transaction(function () use ($userId, $roomId, $checkIn, $checkOut) { // 1. 查询该房间在入住日期到退房日期间是否已被占用 $dates getDateRange($checkIn, $checkOut); $booked Db::name(room_calendar) -where(room_id, $roomId) -where(date, in, $dates) -where(is_booked, 1) -count(); if ($booked 0) { throw new \Exception(当前房间已被预订请重新选择); } // 2. 锁定这些日期的房态 Db::name(room_calendar) -where(room_id, $roomId) -where(date, in, $dates) -update([is_booked 1]); // 3. 生成订单 $orderId Db::name(order)-insertGetId([ order_sn generateOrderSn(), user_id $userId, room_id $roomId, check_in_date $checkIn, check_out_date $checkOut, nights count($dates) - 1, total_amount $this-calcAmount($roomId, $dates), status 1 ]); // 4. 清空之前可能残留的缓存信息 cache(room_price_ . $roomId, null); return $orderId; }); return $res; }可以看到事务保证了要么房态锁定和订单创建都成功要么一个都没发生。如果不加事务第一步查的时候显示可订但第二步锁房态时发现被别人占了就会产生超卖。还有一个细节用户创建订单后如果一直不支付这些日期就被白白占着影响其他客人下单。所以我会加“待支付订单锁定时限”比如15分钟。超过时限后通过定时任务把未支付订单取消并释放对应的房态日历。3.4 房间价格要不要做动态计算很多毕设级别的系统都是房型表里一个固定价格。但真实酒店场景没那么简单节假日要涨价连住几天可能有折扣不同渠道价格还不同。我在这套系统里给房型表加了一个price_rules字段用JSON存规则比如{ normal_price: 268, holiday_price: 398, holiday_dates: [2025-10-01, 2025-10-02, 2025-10-03], long_stay_discount: 0.9, long_stay_nights: 3 }在算总价的方法里根据入住日期判断是否属于节假日如果入住晚数≥3晚就打9折。实际开发中不用把价格规则做太重能覆盖“节假日调价”和“连住优惠”两种常见运营需求就够了。动态价格是挺常见的加价点毕设答辩时也能成为一个亮点。4. 前端小程序页面与交互实现4.1 uniapp页面架构和小程序端适配uniapp的项目结构跟Vue项目几乎一样页面写在pages目录下路由由pages.json自动生成。我做的是四个底部Tab页面首页房间预览、订单订单列表、消息通知、我的个人中心。另外有房型详情页、订单确认页、支付结果页。这里有个uniapp和小程序原生开发最大的差异**uniapp里数据绑定用的是Vue语法页面不能用小程序原生的setData。**比如显示房间列表数据放在data里后用v-for就能渲染view classroom-card v-foritem in roomList :keyitem.id clickgoDetail(item) image :srcitem.pic modeaspectFill/image view classroom-name{{ item.name }}/view view classroom-price¥{{ item.price }}/晚/view /viewVue语法对小程序的差异主要体现在生命周期和平台API上。比如页面加载时获取数据uniapp是小程序风格的onLoad不是Vue的created。这个很容易踩坑我第一次写的时候就习惯性用了mounted结果数据一直没加载出来。4.2 房间列表页按日期过滤可订房型房间列表页是用户进入小程序后看到的核心页面也是转化率的关键。我建议不用一上来就把所有房间都展示出来而是让用户先选择入住日期和退房日期再根据后台房态日历返回可订房型。这样子可以提前筛掉没房的日期用户体验大幅提升。页面逻辑是这样的顶部两个日期选择器默认是今天入住、明天退房用户改变日期后重新请求/api/room/available接口接口返回的数据是每个房型剩余的可订房间数和价格。代码示意async loadRooms() { const res await uni.request({ url: /api/room/available, data: { start: this.checkInDate, end: this.checkOutDate } }); this.roomList res.data.data; }注意一个交互细节选择退房日期时至少要大于入住日期一天否则在后端校验就会报错。前端要在日期选择器的change事件里加判断如果退房日期小于等于入住日期就自动把退房日期改成入住日期加一天并提示用户。这种小细节对用户体验的影响比功能本身还大。4.3 订单确认页金额明细和状态流转展示用户点了房型详情页里的“立即预订”进入订单确认页。订单确认页有几个重点显示房型图片、入住/退房日期、每晚价格、总价选择入住人手机号这里可以直接用当前微信登录用户的信息填写备注比如“需要大床房无烟房”。都填完了再点提交。订单创建成功之后进入待支付状态。这时页面上要立即显示一个倒计时15分钟内未支付自动取消。前端倒计时用setInterval实现每秒减一到0时把订单状态改成已取消页面跳回列表页并提示“订单超时未支付已自动取消”。订单状态流转这个事我在前端专门封装了一个工具函数根据后端返回的status字段渲染对应的操作按钮status 0显示“去支付”按钮status 1显示“入住中”并提示房间号和入住密码status 2显示“退房”按钮status 3显示“已完成”和“评价”按钮这样后端只存状态码前端根据状态码展示不同界面。有人喜欢把前端展示文案直接存在后端其实没必要文案改动会导致前后端版本要同步发布不如前端自己维护文案。4.4 管理后台一个够用的管理页面管理后台我建议单独写一个H5页面不做成小程序。因为管理后台的使用者是酒店前台和老板他们不可能拿手机小屏去录入房间信息、看报表更多是PC上操作。uniapp的H5编译能力这时候又能派上用场同一套代码里用#ifdef H5条件编译区分平台页面布局在H5上用更宽的栅格。管理后台核心页面有哪些房间管理创建编辑房间、修改房型价格、订单管理查看所有订单、确认入住、办理退房、统计报表今日入住率、今日营收、本月营收、清洁管理房间打扫状态切换。这些页面不需要太花哨数据表格加上操作按钮功能齐全即可。做H5管理后台时有个关键点H5端和小程序端的用户体系不同管理员的登录一定要单独做。我给管理员单独建了一张表账号密码登录生成管理员token和住客的token做区分。权限上管理员能看所有订单住客只能看自己的。这块如果混用一套逻辑很容易出现用户A看到用户B订单的低级错误。5. 常见问题与排查技巧实录5.1 小程序请求后端接口的跨域和合法域名问题小程序端请求HTTP接口跟浏览器环境一样有跨域限制吗简单说小程序开发工具里可以关闭合法域名校验但真机预览和线上发布必须配置合法域名。如果后端接口跑在本地真机就访问不了这是新手最常见的报错。我自己碰到的典型场景是开发阶段用的http://localhost:8080/api/开发工具里勾选了“不校验合法域名”一切正常一上线小程序后台配置域名的时候发现没有HTTPS证书只能临时买了一年证书。所以如果打算上线域名和HTTPS证书要提前准备阿里云或腾讯云的免费证书够用。如果只是想本地调试后端PHP需要处理好跨域头header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization, token);还有一点容易忘记小程序端自定义的请求头如果带了Authorization字段后端必须把它放在Access-Control-Allow-Headers里否则OPTIONS预检请求会被拦截。这个问题我排查过半天最后发现是这一个头没写对。5.2 时间日期处理的常见坑PHP里处理跨天入住最经典的坑就是时区问题。默认情况下PHP的date()函数使用服务器时区如果服务器时区不是Asia/Shanghai那么生成订单时间、判断日期都会乱掉。所以PHP文件开头要设置date_default_timezone_set(Asia/Shanghai);前端小程序端也要注意。小程序中的new Date()获取的是本机时间如果用户手机日期被手动改过那前端传回来的日期可能跟真实日期不符。我做了个保险前端在选择日期后不传“当前时间”给后端而是传经过日期选择器格式化后的日期字符串YYYY-MM-DD后端按这个字符串做业务判断不依赖前端时间。这样做的原因是后端只关心用户选的入住日期而不是用户下单一刻的手机时间实际订单支付时间由后端自己记录就避免了时间伪造的问题。5.3 PHP版本迁移到7之后的老坑不少人的毕设代码是老PHP写的比如用mysql_query()这种早就移除的函数。如果系统要跑在PHP 7以上有几个兼容性大坑得注意mysql_*系列函数全部移除必须用mysqli_或PDO。PHP 7不再支持mysql_escape_string()要用mysqli_real_escape_string()或参数绑定。类名和函数名不再区分大小写但这是一个警告级别的切换尽量统一小写。each()循环在PHP 8彻底移除老代码里如果有直接改成foreach。数组字符串偏移量语法$str{0}在PHP 8废弃了改成$str[0]。如果在写学校项目时一开始就用PDO预处理这些坑就一个都踩不到。PDO预处理除了防注入还能让代码在新老PHP版本间平滑迁移这是我在重构老系统过程中最深的体会。5.4 uniapp打包成App和小程序遇到的差异化问题同一个uniapp项目编译到微信小程序、H5、Android App时会有差异最常见的几个第一微信小程序端必须使用uni.request不能用axios。虽然uniapp兼容了部分Web API但小程序的网络请求底层就是wx.requestuniapp已经做了封装直接用uni.request最稳妥。第二App端使用相机、定位、支付这类原生能力如果沿用小程序平台的API会报“xxx is not a function”错误。需要针对App端使用plus对象或者原生插件。比如我的系统里有个扫码办理入住的功能小程序端用uni.scanCodeApp端就得用uni.scanCode也支持但如果涉及蓝牙打印就必须走原生插件。第三H5和App端的跨域限制不同H5受浏览器跨域限制App端不受。这就导致同一个请求在开发工具里跑通了真机App也跑通了但H5发布到另一台服务器时会有跨域报错。处理方案是想清楚前端部署在哪里接口地址用相对路径还是绝对路径。5.5 房态并发冲突的兜底方案前面在接口实现里讲了事务处理但这里再补充一个兜底方案就算后端做了事务在网络极端延迟的情况下仍可能出现用户点完提交没反应、再次点击产生两个订单的情况。我给前端加了“提交锁”变成提交按钮时加一个loading状态在结果返回前禁止再次点击后端同一用户、同一房间、同一入住日期的重复订单也要加唯一索引或逻辑判重。逻辑判重的代码就是在创建订单的表里加一个唯一字段比如order_token前端提交时生成一个唯一的tokenUUID后端在插入前检查这个token是否已被使用。如果重复提交直接返回“please dont submit twice”。这个小改动在真实场景中救过我好几次尤其是用户手机网络差的时候按钮重复点击导致数据错乱处理起来的成本远大于那几行判断代码。6. 实测下来比较顺手的扩展方向系统基础跑通之后如果还有余力我建议往三个方向扩展性价比都比较高。第一个是加入扫码入住和智能门锁联动。客人到店后通过小程序扫描房间里贴的二维码后端校验订单状态是已支付就返回一个临时开门密码。做这个功能需要和智能门锁厂商对接API但是对接方式都是HTTP回调后端PHP实现不难却能让整个系统的“科技感”上一个档次。第二个是接入真实微信支付。我上面用的是模拟支付真实支付需要申请微信支付商户号然后在后端调用微信支付统一下单API拿到支付参数再返回给前端前端用uni.requestPayment唤起支付。流程不复杂麻烦的是微信审核的资质材料企业主体才能申请。第三个是加一个数据统计的可视化看板。后台管理端用Chart.js或者ECharts把每个月的入住率、营收趋势、热门房型做成图表。做这个功能有助于老板做经营决策也让整个系统显得完整。PHP端只需要聚合SQL查一下每日订单数和营收接口返回数据前端画图就行。7. 我个人踩过几次坑之后的体会整个项目做下来我的体会是系统复杂度不在于代码量而在于状态管理。酒店这个业务房态、订单状态、支付状态每一种状态之间都有流转关系一不留神就会出现“房已入住但状态还是待支付”这种逻辑漏洞。所以在动手写第一个接口之前花两天时间把状态流转图画清楚把每个状态之间的转换条件和触发动作列出来后面编码其实就是填空。另一个深刻的体会是别把系统设计得太重。很多毕设同学一开始就想着加权限管理、加消息推送、加日志系统结果主流程还没走通就被这些附加功能拖住了。建议第一版只做核心的“找房-下单-支付-入住-退房”闭环把边界和异常处理做好。跑通以后再加功能会非常顺因为地基是稳的。如果你正在做类似的系统从这套方案里能拿走的首先是数据库设计的思路特别是房态日历表的设计其次是下单接口的事务处理再就是前端按状态渲染按钮的模式。这套组合在酒店、民宿、会议室预订这些场景里都能复用。照着做一套至少能省一个月的试错时间。