同一个付费自习室管理系统我前后完整写过两版。第一版跑在 ThinkPHP 3.2.3 PHP 5.6 上从 2019 年一直支撑到 2022 年服务本地三家门店第二版用 Laravel 重写作为纯 API 后端同时对接小程序和门店自助机。两版都真实上线、真实运营不是教学 Demo。这篇文章把两轮开发里的业务模型、老框架升级、框架选型和踩坑记录整理一遍。它不是为了比较 ThinkPHP 和 Laravel 谁更牛而是想说明付费自习室这种“预约 计时 计费 无人值守”的业务到底对框架提出了哪些隐性要求。适合正在做自习室、共享空间、计时租赁类管理系统的同学参考也适合准备从 ThinkPHP 往 Laravel 迁移的团队。1. 付费自习室系统到底在管什么为什么它不是普通预约系统1.1 核心资源是座位不是订单很多人第一次做这类系统时会下意识把订单当成核心对象先设计订单表、支付流程、退款流程最后才补座位表。这个顺序反过来才合适。自习室业务里座位是稀缺资源订单只是座位在某个时间段被谁占用的一种记录。我的第一版数据库里座位表是绝对的核心所有业务都围绕座位状态机转。一个座位常见状态有这么几种空闲、已预约未到店、使用中、临时离开、维修、锁定。状态不能任意跳转比如“使用中”不能直接变“空闲”必须先走结账动作“已预约”到“使用中”也必须经过扫码落座的确认动作。这些状态转移规则就是这套系统第一层复杂度。座位和时段绑定之后业务上还会衍生出一系列问题一个座位在某天 19:00-22:00 被预约了其他时段能不能继续卖用户预约后 15 分钟没到店座位怎么释放用户中途临时离开 30 分钟座位是保留还是释放计费是否暂停这些问题不是拍脑袋定的每一条都对应实际运营规则。系统要实现得好必须先和门店运营一起把这些规则梳理清楚。1.2 计费引擎比表面看起来复杂得多自习室的计费不是“单价 × 时长”这么简单。我接触到的真实规则至少有这些高峰时段加价周末和晚间 18:00 后单价上浮最低消费时长入场不满 1 小时按 1 小时算首小时优惠新用户首次体验价储值会员折扣不同储值档位对应不同折扣率次卡、月卡、季卡扣次数还是扣天数规则完全不同临时离开规则暂停计费但保留座位超过 N 分钟自动释放超时未结账自动续费到点后按分钟继续计费而不是停掉这套计费引擎如果直接写在控制器里后期一定是一场灾难。我在 ThinkPHP 版里把它写成了一个静态类所有控制器调用同一个入口勉强能用但很难测试。到 Laravel 版才重构为策略模式把“规则判定”和“费用计算”拆开每次调整计价规则只需要改对应策略类不影响其他代码。这一点后面会细讲。1.3 逆向流程决定系统的稳定性预约、支付、入座、结账是正向流程真正容易出问题的是逆向流程用户预约后取消、支付后申请退款、到店发现座位故障、计费中途需要换座。这些流程在需求评审时往往被一笔带过实际开发中却占了大量工作量。举个例子用户买了一张 20:00-22:00 的时段票21:30 申请取消按规则只能退 30 分钟费用但如果座位已经入座则不允许线上取消只能门店后台强制结账。这些分支条件组合起来非常多。我的经验是开发前必须把所有逆向流程画成状态转移图并且在数据库层加状态约束而不是完全依赖代码逻辑否则后续线上问题会层出不穷。2. ThinkPHP 3.2 老底子迁移到 PHP 8一次硬核升级记录2.1 为什么还在动老框架有人可能会问2019 年都有人用 Laravel 了为什么第一版还会用 ThinkPHP 3.2.3当时的情况是团队里没人用过 Laravel而 ThinkPHP 中文文档齐全外包资源丰富接手的维护成本最低。这套系统上线后跑得很稳定真正逼着我动手的原因有两个PHP 5.6 已停止安全维护宿主机检查过不了另外数据库服务器也要一起升级老框架自带的mysql_*数据库驱动在新环境里跑不起来。如果你也维护着 TP3.2 的老系统请先想清楚一个问题是升级框架还是升级写框架的人我当时权衡之后选择了后者因为业务还要继续迭代与其守着旧框架打补丁不如借这次机会整体重构。但重构需要时间线上又不能停所以“先让老系统在新环境活下来”就成了第一个目标。2.2 最棘手的三件事先把数据库驱动换掉。TP3.2 默认的DbMysql驱动依赖mysql_connect、mysql_query这些函数PHP 7.0 开始这些函数被移除PHP 8 更不用说。最直接的方法是切换配置里的DB_TYPE为mysqli但 TP3.2 的 mysqli 驱动对预处理和结果集绑定的支持不太完善部分查询在特定场景下会拿到错误的数据类型。我当时的处理是 fork 了一份驱动类把底层替换成 PDO 的预处理能力同时保留 TP3.2 的上层查询接口。这个方案算是在“不动业务代码”和“能跑起来”之间最务实的折中。第二个坑是框架核心和业务代码里大量使用 PHP 8 已删除的语法。这里列一个我实际遇到的清单风险点在 PHP 8 中的变化处理方式mysql_*函数PHP 7 起已移除替换为 PDO/mysqli 驱动each()PHP 8.0 移除批量重写为 foreachcreate_function()PHP 8.0 移除改用匿名函数closure$str{0}字符串偏移PHP 8.0 移除正则替换为$str[0]魔术引号相关函数早已移除删除相关逻辑隐式类型转换类型错误更严格检查strpos、substr等返回值我建议在迁移时先跑一遍静态扫描工具把所有可疑调用全部列出来再逐个确认。手工翻代码效率太低而且翻完还会漏。我当时先写了一个简单的正则脚本把{形式的字符串偏移全部标记出来光这一项就标记了 200 多处。第三个问题是类型错误。PHP 8 的类型系统比以前严格老代码里大量存在“函数返回 false 后直接再做字符串处理”的写法。这类问题平时不报错数据异常时才暴露尤其集中在导出报表和统计模块。解决办法不是改业务逻辑而是加一层封装对所有外部输入和数据库返回值做统一的类型兜底。2.3 安全加固不能漏从 2018 年开始ThinkPHP 陆续出现过几轮安全公告尤其是路由和 SQL 注入相关的风险。老版本系统如果一直没打补丁迁移到 PHP 8 后更需要做一次全面加固。我做过的处理有三点关闭 debug 模式和字段缓存避免敏感信息泄露给数据库账号配置最小权限应用账号不再持有 drop、truncate 这类高危权限对所有外部参数统一做白名单过滤禁止直接拼进 SQL。另外想提醒一句网上流传的“ThinkPHP 出库系统源码免费版”“xx 系统源码免费下载”很多是从外包项目流出来的老版本里面可能残留了调试后门、弱口令、固定密钥。哪怕只是学习参考也别直接放到生产环境。真要拿来用先做代码审计改掉默认后台路径、换掉密钥再谈后续开发。3. Laravel 落地自习室业务中间件管道与 REST API 设计3.1 中间件到底是怎么把请求“穿过去”的用 Laravel 写 API 后端避开不了一个话题就是中间件。Laravel 的中间件本质上是一个洋葱模型请求从最外层开始依次经过每个中间件到达核心处理器响应再原路返回。用一段伪代码理解这个概念会更直观// 中间件的核心结构 $request Request::capture(); $middlewareStack [ CheckMemberStatus::class, SeatAccessToken::class, RequestLogger::class, ]; $pipeline array_reduce( array_reverse($middlewareStack), function ($nextMiddleware, $middleware) { return function ($request) use ($nextMiddleware, $middleware) { return (new $middleware)-handle($request, $nextMiddleware); }; }, function ($request) { return $request-controller(); } ); $response $pipeline($request);这里的关键在于$next($request)这个闭包。它在每个中间件的handle方法里被调用调用前是“前置逻辑”调用后是“后置逻辑”。很多新手第一次写中间件时会有个误解以为中间件只是路由前做的一件事其实它还能处理响应public function handle(Request $request, Closure $next) { // 前置逻辑请求到达控制器之前 if (! $request-user()) { return response()-json([code 401, message 未登录], 401); } $response $next($request); // 后置逻辑控制器处理完成后、响应返回浏览器/客户端之前 $response-headers-set(X-Request-Time, microtime(true) - LARAVEL_START); return $response; }在自习室项目里我真正用到中间件的场景有四个登录态校验、会员封禁状态校验、扫码开门令牌校验、请求日志记录。如果不用中间件这些逻辑也可以写在控制器里但那样每个控制器方法都要重复这些代码后期维护成本高得多。3.2 用中间件收口“扫码开门”令牌付费自习室大部分是无人的用户在小程序上购买时段后需要扫码进入门店。这里的核心问题是用户扫的二维码不能是固定链接否则被截图转发就能无限扫码进门。我的方案是每次开门动态生成一个短期令牌令牌里包含座位 ID、用户 ID、时间段、签名有效期 60 秒。这个校验逻辑放在中间件里非常合适因为小程序、门店自助机、后台管理系统都可能在调用同一个开门接口所有入口统一经过中间件收口安全性更容易把控class VerifySeatAccessToken { public function handle(Request $request, Closure $next) { $token $request-header(X-Seat-Token); if (! $token) { return response()-json([code 401, message 缺少开门凭证], 401); } try { $payload \Crypt::decryptString($token); [$seatId, $userId, $expiresAt] explode(|, $payload); } catch (DecryptException $e) { return response()-json([code 401, message 令牌无效], 401); } // token 过期校验 if ((int) $expiresAt time()) { return response()-json([code 401, message 凭证已过期请重新获取], 401); } // 把解析出来的用户 ID 绑定到请求上后续控制器可以直接取用 $request-merge([verified_user_id (int) $userId]); $request-merge([verified_seat_id (int) $seatId]); return $next($request); } }实际运行时还有一个细节容易忽略客户端请求头里的X-Seat-Token在预检请求OPTIONS阶段也会触发中间件如果你没有在 Laravel 的 CORS 配置里放行这个自定义头前端会一直拿不到正确响应。这个坑我在 5.1 节会专门再说。3.3 REST API 层的体面做法第二版后端整体采用 REST API 架构路由文件采用api.php按资源维度组织Route::group([prefix v1], function () { Route::apiResource(seats, SeatController::class)-only([index, show]); Route::apiResource(orders, OrderController::class)-only([store, show]); Route::post(reservations/{reservation}/checkin, ReservationController::class . checkin); Route::post(reservations/{reservation}/checkout, ReservationController::class . checkout); Route::post(reservations/{reservation}/cancel, ReservationController::class . cancel); });控制器只做参数中转业务逻辑尽量下沉到 Service 类输出统一使用 API Resource。这里有一个很实用的优化点所有列表接口都离不开“座位 最新订单 会员昵称”这类关联查询如果不加控制很容易出现 N1 查询。Laravel 的 API Resource 加上whenLoaded可以优雅处理这个问题class SeatResource extends JsonResource { public function toArray($request) { return [ id $this-id, name $this-name, area $this-area, status $this-status, // 没有加载关联时自动不输出避免额外查询 current_order new OrderResource($this-whenLoaded(currentOrder)), ]; } }在控制器里用Seat::with(currentOrder)-...预加载一次性把需要的关联数据查出来避免循环里一条条查。这个小优化在座位列表只有二三十条时看不出差别但到了门店查看“今日所有时段座位的预约情况”这种列表页性能差距会非常明显。4. 同一套业务两种框架的实现思路对比4.1 定时任务释放超时未到店的预约自习室业务里有两个典型的定时任务每 1 分钟检查“已预约但超过 15 分钟未到店”的座位并自动释放每晚凌晨汇总当天的结算数据生成门店经营报表。ThinkPHP 3.2 时代没有内置调度器我的方案是写一个 PHP CLI 脚本放在项目根目录由系统 cron 每分钟调用一次。这个脚本的核心逻辑不复杂查出所有超时未确认的预约批量把座位状态改为空闲把预约状态改为已过期。但实际操作中有个坑TP3.2 的入口文件在 CLI 模式下会加载 debug 信息如果脚本里引入了 Web 路由cron 的日志里会夹杂大量 HTML 输出干扰排错。解决办法是在入口文件里判断php_sapi_name()CLI 模式强制关闭 debug。Laravel 里同样的功能就顺手很多用自带的调度器class ReleaseExpiredReservations extends Command { protected $signature seats:release-expired; protected $description 释放超时未到店的预约座位; public function handle() { $expiredAt now()-subMinutes(15); Reservation::query() -where(status, pending_confirm) -where(created_at, , $expiredAt) -update([status expired]); $this-info(过期预约已释放); } }然后在app/Console/Kernel.php里注册protected function schedule(Schedule $schedule) { $schedule-command(seats:release-expired)-everyMinute(); }两套实现的核心 SQL 是一样的差在工程化程度上。Laravel 的调度器自带日志、后台运行、避免重复执行等能力不需要额外造轮子。4.2 删除座位关联数据到底怎么处理这是我在第一版里留下最深刻教训的地方。一开始设计座位表时我想当然地给座位加了“删除”功能删除座位时自动删除该座位未来所有预约记录并给用户发送退款通知。听起来很合理对吧结果删掉一个座位后财务对账时发现金额对不上。一查才发现关联删除时把过去的历史订单也一并删掉了而历史订单是已经入账的营收数据。从商业模式上讲历史订单只能标记“已作废”或“已退款”绝对不能物理删除。这个事故之后所有涉及金额和订单的删除操作全部改成软删除订单表加status字段取消、退款、作废都是改状态不走 delete座位表加is_deleted字段删除只是从后台列表隐藏数据库保留记录TP3.2 的_before_delete钩子里如果还要额外查库一定要确认主删除成功后再操作否则容易触发重复执行到了 Laravel 版模型事件提供了更干净的方案class Seat extends Model { protected static function booted() { static::deleting(function (Seat $seat) { // 判断是软删除还是硬删除 if ($seat-isForceDeleting()) { // 强制删除时只允许删除未来未开始的预约历史订单一律不动 $seat-reservations() -where(start_time, , now()) -whereIn(status, [pending, confirmed]) -update([status cancelled_by_admin]); } }); } }两版对比下来TP3.2 的钩子触发时机比较隐蔽Laravel 的模型事件更可控但底层思路完全一致删除永远要问一句“这里该删的是记录本身还是这条记录的业务状态”。4.3 代码组织方式从“能用”到“好维护”两套系统开发时间间隔不到三年我对代码组织的理解明显不一样。第一版 TP3.2 的项目结构是典型的 MVC 加一个杂乱的 service 目录所有公共方法都堆在一个CommonService.class.php文件里最后这个文件超过 3000 行。当时觉得没什么后来改一个计费规则要在 30 个方法里翻来找去非常痛苦。第二版 Laravel 项目采用简单的领域分层app/ ├── Http/ │ ├── Controllers/ │ ├── Middleware/ │ ├── Requests/ │ └── Resources/ ├── Services/ │ ├── Price/ │ ├── Reservation/ │ └── Report/ ├── Models/ └── Events/计费规则被收敛到Services/Price目录下一条规则一个类。比如高峰加价规则实现统一接口将来新增节假日规则只需要加一个类不改动原有代码。这种组织方式的维护体验比 TP3.2 时代好太多这也是我后来在团队里推荐新项目直接用 Laravel 的核心原因。下面是两套实现的一个简要对齐功能点ThinkPHP 3.2 实现Laravel 实现路由定义单入口路由配置规则较简陋独立 api.php支持资源路由请求参数校验写业务代码时手动 validateFormRequest自动化校验 错误响应数据库操作M() 和模型混用链式查询较弱查询构造器和 Eloquent ORM方案统一定时任务cron 手写 CLI 脚本Scheduler Artisan Command队列需要额外扩展内置队列抽象适合处理退款通知等单元测试几乎没有支持开箱即用计费引擎可以真正做测试必须说明我对比的是 TP3.2 这一代。ThinkPHP 6/8 已经引入了不少现代特性很多方面差距没那么大。但如果从零开始做一个需要长期迭代的业务系统Laravel 的配套工具链和社区生态确实更完整。5. 实战中那几个害人不浅的坑5.1 Laravel storage 里的 PDF 出现 CORS 错误这个坑出现得很隐蔽。后台管理系统需要查看订单凭证我的实现是把 PDF 生成后存到storage/app/private然后通过route(receipt.show, $order-id)返回。在本地用php artisan serve测试时一切正常一上生产环境后台管理端访问订单凭证 PDF 就一直报跨域错误。排查了很久最终发现原因在 Nginx。生产环境的 Nginx 配置里/storage/路径被直接映射到静态文件目录请求到达 Nginx 后就直接返回文件了根本没有经过 Laravel 中间件。而我的 CORS 中间件只注册在应用路由上对静态文件完全无效所以响应头里没有Access-Control-Allow-Origin。本地php artisan serve没有 Nginx 这一层所有请求都走 PHPCORS 头自然正常。这个差异导致本地测不出问题部署到服务器才暴露。解决办法有两个方向。如果 PDF 必须放在storage/app/public下就在 Nginx 层对 PDF 目录加add_header Access-Control-Allow-Origin *;。我更推荐走应用路由Route::get(/receipts/{order}, function (Order $order) { $pdfPath receipts/ . $order-id . .pdf; if (! Storage::exists($pdfPath)) { abort(404); } return Storage::download($pdfPath); })-middleware([admin.auth, cors]);这样 PDF 的访问权限、跨域头、鉴权逻辑都可以统一在应用层控制不用依赖服务器配置。如果你的后端是纯 API 模式这类文件下载接口会越来越多一开始就统一走路由更省心。5.2 关联删除引发的“财务事故”第 4 节里提到过这个事故这里把完整过程说一遍。当时的场景是门店要撤掉一张坏掉的座位管理员在后台点击“删除座位”。我在删除逻辑里写了级联删除把该座位下的预约和订单全部删掉。本以为能快速完成任务结果第二天财务对账时发现最近一个月的订单总额和支付平台对不上差额恰好是那个座位过去一段时间产生的订单收入。查询数据库才发现关联删除执行时不仅删掉了未来预约也把历史订单一起删了。当时的订单表没有做软删除设计物理删除后连恢复都很困难最后从备份表里手工捞回数据才把账抹平。从这个事件后我定了一条铁律订单、流水、优惠券核销记录这种涉及金额的数据只允许“作废”和“标记失败”绝不允许物理删除。座位、用户这种主数据可以删但必须用软删除字段。后台所有“删除”操作都要过一道审计日志记录操作人、操作时间、操作前后的数据状态。用现在的话说这叫数据可追溯。在 TP3.2 那种老架构里缺少现成的软删除机制手动加is_deleted字段虽然不难但容易遗漏。Laravel 的SoftDeletes特性直接解决了这个问题模型默认不返回已删除数据关联查询也能自动过滤。不过要注意软删除不等于万事大吉数据库里的无主数据和一个特殊的状态标记完全不同做报表归集时还是得想清楚哪些数据要包含已删除记录。5.3 并发抢座同一座位同一时段怎么防止卖两次自习室在某个黄金时段比如周末下午确实会出现两个用户同时抢同一个座位的情况。如果代码是“先查座位是否为空再插入预约”并发场景下肯定出事两个请求同时查到座位为空同时插入预约结果一个座位同一时段卖出两次。这类问题的正统解法是数据库行锁。Laravel 里面的写法很清楚DB::transaction(function () use ($seatId, $startTime, $endTime, $userId) { $seat Seat::query() -whereKey($seatId) -lockForUpdate() -first(); // 拿到锁之后再查冲突预约 $overlap Reservation::query() -where(seat_id, $seatId) -where(start_time, , $endTime) -where(end_time, , $startTime) -whereIn(status, [pending, confirmed]) -exists(); if ($overlap) { throw new SeatConflictException(该时段已被预约); } Reservation::create([ user_id $userId, seat_id $seatId, start_time $startTime, end_time $endTime, status confirmed, ]); });ThinkPHP 3.2 里对应的方法是lock(true)$seat M(Seat)-where([id $seatId])-lock(true)-find();关键点在于先锁住座位这一行记录其他事务必须等第一个事务提交后才能继续读取这样就避免了“两个事务同时看到座位为空”的问题。这是最朴素也最可靠的方案。我还在数据库层加了一道唯一索引兜底字段组合是座位 ID 开始时间 结束时间 状态里的非取消状态不过这个设计在实际操作中有点复杂因为“状态”不是一个固定值。更简单的兜底方案是在预约表上建立一个“互斥预约”触发器但复杂规则很难用触发器表达。最终我采用的是“行锁为主应用层互斥校验为辅定时任务扫描异常数据”的组合方案线上至今没有出现过超卖。关于 Redis 锁我也简单说过自己的看法自习室的并发量远没到必须引入分布式锁的程度行锁完全够用。如果你非要上 Redis 锁一定要考虑锁过期时间、误删锁、集群丢锁这些额外问题复杂度反而上去了。6. 给后来者的选型建议与实际维护笔记6.1 新项目到底选哪个如果是全新项目我的建议直接选 Laravel理由前面已经说了调度器、队列、软删除、API Resource、FormRequest、更成熟的 ORM这些都是在自习室这类业务里实际用得上且能明显提升效率的能力。Laravel 的学习曲线比 ThinkPHP 陡一点但当你需要处理定时任务、异步通知、测试、部署流程时社区方案可以让你少走很多弯路。如果团队已经用 ThinkPHP 维护老系统不要盲目推倒重写。先把老系统在新版本 PHP 环境跑稳定再逐步把核心模块迁移出来。ThinkPHP 6/8 现在也很务实该有的中间件、依赖注入、模型事件都有。关键是别停在 3.2 这个旧版本上旧版本的已知安全问题和兼容性负担会随着时间越滚越大。6.2 两条实际维护经验第一不要轻易下载运行网上流传的“付费自习室系统源码”“出库系统源码免费版”。这些源码很大概率是从某些外包项目里直接拷贝出来的里面带着真实数据的测试库、固定的后台路径、甚至预留的后门。真要用第一步应该做代码审计替换所有默认密钥和后台账号然后再部署。第二不管用什么框架从一开始就要保留核心数据变更的操作日志。自习室系统的订单状态变迁、座位状态迁移、计费规则调整这些都需要审计。没有日志出问题只能对着数据库瞎猜。我的做法非常朴素TP3.2 时代就建了一张operation_logs表Laravel 时代换成一个简单的 Observer记录操作人、操作模块、操作前值、操作后值。看似多写几行代码关键时刻能救命。6.3 框架只是容器业务规则才是护城河回到开头说的那件事我写了两套系统选了不同框架但核心业务模型始终没变——座位状态机和计费引擎。框架承载了路由、数据库操作、中间件、队列这些基础设施但真正决定系统值不值钱的是你对自习室运营规则的理解深度。如果你接手这样的项目我建议先把座位状态流转、计费规则、逆向流程整理成文档再谈选型。这些业务规则沉淀好了后续想把 ThinkPHP 换成 Laravel或者把 Laravel 换成别的什么都只是工作量问题不至于伤筋动骨。我在 Laravel 版里把计费规则拆成独立策略类之后改计价规则基本不再碰控制器和模型这种体验才是重构带来的最大收益。