企业官网建设流程全解析

做了几年PHP开发，接触过不少业务系统，但电影订票这类带强实时性、强事务性的项目，确实是个很好的技术练兵场。手头这个基于ThinkPHP和Laravel双框架的电影订票系统，是我在某公司内部项目孵化阶段做的完整实战项目，从需求分析到数据建模，从双框架选型到高并发座位锁定，踩了不少坑，也沉淀了不少经验。今天把整个项目的设计思路和核心实现细节拆开聊聊，希望能给准备做订票、选座、预约类系统的朋友一些参考。

1. 项目概述与核心需求解析

1.1 这个项目解决的核心问题

电影订票系统本质上是一个典型的交易型业务系统，核心链路很清楚：用户浏览影片 -> 选择场次 -> 在线选座 -> 下单支付 -> 生成电子票 -> 影院核销。听起来跟电商下单差不多，但实际做起来有几个非常棘手的点，这也是我当初接下这个项目时最关注的部分。

第一个痛点是座位资源的实时性。同一场次的有效座位是有限的，多个用户同时在看同一批座位，A用户锁定的座位绝不能同时卖给B用户，这就要求座位锁定必须有严格的并发控制。第二个痛点是订单状态的复杂性。一个订单要经历待支付、已支付、已出票、已取消、已退票这么多个状态，而且状态流转必须跟支付回调、锁座有效期、场次开始时间这些因素联动。第三个痛点是双框架带来的协作问题。项目要求基于ThinkPHP和Laravel两套框架完成，这就得想清楚两个框架的职责边界，不能让它们互相打架。

如果你是刚接触这类项目的开发者，或者准备做影院、剧院、体育赛事等座位预订类系统，这个项目的拆解思路和代码层面的实现方案都是可以直接借鉴的。项目本身的代码规模不大，但麻雀虽小五脏俱全，该有的并发控制、事务一致性、缓存策略都在里面。

1.2 为什么选择双框架方案而不是单一框架

很多朋友看到“ThinkPHP + Laravel”这个组合会有点疑惑——明明一个框架就能搞定的事，为什么非要上两套？这里我要先说明白，双框架不是炫技，而是有实际业务背景的。

在实际工作中，这种双框架并存的情况往往出现在系统升级过渡期。老的业务模块是用ThinkPHP写的，沉淀了大量稳定功能，重新用Laravel完全重写成本太高风险太大；但新业务模块需要更成熟的生态支持，比如更优雅的队列机制、更灵活的中间件体系，这时候自然倾向用Laravel来做。我这个项目就是这种状态：后台管理和基础信息维护继续用ThinkPHP，面向C端用户的API接口和订单核心链路用Laravel实现。

这样划分的好处有三个：

• 后台管理模块（影院管理、影片管理、场次排片）逻辑相对简单，ThinkPHP的CRUD开发效率极高，而且现有团队对TP的维护经验丰富
• 前端用户端涉及下单、支付、锁座等核心交易链路，Laravel的Eloquent ORM、事件监听、队列、缓存机制更成熟，处理复杂业务更从容
• 两个框架通过统一的API网关层通信，业务边界清晰，后续如果要做微服务拆分，这个架构可以平滑演进

2. 系统整体设计与数据模型拆解

2.1 系统架构与模块划分

整个系统从功能上分为三个端：用户端、管理端、API服务层。用户端负责影片展示、场次查询、在线选座、订单管理等；管理端负责影片排片、影院信息维护、订单核销、数据统计；API服务层则是承载业务逻辑的核心，也是连接两端的桥梁。

模块划分上，我按照领域职责拆成了这么几个：用户模块、影片模块、场次模块、座位模块、订单模块、支付模块。其中座位模块和订单模块是核心中的核心，也是技术难点最集中的地方。

