很多人接民宿预订系统时习惯打开一套商城源码就开改这是最大的坑。民宿的预订模型跟卖货完全是两码事——它是“日期 × 房间”的二维库存不是简单的 SKU 库存。我最近做的这个项目需求原文写得很直白“Thinkphp和Laravel框架都支持基于小程序的民宿预订系统-web pc 手机端”翻译过来就是用 PHP 技术栈同时撑起微信小程序、Web 门户、PC 管理后台和手机 H5 四个入口并且框架在 ThinkPHP 和 Laravel 之间可以灵活选择。这篇我就把这个项目从选型、数据库建模到多端接口设计、并发锁房的完整思路拆开讲给准备做民宿预订、住宿预订类产品的同行一份可以直接参考的实战记录。1. 先把“web pc 手机端”这几个字拆透民宿系统到底在做什么1.1 三端入口各有各的角色不是同一个页面换个壳标题里反复强调多端说明这个产品从一开始就不是单个后台管理页面而是一个典型的“C 端预订 B 端管理 平台运营”三层结构。我按实际业务把端拆成了这样微信小程序给 C 端客人用的主入口。客人进来搜索城市、看房源列表、查日历价格、下单支付全部在小程序里完成。微信生态的好处是登录省事、支付顺手、取消订单和入住提醒可以走订阅消息。Web 门户PC 浏览器上打开的预订官网。它承担的是品牌展示和 SEO 流量入口也可以直接走完整预订流程。很多用户习惯在电脑上比较几家民宿的日历价格Web 端在这类场景里的转化率并不低。PC 管理后台给平台运营和房东用的工作台。房源上下架、房态日历批量锁房、改价、订单确认、退改审核、收益结算全在这一端操作。这是最容易被人忽略、却最考验业务建模能力的一块。手机 H5用来承接非微信环境下的落地页比如短信营销链接、抖音挂载链接、外部广告投放。H5 不需要登录也能浏览房源只有下单时才要求登录。四端共用同一套业务数据但交互能力差异很大。小程序有微信登录和支付能力Web 端可以用账号密码登录H5 在微信里打开时还能走公众号 OAuth。设计时千万不要让后端为“每端各写一套”而是要做成一套 API端侧只做适配。后文我会详细讲这套 API 的组织方式。1.2 民宿预订和酒店预订是两种玩法很多开发第一次接触民宿很容易把民宿订单当作酒店房间去处理。实际上两者业务形态有明显差异民宿大多是一房一价同一套房源在周末、节假日、淡季价格完全不同甚至跨年那几天要翻三倍。民宿按“整晚”出租客人选的是入住日期和离店日期系统要按日期跨度计算总价。房东常见操作是“锁房”——某天自己要用、某天不想接待、某天要装修都会手动把日历置为不可订。退改规则更灵活有的民宿是入住前 3 天免费退有的是一经预订不可退规则必须挂到每套房源上。这个产业背景决定了系统的核心不是“商品管理”而是房态日历的准确性。谁能在高并发下单时保证同一间房同一晚不被卖两次谁的系统就能在真实运营里站住脚。所以我一贯的做法是数据库表设计阶段就把房态日历做成独立实体而不是把可订日期塞在一个 JSON 字段里拍脑袋。2. 框架选型不是信仰问题ThinkPHP 与 Laravel 在民宿项目中的真实差异需求方把“Thinkphp和Laravel框架都支持”这句话写在标题里意味着他不希望被某个框架绑架。从我实际开发体验看这两个框架做民宿预订系统确实都成立但各自的“工程手感”差别很大选型前要冷静看清。2.1 两个框架在民宿场景下的坐标ThinkPHP 在国内起步早、使用者基数大中文文档和问答资料非常全新手半个月就能上手干活。Laravel 则是全球 PHP 社区的事实标准生态强大从队列、事件、任务调度到测试工具全是现成的适合长期维护的复杂业务。放到民宿预订系统里我的感受如下表格对比维度ThinkPHPLaravel入门速度中文资料多结构直观上手快学习曲线稍陡但官方文档质量极高ORM 与关联模型Db 类好用Model 关联可用Eloquent 关联设计更顺手处理房源、日历、订单关系方便数据库迁移需要手动维护 SQL 或依赖第三方扩展migration seeder 原生支持多环境数据结构同步省心队列与定时任务需要自己搭脚本queue schedule 原生整合订单超时取消这类场景开箱即用中间件与鉴权6.0 之后有中间件能力够用中间件是一等公民路由级权限控制很自然限流与授权自己实现为主throttle 中间件、Gate 授权机制现成国内人才池大量外包团队熟 TP接盘容易Laravel 在国内也有充足社区高级工程师更认工程规范上限靠团队自律框架本身引导你走规范路线2.2 民宿项目里最有感知的差异点我挑三个对这个项目影响最大的点具体展开。第一个是房态关联查询。搜索房源时要带出日历状态、距离最近的可订日期、价格区间Laravel 的 Eloquent 可以用预加载和关系查询把关联写得非常干净。ThinkPHP 的 Model 关联也能写但更依赖手写 join 和查询构造器代码量会多一点。第二个是订单超时释放。用户下单后如果 15 分钟不支付系统要自动取消订单、回滚房态日历。Laravel 里可以用队列延迟任务定义好 Job 后-delay(now()-addMinutes(15))就完事ThinkPHP 需要自己在 crontab 里挂一个每分钟执行的脚本扫描超时订单。两种都能实现但 Laravel 的体验明显更顺滑。第三个是后台管理界面。PC 管理后台如果要从零搭Laravel 社区里有很多成熟底座可用ThinkPHP 也可以做但更多是前端自己拉一套 Vue 或 AdminLTE 来实现。民宿的房东端要频繁操作日历改价、锁房这类交互密集的页面前端工程化反而是主战场框架差异反而不是决定性因素。2.3 双框架并存的方案值不值我也认真考虑过标题字面意义上“两个框架都支持”的做法小程序 API 用 ThinkPHPPC 后台和 Web 门户用 Laravel两个服务通过公共的 MySQL 和 Redis 通信。这个方案技术上完全可行尤其是在“团队里有人只会 TP、有人擅长 Laravel”的情况下能最大化人员利用率。但我不推荐在中小规模项目里这么干原因有两个一是两套代码库意味着两套上线流程、日志规范、权限体系和运维脚本维护成本直接翻倍二是组内成员跨模块协作时总要切换上下文沟通成本上去之后节省的那点开发时间很快就被吞掉。我的建议是同一个项目里选一个框架做主基调另一个框架可以作为团队招聘和未来技术演进的备选。标题里强调“都支持”真正的价值在于让你在选型时不会被框架锁死而不是真的要一个系统里跑两个框架。3. 数据库建模房态、房价、订单三张核心表怎么设计才不打架民宿系统的数据库设计核心就是围绕“某个房源在某个日期是否可订、卖多少钱”展开。我把整个模型精简成三张核心表加若干辅助表直接给了开发团队一套可落地的建表方案。3.1 三张核心表的职责边界第一张是房源表house存房子本身的静态属性标题、城市、地址、户型整租/单间、卧室数、可住人数、默认价格、押金、入住/退房时间、上下架状态。第二张是房态日历表house_calendar这是民宿系统的灵魂。每一行代表“某房源某一天的状态和价格”字段包括日期、当日价格、状态。状态我设计了四个值0 可订、1 人工锁房、2 订单预占、3 已支付占用。日期是业务维度价格是每日常量。第三张是订单表booking_order记录客人的预订区间下单人、房源、入住日、离店日、晚数、人数、订单金额、押金、支付状态、支付时间。三张表的关系就是一个房源对应多行日历一个房源对应多笔订单一个用户对应多笔订单。因为house_calendar上有房源 ID 和日期的唯一索引所以数据库天然在“同一房源同一日期只能有一条状态记录”这个层面上做了一层保底这是后续防超卖的重要前提。下面是我交付给团队的简化建表脚本去掉了一些业务扩展字段保留了最核心的骨架CREATE TABLE house ( id int(11) unsigned NOT NULL AUTO_INCREMENT, owner_id int(11) NOT NULL COMMENT 房东用户ID, title varchar(100) NOT NULL COMMENT 房源标题, city varchar(50) NOT NULL COMMENT 所在城市, address varchar(255) NOT NULL DEFAULT COMMENT 详细地址, house_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 1整租 2单间, bedroom_count tinyint(4) NOT NULL DEFAULT 1 COMMENT 卧室数量, guest_num tinyint(4) NOT NULL DEFAULT 2 COMMENT 可住人数, base_price decimal(10,2) NOT NULL COMMENT 默认价格, deposit decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 押金, checkin_time time NOT NULL DEFAULT 14:00:00, checkout_time time NOT NULL DEFAULT 12:00:00, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 1上架 0下架, created_at int(11) NOT NULL, PRIMARY KEY (id), KEY idx_city (city) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE house_calendar ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT, house_id int(11) NOT NULL COMMENT 房源ID, date date NOT NULL COMMENT 日期, price decimal(10,2) NOT NULL COMMENT 当日售价, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0可订 1锁房 2预占 3已订, PRIMARY KEY (id), UNIQUE KEY uk_house_date (house_id, date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE booking_order ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, user_id int(11) NOT NULL COMMENT 下单用户, house_id int(11) NOT NULL COMMENT 房源ID, checkin_date date NOT NULL COMMENT 入住日期, checkout_date date NOT NULL COMMENT 离店日期, night_count int(11) NOT NULL COMMENT 住宿晚数, guest_num int(11) NOT NULL COMMENT 入住人数, total_amount decimal(10,2) NOT NULL COMMENT 订单总额, deposit decimal(10,2) NOT NULL DEFAULT 0.00, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已确认 3已入住 4已完成 5已取消 6退款中, created_at int(11) NOT NULL, paid_at int(11) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_house_checkin (house_id, checkin_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个细节我要特别强调订单金额必须快照。客人下单时展示的价格要原样存进订单表之后房东改日历价、调节假日价格都不能影响已生成的订单。这也是为什么价格策略不能只存一份“当前价”的原因。3.2 房价策略怎么落到日历粒度民宿的定价逻辑比酒店复杂。同一天的同一房源全职房东可能设一个价格平台活动又可能叠加优惠周末一个价、节假日一个价、连住三天又有折扣。如果这些只在计算接口里临时算很容易出现展示价和下单结算价不一致的问题。我的做法是把“价格规则”和“实际日历价”分层后台维护一套价格规则星期价、区间价、节假日价、连住优惠点击“应用”之后把规则批量计算并写入house_calendar的price字段。这样前端查日历展示的就是一张实打实的价目表不需要每次查询都实时套用复杂策略。这个设计最大的好处是可回滚、可审计。房东改价时系统只改日历表里未来的日期行历史订单不受影响运营也能直观看到“哪天卖了多少钱”。3.3 订单状态机从锁定到完成的全过程订单状态不能拍脑袋乱跳要设计清晰的状态机。我的订单状态链是这样走的0 待支付→1 已支付→2 已确认→3 已入住→4 已完成分支路线有两条待支付超时自动取消或者用户在规则允许内申请取消进入5 已取消支付后如果要退款走6 退款中退款到账后回到5 已取消或专门放一个“已退款”。每个状态变更都要同步影响房态日历待支付生成时日历标记为“2 预占”防止别人同时下单。支付成功日历从“2 预占”升级为“3 已订”。订单取消或超时回滚日历回到“0 可订”。房东手动锁房、解锁日历在“1 锁房”和“0 可订”之间切换。只要这张状态机和日历状态的对应关系画准确后面所有接口写起来都会非常顺。4. 一套 API 喂饱三端接口设计和多端适配的真实做法4.1 统一接口规范与鉴权体系多端项目最忌讳的就是端端有自己的接口风格。我定的规范是所有接口返回统一 JSON 结构{code, msg, data}code 0表示成功非 0 表示业务异常。列表接口固定{list, page, total}结构错误码和文案在服务端统一管理。接口路径统一前缀/api/v1方便日后升级大版本。核心接口大概是这几类房源列表与搜索GET /api/v1/houses?city杭州checkin2025-06-01checkout2025-06-03guest_num2房源详情与日历GET /api/v1/houses/{id}、GET /api/v1/houses/{id}/calendar?month2025-06下单锁房POST /api/v1/orders订单列表详情GET /api/v1/orders、GET /api/v1/orders/{orderNo}支付与回调POST /api/v1/orders/{orderNo}/pay鉴权体系分两条线小程序端用微信登录换取业务 token。小程序调用wx.login()拿到临时 code后端拿 code 调微信接口换openid和session_key然后为用户生成自有业务 token前端存进 storage。后续请求统一在 header 里带Authorization: Bearer token。Web / PC 后台用账号密码登录校验通过后签发同样的 token。角色权限上我做的是 RBAC 设计平台运营、房东、普通客人三种角色接口按角色做中间件鉴权。4.2 小程序端登录与手机号获取的完整流程小程序登录是民宿预订的关键能力尤其是手机号获取直接决定客人能不能快速完成“注册 预订 支付”。我在这里把流程讲透因为这是热搜词里反复出现的问题也是很多新手被卡住的地方。现在的官方推荐流程已经不是老式的session_key解密而是用手机号快速验证组件。前端放一个按钮button open-typegetPhoneNumber bindgetphonenumberonPhoneNumber微信一键登录/button用户点击后会触发bindgetphonenumber事件对象里带一个动态令牌code。前端把这个code发给后端后端用自己的 access_token 调接口POST https://api.weixin.qq.com/wxa/business/getuserphonenumber?access_tokenACCESS_TOKEN Content-Type: application/json {code: 前端传过来的code}微信返回phone_info里面就是用户的纯手机号和国家区号。拿到手机号后后端先通过wx.login的 code 换openid再把这个 openid 和手机号绑定到用户表。这样用户第一次进来只要点一次按钮账号、手机号、openid 就全部打通了。这个流程有两点容易踩坑换手机号的code跟wx.login的code不是同一个东西别混。每个小程序的openid是不一致的如果未来要做开放平台多小程序打通需要绑定微信开放平台获取unionid作为全局标识。4.3 面向三端的差异处理接口规范统一之后三端差异就控制在端上处理小程序端下单后要引导用户授权订阅消息等服务端在“支付成功”“入住提醒”时给客人发模板消息。Web 端门户需要配置更详细的筛选条件比如商圈、床型、可做饭等这些可以做成可扩展的查询参数。PC 管理后台的接口权限要求更高操作房东资源和改价时必须二次校验权限所有修改操作要有操作日志。一句话后端只关心业务逻辑不关心你是屏幕还是手机。这样后面再加一个抖音小程序、支付宝小程序后端几乎不用动。5. 房态并发与订单超卖民宿系统最容易翻车的现场如果你只记住了前面的表结构那我建议你再看这一章。民宿系统的线上事故十有八九出在并发锁房上。5.1 为什么民宿比普通电商更容易超卖电商卖的是 SKU 库存销量可以累计比如库存 10 件卖完为止。民宿卖的是“某天某房间”同一个房间下周六只有一晚可卖和它竞争的不只是“下周六这天”的订单还有“从周五住到周日”这种跨天订单。两个人同时看中间一晚一个想订周五到周日一个只想订周六一晚如果系统不锁房就会重复售卖。所以房态日产的核心是对连续日期做原子性占用要么全部成功要么全部失败。5.2 三种防超卖方案与我的组合用法我在项目里评估过三种方案方案一纯数据库事务 行锁。下单接口里开事务先对房源记录加锁再查日历、写订单、改日历状态最后提交。这种方案胜在一致性强但并发高时行锁会让请求排队体验会受影响。方案二乐观锁更新。不先查询再更新而是直接执行条件更新用受影响行数判断是否抢到。我实际采用的就是这个核心逻辑UPDATE house_calendar SET status 2 WHERE house_id ? AND date BETWEEN ? AND ? AND status 0;这里BETWEEN的范围是入住日到离店日的前一天status 0表示只允许“可订”的日期被预占。如果更新的行数等于订单的晚数说明锁房成功如果行数少于晚数说明中间有日期已经被占了整个下单事务回滚。这个方案不需要额外的 Redis 锁数据库自身就保证了原子性代码也简单。我配合事务的使用方式如下DB::beginTransaction(); try { $affected HouseCalendar::where(house_id, $houseId) -whereBetween(date, [$checkin, $checkoutBefore]) -where(status, 0) -update([status 2]); if ($affected ! $nightCount) { DB::rollBack(); throw new \Exception(所选日期已被预订或锁定); } $order BookingOrder::create([...]); DB::commit(); } catch (\Exception $e) { DB::rollBack(); throw $e; }方案三Redis 分布式锁。对“房源 日期范围”加锁适合秒杀级流量。民宿系统正常流量根本达不到需要 Redis 分布式锁的程度所以我只在热点房源做了一层缓存保护真正写操作还是靠数据库乐观更新。5.3 超时未支付订单的自动回收用户下单锁房后如果迟迟不付款房态就一直被占着影响真实经营。我设的规则是待支付订单 15 分钟未支付自动取消并回滚日历状态。Laravel 环境下我用了队列延迟任务把取消订单的 Job 延迟 15 分钟执行Job 里再做一次校验只有当订单还是“待支付”状态且确实超过 15 分钟时才取消回滚。ThinkPHP 环境就写一个命令行脚本挂在 crontab 里每分钟跑一次* * * * * php /var/www/project/think CheckExpiredOrder脚本逻辑要特别小心释放房态时只能恢复那些状态仍为“2 预占”且对应订单确实超时的日期不能把已经支付成功的“3 已订”状态也回滚掉。用条件更新就可以天然避免误伤。6. 小程序端的实操细节登录态、调试和通知6.1 登录态与用户体系的数据流小程序端的用户体系核心是“openid 手机号 自建用户表”的三层结构。客人第一次打开小程序时后端先用wx.login的 code 拿到 openid此时用户表里没有记录就创建一个临时用户但不强制弹手机号。等到客人点击预订、涉及支付或房东身份认证时再引导授权手机号。这个“先逛后登录”的设计能显著提升转化率——不要让用户一进来就面对授权弹窗先让他找到想住的房子下单前再补充身份信息。6.2 开发调试阶段的实用套路小程序开发中最容易困惑的是接口调试和真机预览。开发工具里可以临时勾选“不校验合法域名”但这只是本地调试的便利真机预览和线上版本必须把接口域名配进小程序后台的“request 合法域名”而且域名必须支持 HTTPS。联调阶段我会把接口的请求和响应通过代理工具查看一遍确认 header、参数、返回格式都正确。要注意的是这些调试动作都应该围绕自己开发的接口展开目的是定位参数错误和状态码异常而不是去研究别人的小程序流量。正经开发者在联调阶段用代理工具查看自己服务端的响应是很常规的操作。真机预览和线上使用中经常遇到的一个坑是登录态过期。微信小程序的 access_token 和业务 token 过期时间不同步很容易出现“页面还能打开接口却 401”。我建议前端统一封装请求拦截器业务 token 过期时先静默调wx.login换新 token重放原请求用户在页面上几乎无感知。6.3 动态标题、导航栏与订阅消息民宿详情页往往要根据房源的品牌和名称来调整展示。用wx.setNavigationBarTitle({ title: 某某湖畔民宿 })可以动态设置顶部标题比在 pages 配置里写死更灵活。顶部导航栏高度在不同机型上不一样尤其刘海屏。通常可以这样取导航栏高度和胶囊按钮信息const menuRect wx.getMenuButtonBoundingClientRect()拿到返回值后配合env(safe-area-inset-top)做 H5 里的适配小程序端则利用计算出的导航栏高度给自定义导航组件定位。如果你用 uniapp 打包小程序同样的逻辑可以用条件编译包一层别让兼容代码污染 H5 端。订阅消息是民宿订单通知的重要通道支付成功后引导用户订阅“订单状态变更”模板入住前一天下发提醒退改状态变化时再通知一次。注意一个模板消息一次订阅只能发一条所以支付成功时可以引导按需要订阅多条。7. 部署与日常维护两个框架的差别没有想象中大7.1 Nginx 伪静态与入口文件ThinkPHP 和 Laravel 的线上部署结构其实非常像都是把站点根目录指到public通过 Nginx 的 rewrite 把请求转发给入口文件。Laravel 的入口是public/index.phpThinkPHP 从 PHP 8 之后同样以public/index.php为入口Nginx 配置几乎可以复用server { listen 443 ssl; server_name api.example.com; root /var/www/project/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/index.php; fastcgi_pass 127.0.0.1:9000; } }7.2 队列、定时任务与环境管理部署层面真正拉开差距的是 Laravel 自带的队列和任务调度。Laravel 用 supervisor 管理php artisan queue:work常驻进程再用 crontab 每分钟跑一次schedule:runOrderCancel 这类延迟任务全部由框架接管运维只看日志就行。ThinkPHP 则需要自己定义好命令类挂 crontab 执行。我强烈建议无论用哪个框架都开启 PHP 的 OPcache对接口响应有明显的提升。民宿系统的热点是房态日历查询我还会在 Redis 里缓存未来一个月的日历写入或改价时同步更新缓存查询接口的压强会小很多。7.3 上线前最容易忽略的检查项每次上线我都会对着这份清单核对一遍HTTPS 证书是否有效小程序 request 合法域名是否已经添加。服务器时区是否设置为Asia/Shanghai日期比较、房价计算一小时都不能差。MySQL 是否开启事务支持表引擎是否为 InnoDB。订单号生成是否具备唯一性避免并发时订单号撞车。所有涉及金额的接口是否做了服务端校验前端的任何价格数据都不可信。队列和定时任务的日志是否单独输出后续排查线上问题全靠它。8. 如果这是我的项目我会怎么选框架8.1 按交付场景选框架的决策清单我参与过不少项目的技术选型评审最后发现选框架很少是纯技术问题更多是团队和交付周期的问题。如果团队全员熟练 ThinkPHP、项目要求 1 到 2 个月快速上线、后续维护团队也以 TP 为主那 ThinkPHP 是完全合理的重点是把服务层和模型层约束好别写出一堆业务堆在控制器里的代码。如果项目计划做长期迭代、后续要接财务系统、积分系统、多平台分销团队又愿意花一周时间适应 Laravel 的规范我倾向选 Laravel它能让你少写很多重复代码工程质量上限更高。如果团队 PHP 基础一般没有强烈的框架偏好我会直接建议 Laravel因为它用规范和脚手架帮你把路划好了。8.2 我的个人倾向与理由就这个民宿项目而言我最后选的 Laravel。原因不是 Laravel 比 ThinkPHP 高级而是民宿业务里订单状态流转、定时回滚、多端权限这些场景恰好都是 Laravel 生态里最顺手的部分。以后如果要接支付回调、做数据报表Laravel 自带的队列、事件系统和测试支持能让我在维护阶段省下大量时间。但我也要公平地说如果交付时间紧、团队全是 TP 老手、预算有限用 ThinkPHP 一点不丢人。系统的价值在于跑得稳、算得准不在于是哪个框架写的。8.3 最后一句话框架不是这个项目的胜负手真要我给一个总结性建议那就是民宿系统的胜负手不在 ThinkPHP 还是 Laravel而在你肯不肯花半天时间把房态日历的状态流转和并发更新方案画明白。我见过太多项目上线后三天两头出现重复订房最后排查下来全是日历状态和订单状态没对齐造成的。先把这一层想透选哪个框架都不慌。框架只是你写代码的工具房态准确性才是你吃饭的本钱。