2023年国庆档，基于我蹲在电脑前刷新某购票网站，的电影准备抢《坚如磐石》的购票IMAX场。页面卡了整整四分钟，网站等加载出来，论文黄金座位全灰了。基于那一刻我盯着屏幕想：这破网站到底怎么写的的电影？后来自己动手做了一个，才发现问题远比想象中具体。购票

电影购票网站的网站核心就三件事：座位别抢重、支付别掉单、论文数据别丢。基于听着简单，的电影做起来全是购票坑。我用的网站技术栈很朴素——前端HTML+CSS+JavaScript，后端PHP配MySQL，论文服务器是阿里云最便宜的那档。选座模块是整站最要命的部分。最初用轮询查座位状态，每三秒发一次请求，二十个人同时选座，数据库直接飙到CPU 100%。后来换成WebSocket长连接，前端用Canvas画座位图，每个座位绑定一个状态对象，后端只推变化的那几个座位。延迟从三秒压到两百毫秒以内。这个改动让我明白一件事：购票网站的瓶颈从来不在页面渲染，而在并发写操作。

支付环节更刺激。接的是支付宝沙箱环境，回调地址配错一次，用户付了钱订单还是待支付。排查半天发现是异步通知没做签名验证，支付宝发了三次请求全被防火墙拦了。补上verifySign方法后，又遇到重复回调——同一笔订单插了两条支付记录。解决办法是给订单号加唯一索引，回调进来先查再插，用数据库的唯一约束兜底。这事教会我：支付逻辑不能信任任何外部输入，包括支付平台自己。

数据库设计走了弯路。一开始把座位信息和场次信息塞在同一张表，查一个场次的座位要扫全表。后来拆成screening（场次）、seat（座位模板）、ticket（已售座位）三张表，ticket表只存screening_id和seat_id的关联。查询时先拿场次ID去ticket表捞已售座位，再用seat表渲染完整座位图。响应时间从1.8秒降到300毫秒。这个拆分逻辑跟电影院线下卖票一个道理——座位图是固定的，每场卖出去的是“占位标记”，不是重新画一张图。

前端有个细节值得说。移动端选座时，手指缩放座位图经常误触。我试过用touch-action: none禁用默认手势，自己写双指缩放逻辑，结果iOS和安卓的touch事件坐标不一致。最后干脆放弃自定义缩放，改回浏览器默认行为，只保留单击选座。用户反馈反而好了——没人想在买票时玩手势解谜。有时候少做比多做聪明。

压力测试用JMeter模拟了五百个并发用户同时抢《奥本海默》首映场。结果MySQL连接池爆了，报Too many connections。把最大连接数从100调到500，又出现死锁——两个事务同时更新同一场次的剩余座位数。改成Redis原子递减库存，数据库只负责最终落盘，问题消失。这套方案不新鲜，但自己踩一遍才真正理解为什么大厂都这么干。

上线后跑了三个月，日均订单两百多笔，峰值出现在周五晚八点。最离谱的一次故障是服务器时间没同步NTP，导致场次开始时间比实际早了七分钟，用户买完票发现已经“过期”。修好之后加了个定时任务，每十分钟校时一次。这种低级错误，不自己运维根本想不到。

做这个网站最大的收获不是技术多牛，而是对“买票”这件事有了肌肉记忆。现在我去任何购票平台，第一反应是看它的座位状态同步机制，第二反应是查它的支付回调日志。有次在猫眼买票，页面卡顿，我下意识按F12看Network面板，发现它在轮询一个/seat/status接口，频率是每秒一次。当时就笑了——这哥们儿肯定没试过WebSocket。