项目根目录 ├── thinkphp/ # TP端，负责后台管理与基础维护 │ ├── application/ │ │ ├── admin/ # 管理后台模块 │ │ └── api/ # 对TP端的简单数据接口 │ └── ... ├── laravel/ # Laravel端，负责C端API与核心交易链路 │ ├── app/ │ │ ├── Http/ │ │ ├── Models/ │ │ ├── Services/ # 订单、锁座等业务服务层 │ │ └── ... │ └── ... └── ...

目录结构是物理隔离的，两个框架跑在同一台服务器的不同端口上。TP端监听8080，Laravel端监听8081，统一走Nginx反向代理对外提供服务。这样做的好处是两个框架互不干扰，各自的依赖、配置、日志都完全隔离，部署时也可以单独升级。

2.2 数据库表结构与核心字段设计

数据库我用的是MySQL 8.0，存储引擎统一InnoDB，字符集utf8mb4。整个系统一共设计了9张核心表，这里我把关键表和字段结构列出来，这些字段都是经过实际业务验证的。

用户表（users）主要负责账号体系的基础信息，包含自增主键id、用户名username、密码哈希password_hash、手机号phone、注册时间created_at等字段，密码字段我用的是bcrypt算法生成哈希值，长度设定在255位，不直接存储明文。这里有个细节需要注意，username字段虽然是用户登录凭证，但未来很可能需要支持手机号、邮箱等多种登录方式，所以username并没有加唯一索引，而是用了一个独立的login_account字段做唯一约束，这样后续扩展登录方式时不需要改表结构。

影片表（movies）保存电影的基础信息，包含影片ID、标题title、封面图cover、时长duration_minutes、上映日期release_date、剧情简介synopsis、状态status（1即将上映、2热映中、3已下架）等。这里比较重要的是status字段的维护方式，它不是靠人工手动修改，而是通过定时任务在每天凌晨自动计算，根据上映日期和当前时间的对比来更新状态，避免人工漏改导致前端展示了错误场次。

场次表（schedules）是连接影片和影院的桥梁，关联movie_id、cinema_id、hall_id、放映时间start_time、结束时间end_time、票价price、状态status等字段。票价这里我处理成了decimal(10,2)类型，精确到分，避免浮点数计算误差。end_time不靠人工录入，而是在创建场次时根据影片时长加放映间隔自动计算出来，这样可以保证同一影厅的场次时间不会重叠。

影厅表（halls）和座位表（seats）是选座功能的基础。影厅表记录所属影院cinema_id、影厅名称name、座位行数seat_rows、座位列数seat_cols；座位表记录所属影厅hall_id、行号row_no、列号col_no、座位类型seat_type（普通座、情侣座、无障碍座）、是否过道is_aisle等。创建影厅时系统会根据行数和列数自动生成对应的座位记录，这种冗余生成的方式虽然多占了存储空间，但为后续的座位查询和锁定提供了极大的便利，不需要动态计算。

订单表（orders）、订单明细表（order_items）和支付流水表（payments）是交易链路的核心。订单表包含订单号order_no、用户ID user_id、场次ID schedule_id、总金额total_amount、订单状态status、锁定过期时间lock_expire_at、支付时间paid_at等；订单明细表记录订单对应的具体座位，一个订单可能包含多个座位；支付流水表记录每笔支付请求的流水号transaction_id、支付金额amount、支付渠道channel、回调状态callback_status等。

这里我特别说一下订单号的设计。订单号我用了日期 + 随机数 + 用户ID后四位的生成策略，例如20250605xxxx1234，长度控制在20位以内，同时在数据库层面对order_no建立了唯一索引。为什么不用雪花ID？因为在单库单表的业务场景下雪花ID反而会增加复杂度，自增ID配合业务订单号的组合完全够用，而且这套方案在排查问题时可以直接肉眼关联订单和用户，信息可读性强很多。

2.3 接口设计与数据交互约定

两个框架之间的通信以及对外提供服务，统一走RESTful风格的JSON接口。响应格式我做了统一封装，无论哪个端返回的数据都遵循同一个结构。

