摘要：优化过一个日均百万请求的 PHP 接口：平均响应从 200ms 压到 40ms。这篇按"先测量、再动手"的顺序复盘全过程：Xdebug/XHProf 火焰图定位热点、N+1 查询的消灭、三层缓存策略（本地 APCu → Redis → HTTP 缓存）、OPcache 与 JIT 的真实收益、以及序列化开销这种容易被忽略的暗坑。关键词：PHP 性能优化、缓存、OPcache、JIT、N+1适合人群：做 PHP 后端接口优化的工程师一、测量先行：没有火焰图的优化都是玄学第一步不是改代码，是拿到耗时分布。工具选择：Xdebug（开发环境）：函数级 profile，生成 cachegrind 文件用 qcachegrind 看火焰图——精确但开销大，禁用于生产XHProf/Tideways（生产可用）：低开销采样，线上抓真实流量热点基准口径：优化前先固定压测脚本（同一接口、同一数据集、500 并发），所有数字以它为准火焰图读出的真实分布（改造前 200ms 的构成）：DB 查询（23 条，含 N+1） 120ms ← 最大头 Redis 网络 IO（逐次 get×9） 30ms 数据组装与序列化 28ms 框架与路由 15ms 其他 7ms结论一眼可见：性能问题 75% 在"数据获取"，不在"代码执行"。PHP 语言层的执行速度（升级 PHP8、开 JIT）在列表里只值 7ms——这也是后面 OPcache/JIT 收益有限的伏笔