{ "code": 0, "message": "success", "data": {} }

code为0表示业务成功，非0表示业务异常，通过message返回错误提示。前端只需判断code就能统一处理所有错误场景，不需要关心HTTP状态码的差异。框架层面的异常由全局异常处理器捕获后同样转换成这个格式，保证接口层的一致性。

API接口设计上，我坚持了资源导向的URL设计原则。比如GET /api/v1/movies获取影片列表，GET /api/v1/schedules?movie_id=1获取某部影片的场次，POST /api/v1/orders创建订单，POST /api/v1/orders/{order_no}/pay发起支付，POST /api/v1/orders/{order_no}/cancel取消订单。每个接口都对应一个明确的资源操作，参数统一通过请求体验证，响应数据不冗余返回无关字段。

3. 核心业务功能的实操实现

3.1 影片和场次查询模块的实现

查询模块虽然在技术上不算难，但确实直接决定了用户的第一体验，所以我把缓存优化放在了这个环节。影片列表和场次列表是典型的读多写少的数据，如果每次请求都查数据库，高并发场景下数据库压力会非常大。

我用Laravel自带的Cache门面做了两层缓存。第一层缓存影片列表数据，key设计为movie_list:status:2，缓存时间为10分钟，这个时间设定是经过权衡的——太短起不到缓存效果，太长会导致影片下架后前端还在展示过期数据。第二层缓存场次列表，key设计为schedule_list:movie:{movie_id}:date:{date}，缓存时间为5分钟。

// 获取指定影片的场次列表（含缓存） public function getSchedules(Request $request, $movieId) { $date = $request->input('date', date('Y-m-d')); $cacheKey = sprintf('schedule_list:movie:%d:date:%s', $movieId, $date); $schedules = Cache::remember($cacheKey, 300, function () use ($movieId, $date) { return Schedule::with(['cinema', 'hall']) ->where('movie_id', $movieId) ->whereDate('start_time', $date) ->where('status', 1) ->orderBy('start_time') ->get(); }); return $this->success($schedules); }

这里有一个容易踩的坑：Cache::remember在缓存数据为空的时候会把空数组也缓存起来，这本来是好事，但如果缓存的是Eloquent模型集合，序列化到Redis再反序列化出来，里面的一些临时属性和日期格式可能会发生变化。我建议在使用remember缓存复杂数据时，强制在闭包最后调用->toArray()转成纯数组，这样缓存中只有纯数据，反序列化结果更稳定。

数据库层面，我自己在schedules表上做了movie_id + start_time的联合索引，把高频查询字段覆盖进去。在explian的验证下，原本全表扫描的SQL走了索引后，查询耗时从80ms降到了5ms以内，效果非常直观。

3.2 选座与锁定流程的实现

这个模块是整个系统的核心难点，也是我花时间最多的地方。座位锁定的需求是：用户选择了某个场次的一个或多个座位后，这些座位必须在用户下单期间被独占，其他人不能重复选择，同时要在用户放弃支付后自动释放。

最直接的方案是用数据库事务配合SELECT ... FOR UPDATE做行级锁，但这个方案有个问题：锁粒度大、性能消耗高，而且在高并发场景下容易出现锁等待和死锁。我最终采用的是Redis分布式锁 + 数据库事务的组合方案。

流程是这样的：

1. 用户发起锁座请求，携带场次ID和座位ID列表
2. 系统先通过Redis的SETNX命令尝试获取每个座位的分布式锁
3. 拿到全部锁后，再开启数据库事务，检查座位状态并创建占座记录
4. 事务提交后释放Redis锁

// 锁座核心逻辑 public function lockSeats(Request $request) { $scheduleId = $request->input('schedule_id'); $seatIds = $request->input('seat_ids'); $expireSeconds = 300; // 锁座有效期5分钟，超时自动释放 // 收集所有需要加锁的座位key $lockKeys = []; foreach ($seatIds as $seatId) { $lockKeys[] = sprintf('seat_lock:%d:%d', $scheduleId, $seatId); } // 尝试一次性获取全部锁，防止死锁 $lockValues = []; foreach ($lockKeys as $key) { $value = Str::random(16); $locked = Redis::set($key, $value, 'EX', $expireSeconds, 'NX'); if (!$locked) { // 某个座位已被占用，释放已获取的锁 $this->releaseLocks($lockValues); return $this->error('seat_occupied', '有座位刚刚被选走了，请重新选择'); } $lockValues[$key] = $value; } // 获取锁成功后，开启数据库事务，检查座位状态并创建占座记录 try { DB::beginTransaction(); $lockedSeats = SeatLock::where('schedule_id', $scheduleId) ->whereIn('seat_id', $seatIds) ->where('expire_at', '>', now()) ->lockForUpdate() ->get(); if ($lockedSeats->isNotEmpty()) { DB::rollBack(); $this->releaseLocks($lockValues); return $this->error('seat_occupied', '座位已被预订'); } // 创建占座记录 foreach ($seatIds as $seatId) { SeatLock::create([ 'schedule_id' => $scheduleId, 'seat_id' => $seatId, 'user_id' => auth('api')->id(), 'expire_at' => now()->addMinutes(5), 'order_no' => $this->generateOrderNo(), ]); } DB::commit(); $this->releaseLocks($lockValues); return $this->success(['lock_expire_at' => now()->addMinutes(5)]); } catch (\Exception $e) { DB::rollBack(); $this->releaseLocks($lockValues); Log::error('锁座失败: ' . $e->getMessage()); return $this->error('lock_failed', '系统繁忙，请稍后重试'); } }

这个方案的关键点是先获取全部Redis锁再操作数据库，而不是逐座分批获取，这样可以避免多个请求互相持有对方所需锁导致的死锁问题。Redis锁的过期时间我设成了5分钟，比用户的支付时间略长，如果用户5分钟内不支付，锁会自动过期，座位释放给其他人。

还有一个细节需要注意：SeatLock表的查询必须加上lockForUpdate()，虽然上面已经有Redis锁做并发控制了，但数据库层面的行锁仍然是有必要的兜底。因为Redis锁有可能会因为网络抖动、主从切换等极端问题失效，数据库锁是最后一道防线，两把锁同时用才足够安全。

3.3 下单与订单状态机设计

订单状态的设计直接决定了交易流程的可维护性。我参考了电商平台的标准做法，设计了一套完整的状态机，并且用数据库字段status存储当前状态，用transition_log表记录状态流转历史。

// 订单状态常量定义 const STATUS_PENDING_PAYMENT = 1; // 待支付 const STATUS_PAID = 2; // 已支付 const STATUS_ISSUED = 3; // 已出票 const STATUS_USED = 4; // 已使用（已核销） const STATUS_CANCELLED = 5; // 已取消 const STATUS_REFUNDED = 6; // 已退票

每个状态可以流转到哪些状态，我在代码里做了一个显式的路由配置，不允许非法跳转。比如待支付状态可以流转到已支付，也可以流转到已取消；已支付状态可以流转到已出票和已退票，但绝不允许从已出票直接流转到已取消。

// 订单状态流转合法性校验 private $allowedTransitions = [ self::STATUS_PENDING_PAYMENT => [self::STATUS_PAID, self::STATUS_CANCELLED], self::STATUS_PAID => [self::STATUS_ISSUED, self::STATUS_REFUNDED], self::STATUS_ISSUED => [self::STATUS_USED, self::STATUS_REFUNDED], self::STATUS_USED => [], self::STATUS_CANCELLED => [], self::STATUS_REFUNDED => [], ]; public function transition($order, $targetStatus) { if (!in_array($targetStatus, $this->allowedTransitions[$order->status])) { throw new \Exception('非法的订单状态流转'); } $oldStatus = $order->status; $order->status = $targetStatus; $order->save(); // 记录状态流转历史 TransitionLog::create([ 'order_no' => $order->order_no, 'from_status' => $oldStatus, 'to_status' => $targetStatus, 'operator_type' => 'system', ]); }

状态机的好处是让订单的每一步流转都有据可查，出了问题可以很精准地定位是哪一步跳错了。而且配合Laravel的事件监听机制，我可以在状态变化时自动触发后续动作，比如支付成功后自动调用出票方法生成电子票，而不需要在支付回调代码里手动写一堆if-else。

3.4 支付回调与票号生成

支付这一块，我接了市场上的主流聚合支付SDK，但这里不去细说具体是哪一家，重点讲支付回调的处理逻辑，这部分踩坑最多。

支付回调必须注意幂等性问题。支付平台在回调失败时会重新发送多次通知，如果回调逻辑不是幂等的，就会出现同一笔订单被重复处理、重复出票的情况。我在处理回调时用的策略是：以支付流水号为唯一标识，先查流水是否已处理过，处理过就直接返回成功，不再重复执行业务逻辑。

// 支付回调处理（幂等） public function handlePaymentCallback(Request $request) { $callbackData = $request->all(); $transactionId = $callbackData['transaction_id']; // 检查流水是否已处理过 $payment = Payment::where('transaction_id', $transactionId)->first(); if ($payment && $payment->callback_status == 2) { // 已处理过，直接返回成功，防止重复回调 return $this->success(); } // 验签通过后开始处理 DB::beginTransaction(); try { // 更新支付流水状态 $payment = Payment::where('transaction_id', $transactionId) ->lockForUpdate() ->first(); if (!$payment) { throw new \Exception('支付流水不存在'); } if ($payment->callback_status == 2) { DB::commit(); return $this->success(); } // 更新流水 $payment->callback_status = 2; $payment->callback_data = json_encode($callbackData); $payment->paid_at = now(); $payment->save(); // 更新订单状态 $order = Order::where('order_no', $payment->order_no)->first(); $this->transition($order, Order::STATUS_PAID); // 生成电子票 $this->issueTickets($order); DB::commit(); return $this->success(); } catch (\Exception $e) { DB::rollBack(); Log::error('支付回调处理失败: ' . $e->getMessage()); return $this->error('callback_error'); } }

票号生成我用了日期 + 场次ID + 座位号的组合，例如20250605-023-05排08座，同时生成对应的二维码内容。票号本身可读性要强，方便检票员人工核对，二维码内容是一个随机token，绑定订单号和座位号，在核销接口里做校验，起到双重验证的作用。

4. 双框架协作中的典型问题与排查技巧

4.1 跨框架会话与鉴权不一致问题

双框架协作第一个遇到的问题就是用户登录状态的共享。ThinkPHP的Session是基于文件存储的，Laravel默认也支持Session，但两个框架的Session处理机制完全不一样，用户在一端登录后，另一端完全感知不到。

我这个项目的解决方案是让两个框架的鉴权体系完全解耦，统一走JWT鉴权。用户在Laravel端通过登录接口获取JWT token，之后所有请求（无论打到TP端还是Laravel端）都携带这个token，两端各自解析token获取用户身份。

// Laravel端JWT生成 public function login(Request $request) { $credentials = $request->only('username', 'password'); if (!$token = Auth::guard('api')->attempt($credentials)) { return $this->error('invalid_credentials', '用户名或密码错误'); } return $this->success(['token' => $token]); }

TP端原本没有JWT解析能力，我写了一个简单的中间件，用同样的密钥解析token的payload部分，然后从Redis中读取用户信息。这里有个经验：JWT的签名密钥必须统一配置，最好放在单独的配置文件中，同时在两端保持一致，否则会出现一端能解析一端解析不了的诡异问题。

4.2 事务与锁冲突导致的死锁

第一次压测时就遇到了死锁问题。情况是这样的：用户批量选座时，系统会在一个事务内批量插入多条SeatLock记录，多个请求并发下，如果请求A先锁了座位1再锁座位2，请求B先锁了座位2再锁座位1，两个请求就会互相等待对方的锁释放，形成死锁。

MySQL检测到死锁后会自动回滚其中一个事务，并抛出Deadlock found的错误，但业务上这会导致一方的选座请求直接失败。我的解决办法是在SQL层面统一加锁顺序：

// 对座位ID列表进行排序，保证所有请求按照相同的顺序加锁 $seatIds = collect($request->input('seat_ids'))->sort()->values()->all(); // 先按顺序查出对应座位记录并锁定 SeatLock::where('schedule_id', $scheduleId) ->whereIn('seat_id', $seatIds) ->orderBy('seat_id') ->lockForUpdate() ->get();

因为所有请求都按座位ID从小到大加锁，所以永远不会有互相等待的情况发生，从根源上消除了死锁。这一点在写任何涉及批量加锁的事务逻辑时都应该强制遵守。

4.3 列表页性能瓶颈

开发阶段没觉得影片列表慢，但数据量上了5万条之后，分页查询越来越慢，一条列表SQL要跑两秒。排查后发现问题出在ORDER BY的字段没有索引。

-- 优化前：慢查询，排序字段无索引 SELECT * FROM schedules WHERE movie_id = 123 AND status = 1 ORDER BY start_time LIMIT 10 OFFSET 0; -- 优化后：走联合索引 ALTER TABLE schedules ADD INDEX idx_movie_status_time (movie_id, status, start_time);

加了联合索引后，查询速度直接从1.8秒降到了20毫秒。这个经验同样适用于订单列表、支付流水列表这些高频查询场景，索引设计真的不能偷懒。

4.4 订单状态不一致问题

有一段时间频繁出现用户反馈“已支付但订单显示待支付”的情况。排查后发现，问题出在支付回调处理时，业务逻辑在事务中执行了外部API调用（比如请求支付平台查询订单状态），导致事务长时间持有连接，在高并发下连接池被打满，部分回调处理失败。

解决方案很简单：把所有外部API调用全部移出事务。先通过事务更新本地流水和订单状态，提交成功后，再用队列异步调用外部接口做后续动作。这样事务的持有时间大大缩短，数据库连接压力显著下降，回调失败率也降到了零。

另一个状态不一致的来源是缓存。当时订单详情页做了Redis缓存，但支付成功后没有主动清理缓存，导致用户看到的还是待支付的旧数据。这个问题的修复也简单，在状态流转方法里，每次状态更新后都主动清理对应的订单缓存。

5. 部署上线与性能优化实践

5.1 环境准备与部署要点

部署环境用的是经典LNMP架构：CentOS 7、Nginx 1.20、PHP 7.4、MySQL 8.0、Redis 6.2。两个框架的部署目录分开，各自有自己的FPM进程池，避免互相影响。Nginx配置里通过location路径区分请求转发到哪个框架。

PHP 7.4是当时两个框架都比较好兼容的版本，如果要用PHP 8.0以上，Laravel 8以下的老项目会有兼容性问题。这里一个很实际的建议：生产环境不要用最新的PHP版本，最好选用框架官方文档明确支持且已经经过社区验证的稳定版本。

部署时还要注意设置好两个框架的日志路径。我习惯把日志统一放到/data/logs/目录下，按框架分目录存储，同时做了日志按天切割。排查故障时能快速定位是哪个框架报的错，不至于在茫茫日志里翻半天。

5.2 高并发场景下的性能优化策略

项目上线后我做了压测，当时就发现几个性能瓶颈，这里我把优化点列出来：

第一是数据库连接池。Laravel默认的事务处理方式下，每个请求都会创建新的数据库连接，压测到500并发时连接数就到了上限。解决办法是在框架配置里开启持久连接，同时调整MySQL的max_connections参数。这里我提醒一下：不用迷信连接池中间件，单机部署场景下PHP-FPM的进程数本身天然限制了并发连接数，调优FPM的pm.start_servers和pm.max_children往往比引入额外中间件更有效。

第二是热点数据缓存。票房排行、即将上映预告这些首页数据，每次请求都查数据库完全没有必要。我将这些接口的数据缓存时间拉长到30分钟，只在后台发布新影片或修改场次时主动清除缓存。这样首页接口的QPS从3000降到不到100次实际数据库查询。

第三是Redis直连优化。最初我的锁实现里每次锁座操作要调用十几次Redis命令，后来利用Redis的pipeline功能，一次性把所有SETNX命令打包发送，网络Round Trip从十几次降到了1次，锁座接口的响应时间缩短了近200毫秒。

6. 项目扩展思路与经验心得

6.1 功能扩展方向

做完这个基础版本后，我其实还规划了几个更有意思的扩展点，虽然没有全部落地，但思路是可以分享的。

第一个是选座页面的图形化展示。目前的座位状态查询还是单纯的文字列表，实际影院场景需要前端根据影厅布局数据渲染出可视化的座位图，区分普通座、情侣座、无障碍座，还要处理过道、走廊、预留座位这些特殊区域。这个需求里，后端需要额外提供影厅布局数据接口，返回每个座位的行列坐标和类型属性。

第二个是预售和秒杀场景。热门影片的首映场次经常会出现大批用户同时抢座的情况，当前的设计在几千并发下能扛住，但如果是几万的瞬时流量，Redis锁方案会面临锁等待加剧的问题。更优的方案是引入消息队列削峰，把锁座请求先放入队列异步处理，但代价是用户在体验上会有一个短暂的等待动画。

第三个是会员体系和营销工具。积分抵扣票价、优惠券、会员折扣这些都可以做，但要注意它们都会影响订单价格计算逻辑，所以在订单模块设计的时候就要把价格计算独立成服务，不要硬编码在控制器里。

6.2 踩坑经验总结

最后整理一下我做这个项目时踩过的几个印象深刻的坑，希望能帮大家少走弯路：

静态资源的跨域问题。TP端和Laravel端分别部署在不同端口后，前端调用接口时遇到了跨域限制。虽然可以简单地在Nginx层配置允许跨域，但更规范的方案是在Laravel端加一个全局的CORS中间件，统一处理跨域响应头。只要配置一次，之后所有接口都能正常调用。

日期时间字段的时区问题。刚开始运营时出现过几次“用户下单5分钟后座位没释放”的投诉，排查后发现是因为框架时区配置不一致，一个框架存的是UTC时间，另一个框架读出来用了默认的PRC时间，导致锁座过期时间的判断出现偏差。解决方案是在两个框架的配置文件里都统一设置时区为PRC，数据库连接也显式指定时区，从源头杜绝这个问题。

缓存穿透问题。有一次某个场次的数据被恶意轮询刷接口，一个不存在的场次ID反复请求，每次都穿透到数据库，导致数据库负载飙升。后来在缓存查询前面加了一个布隆过滤器，并且对不存在的ID也缓存一个空值标记，才把这个问题压下去。

双框架的日志链路追踪。线上排查问题时经常遇到这种情况：同一个用户请求在TP端和Laravel端各打了一条日志，但因为日志格式和ID不一致，很难把两段日志串联起来。我的解决办法是自定义了一个全局唯一的请求ID，在中间件中生成后写入日志上下文，同时在接口响应头里带上这个ID，这样无论是看日志还是看响应头，都能快速定位到同一个请求在两端的所有日志。

这个项目整体做下来，最深的体会是：选座和订票这类业务，表面上拼的是框架用法和接口设计，本质上拼的是对并发控制、事务边界、缓存策略这些底层原理的理解深度。框架只是一个工具，怎么把工具用好，在关键时刻做出正确的技术决策，才是真正体现一个后端工程师价值的地方。