写过 PHP 的朋友多半都听过这类吐槽PHP 是脚本语言QPS 上不去高并发要靠堆机器生命周期太短每一次请求都得重新“从零开始”。这话一半对一半错。QPS 确实是衡量 PHP 应用吞吐能力的核心指标但瓶颈到底出在生命周期的哪一段很多人其实没有真正拆开看过。我这些年排查过不少 PHP 性能问题最有用的一个习惯就是把一次请求的完整生命周期拆解开像庖丁解牛那样把启动、编译、执行、关闭每一段单独拎出来量化再谈优化。这篇文章就按这个思路来写先讲清楚 QPS 的内在与 PHP 生命周期之间的因果关系再逐层拆解每个阶段的时间成本最后给出可以直接落地的调优手段和排查手册。不管你是被线上报警逼着查性能的运维还是在本地写完接口被领导问“能不能撑住活动流量”的开发这篇文章应该都能帮到你。1. 先建立整体认知QPS 的数学本质与 PHP 的宿命1.1 QPS 到底是什么一条公式看透吞吐能力QPSQueries Per Second翻译过来是“每秒查询数”严格说它衡量的是系统每秒能处理的请求数量。很多人把它和并发数混为一谈这俩根本不是一回事。并发数是指同一时刻有多少请求在系统里“排队处理”而 QPS 是单位时间内处理完毕的请求总数。计算机领域有个非常经典的关系式QPS 并发数 / 平均响应时间变形一下就是并发数 QPS × 平均响应时间。我举个例子你就明白了。假设一个接口平均响应时间是 200ms如果系统当前只有 1 个并发请求在跑那 QPS 就是 1 / 0.2 5如果你希望 QPS 达到 50那单实例需要承担的并发数就是 50 × 0.2 10也就是说同一个时刻你得允许 10 个请求同时处理。顺着这个公式往下推优化 QPS 只有两条路要么提高并发处理能力加进程、加机器、改异步要么缩短平均响应时间优化代码、减少 IO、降低生命周期内的无效开销。PHP 的处境很特殊。传统的 PHP-FPM 模式是一个请求独占一个 PHP 进程请求处理完进程就空闲或退出进程内部的状态几乎不共享。这种“一个请求一个进程”的模型导致了两个结果并发能力完全靠进程数硬撑而每个请求又必须完整经历从启动到关闭的全过程响应时间里包含了大量“重复劳动”。所以QPS 上不去很多时候并不是 PHP 引擎本身算得慢而是生命周期里的固定开销太多了。1.2 常驻内存语言为什么“天生占便宜”把 PHP 和 Go、Java 这类常驻内存方案对比差异会非常明显。Java 的 JVM 启动一次很重但启动完之后可以长期运行Spring Boot 应用接收请求时类已经加载好了字节码已经编译成机器码了线程池里的线程随时待命请求进来只需要走业务逻辑这一段。Go 的 goroutine 更是轻量协程调度器把并发的成本压到了极低。PHP 传统模型则相反每次请求进来PHP-FPM 要从零开始执行 PHP 脚本的生命周期。这里面有四个阶段模块初始化MINIT、请求初始化RINIT、脚本执行RSCRIPT、请求关闭RSHUTDOWN。虽然 OPcache 能把“编译”这一步缓存起来但请求初始化和关闭时大量的符号表创建、变量注册、扩展初始化工作每一项都得重新来一遍。框架越重启动阶段的耗时就越明显。一个加载了完整 Laravel 或者 ThinkPHP 的应用空跑一遍容器初始化、服务提供者注册、路由匹配可能就要消耗几十毫秒——这个时间在 Go 里可能已经处理完整个业务了。但这不是 PHP 的“原罪”而是模型选择的结果。PHP 的优势在于简单直接改完代码立刻生效不需要编译重启进程模型天然隔离一个请求挂了不会拖垮整个服务。理解了这两种模型的取舍你就知道优化 PHP 的 QPS核心思路不是把 PHP 变成常驻语言而是把生命周期里那些“非业务成本”压缩到最低该省的省该跳过的跳过。1.3 庖丁解牛的切入点把一次请求拆成时间账本我之所以强调“拆解”是因为实际排查性能问题时绝大多数人都卡在“凭感觉优化”。一会儿怀疑数据库慢一会儿觉得 Redis 不行一会儿又怪云厂商的机器性能差最后折腾一圈慢日志一开发现 80% 的时间花在框架初始化上。所以正确的思路是先记账后优化。一次 PHP 请求的完整生命周期在时间轴上可以大致分成这几段网络接收请求、PHP-FPM 分配进程、PHP 引擎初始化请求上下文、自动加载类文件、执行应用代码路由解析、业务逻辑、数据库/Redis 调用、模板渲染、返回响应、进程回收清理。接下来我们就顺着这条时间轴一段一段地拆看看每一段到底消耗什么资源又是如何影响最终 QPS 的。2. 生命周期全景解剖从进程启动到请求关闭的每一帧2.1 先说进程模型PHP-FPM 管理下的三个生命周期很多人把 PHP 生命周期理解成“脚本从上到下执行一行行代码”这个理解太浅了。实际上 PHP 的生命周期是分层级的至少有三层第一层是 SAPI 生命周期也就是 PHP-FPM 进程本身从启动到退出的过程。PHP-FPM 启动时读取 php.ini、加载扩展、初始化共享内存池然后 fork 出一批 worker 进程。worker 进程常驻内存每处理完一个请求后并不退出而是继续等待下一个请求——这点常被误解PHP-FPM 的 worker 确实会复用真正“每次新建”的是请求级上下文不是进程本身。第二层是请求级生命周期。一个 HTTP 请求进来worker 进程开始处理初始化请求对象、创建符号表、注册超全局变量$_GET、$_POST、$_SERVER 等、执行脚本、然后销毁这些变量。这部分是每个请求都逃不掉的固定成本。第三层是脚本级生命周期也就是你的 PHP 代码里面类的加载、函数的定义、全局变量的初始化、框架容器构建、数据库连接建立等等。这一层跟业务代码直接相关弹性最大。打个比方FPM worker 就像酒店里常驻的服务员请求就是客人。服务员进程不会因为客人走了就消失但每来一位客人都要重新倒茶请求初始化、重新点菜脚本执行、客人离开后重新收拾桌子请求关闭。酒店运营效率的高低既要看服务员数量够不够也要看每桌服务动作是否利索。2.2 四个阶段具体干什么MINIT、RINIT、RSCRIPT、RSHUTDOWN按 PHP 源码的划分请求执行会依次经过四个阶段。我逐个说一下每个阶段干了什么、成本有多高。模块初始化阶段MINIT发生在 FPM worker 启动时美团仅执行一次。这个阶段做的事情包括注册扩展、初始化扩展内部数据结构、加载 php.ini 配置项。我们常说的“加载扩展多导致内存占用高”指的就是这个阶段。要注意的是由于 OPcache 的存在PHP 脚本的编译并不仅不在这里完成。等到 worker fork 完成之后MINIT 已经做完了。请求初始化阶段RINIT是每次请求都要执行的。它会初始化执行环境、创建符号表、注册 $_GET/$_POST/$_COOKIE/$_SERVER 等预定义变量。如果你的 PHP 装了很多扩展比如 mysqlnd、curl、gd、openssl 等每个扩展在这个阶段都要执行自己的请求初始化逻辑积累起来是相当可观的时间成本。实测过一个装了 30 扩展的 PHP 环境单次请求初始化能比干净环境多花 2~4ms。脚本执行阶段RSCRIPT就是真正跑你的代码。这里有两个子阶段执行前的编译——把 PHP 代码编译成 opcode编译后的执行——Zend 引擎逐条执行 opcode。没有 OPcache 的时候每次请求都要重新编译一份 opcode有了 OPcache编译结果缓存在共享内存命中之后直接跳过编译。请求关闭阶段RSHUTDOWN做清理工作调用对象的析构函数比如数据库连接的析构会释放连接、清理符号表、释放请求级内存、把响应发送给客户端。如果代码里有注册 register_shutdown_function也会在这个阶段被调用。很多人忽视这个阶段但它同样消耗时间尤其是框架里注册了一堆 shutdown 钩子时。2.3 实测量级各阶段时间的分布规律根据我自己的压测经验给一个典型参考值在 PHP 8.1 PHP-FPM OPcache 开启的情况下一个最简单的“Hello World”接口不走框架、不连数据库平均响应时间大约 5~15ms。拆开来看网络传输占 1~3msFPM 调度和请求初始化占 2~5ms脚本执行占 1~3ms请求关闭占 1~2ms。同一个环境换成 Laravel 空路由加载框架但不连数据库响应会膨胀到 30~80ms。多出来的 20~60ms 几乎都花在 RSCRIPT 阶段的框架启动上Composer 自动加载、服务容器构建、门面别名注册、路由收集等等。如果我们把环境里的数据库查询、Redis 调用、第三方 HTTP 请求加进去执行阶段可能继续膨胀到几百毫秒甚至秒级。所以一个朴素的结论是QPS 的敌人先是框架启动然后是 IO 等待最后才是 PHP 引擎本身的计算。3. 生命周期各阶段对 QPS 的具体影响链路3.1 启动阶段为什么框架越重QPS 掉得越快启动阶段是 PHP 应用最容易“藏时间”的地方。以 Composer 的自动加载机制为例当你访问 Laravel 入口文件 public/index.php 时第一行 require 的 vendor/autoload.php 会注册 PSR-4 自动加载器。之后每 new 一个类PHP 就要触发一次 autoload 回调由 Composer 去查找对应的 classmap 或者目录规则找到后再 include 文件。这个查找过程本身不慢但如果框架在引导阶段一连串加载几十个甚至上百个服务提供者类累加起来就是几十次文件 IO 和类解析。更隐蔽的是服务容器的构建。Laravel 在 bootstrap 阶段要做的工作包括检测环境、加载配置文件.env 解析、注册服务提供者、执行服务提供者的 register 和 boot 方法、注册路由、解析中间件。每一步都涉及实例化对象和闭包绑定。Laravel 还引入了一个“容器”概念大量的服务通过依赖注入解析依赖越多反射和递归解析的开销越大。我曾经把一个业务系统的入口脚本从 Laravel 的 index.php 替换为手写 Router 原生 PDO同一个业务逻辑查数据库返回 JSON响应时间从 120ms 降到了 20msQPS 直接涨了六倍。当然实际项目不会全都脱离框架重写但这个实验足以说明启动阶段占了多少资源。所以提升 QPS 的第一步永远是审视框架引导链路能预加载的预加载能延迟实例化就延迟实例化不用的服务提供者果断去掉这比优化任何业务 SQL 都来的更立竿见影。3.2 编译阶段OPcache 的命中率决定了你的 CPU 成本如果把 PHP 代码看成“原材料”那 opcode 就是“加工后的半成品”。每次请求都重新把源码解析成 opcode 是非常昂贵的操作——词法分析、语法分析、生成抽象语法树、再转换为 opcode 指令序列这个过程比单纯执行 opcode 要慢得多。OPcache 的存在就是为了跳过这个过程它把编译后的 opcode 缓存到共享内存里后续请求直接复用。但 OPcache 不是开了就万事大吉。有几个关键细节很容易踩坑第一opcache.max_accelerated_files默认值可能不够用当你项目里的 PHP 文件数量超过这个上限OPcache 就开始清理旧的缓存条目然后后续请求触发重新编译导致性能抖降。第二opcache.validate_timestamps默认开启时OPcache 每次都会检查文件修改时间mtime这个检查本身就是 stat 系统调用文件多了成本也不小。我平时线上环境会把opcache.validate_timestamps设成 0配合发布流程中的restart_fpm或者opcache_reset()来更新缓存性能提升非常明显。还有一个容易被忽略的点预加载Preload。PHP 7.4 以后引入了 opcache.preload 机制允许在 FPM 启动阶段把指定的类和函数一次性加载到共享内存中并且这些类可以常驻在 worker 进程的 opcode 缓存里之后请求中 new 这些类时连文件读取和类定义都省了。我负责过的一个项目把框架底层的容器类、路由类、数据库门面等核心类放进 preload 脚本压测平均响应时间又降了 8%~15%。不过预加载有个麻烦如果代码更新了需要重启 PHP-FPM 进程才生效所以它更适合底层的、不怎么变动的框架代码不适合频繁迭代的业务类。3.3 执行阶段阻塞等待才是 QPS 的最大杀手生命周期里执行阶段占据的绝对时间最长而执行阶段里最耗费时间的往往不是 CPU 计算而是阻塞等待。数据库查询、Redis 读写、远程 HTTP 调用、文件读写任何一个操作只要阻塞了PHP 进程就只能傻等。用一个生活化类比解释你开了一家奶茶店店里就你一个员工。顾客点单你去做奶茶时后面的顾客就只能在柜台前排队。PHP-FPM worker 也是一样一个 worker 同一时间只能处理一个请求如果这个请求卡在慢查询上 500ms这 500ms 里 worker 是“瘫痪”的QPS 自然上不去。这就解释了为什么同样逻辑用 Go 写并发能力更强Go 可以在一个操作等待 IO 时以极低成本切换去处理另一个请求本质上靠的是用户态协程调度而 PHP-FPM 只能靠增加进程数量来抵抗阻塞。所以对 PHP 来说降低阻塞等待是提升 QPS 最有效的路径。具体手段包括数据库慢查询优化、Redis 批量 pipeline、异步任务队列化把耗时的发送邮件、生成报表等丢到队列、HTTP 客户端的超时设置防止第三方接口拖死进程等等。执行阶段的另一个隐形问题是重复计算。比如循环里写 SQL、foreach 里调用远程接口、每次请求都重新加载同样的配置数组等等。每减少一次不必要的执行都是在直接降低平均响应时间从而按 QPS 公式的倒数关系抬高吞吐量。3.4 关闭阶段析构、连接释放与 session 写入很多人对请求结束完全不设防觉得“代码跑完就完事了”但关闭阶段同样影响 QPS。一个典型场景是 Session 处理默认 PHP Session 是文件存储每次请求结束时会持有 session 写入锁把 session 数据序列化写入文件。如果同一个用户并发发起两个请求第二个请求还会在 session 锁上等待第一个请求释放锁——这就是为什么高并发场景建议把 session 换成 Redis 甚至直接无状态化。再一个常见开销是数据库连接释放。虽然 mysqli/PDO 的析构函数会自动关闭连接但在云数据库场景下频繁建立连接、关闭连接会产生大量握手成本。这个问题的解法不是在代码里显式断开而是要引入连接池组件比如 Swoole 的连接池或者通过 pgbouncer 等外部数据库连接池中间件尽量让请求复用已有连接。就我们压测的数据启用数据库连接池后一个短查询接口的 QPS 大约能提升 20%~40%因为有相当一部分时间本来浪费在 TCP 握手和 MySQL 认证上。关闭阶段还涉及输出缓冲。如果代码里用了 ob_start() 输出缓冲请求结束时会触发缓冲内容输出也可能触发 header 写入等操作。如果响应体很大网络发送也会算到请求时间里。凡是能压缩的开启 gzip/br能精简的减少不必要的响应字段都可以降低这部分的耗时。4. 基于生命周期拆解的 QPS 提升三板斧4.1 第一板斧把 OPcache 和预加载配置到最优先给一份我常用的 OPcache 配置模板PHP 8.1 环境实测稳定; php.ini 或 php.d/opcache.ini opcache.enable1 opcache.enable_cli0 opcache.memory_consumption256 opcache.max_accelerated_files20000 opcache.validate_timestamps1 opcache.revalidate_freq60 opcache.interned_strings_buffer32 opcache.fast_shutdown1 opcache.enable_file_override1注意这里的validate_timestamps1是为了本地开发调试方便线上如果代码通过发布系统部署可以改成 0 然后配合发布后调用opcache_reset()。max_accelerated_files的取值怎么定你可以在服务器上执行这个命令统计项目里 PHP 文件总数find /www/wwwroot/你的项目 -name *.php | wc -l把这个数字往上加 30% 余量再填进去比如统计出来是 12000就设成 20000 这样。太低了会出现缓存频繁逐出太高了浪费共享内存。再说预加载脚本。在 php.ini 里加上opcache.preload/www/wwwroot/你的项目/preload.php opcache.preload_userwwwpreload.php的内容大致长这样?php // 预加载只负责加载类不能执行带有副作用的初始化代码 $files [ /www/wwwroot/你的项目/vendor/laravel/framework/src/Illuminate/Container/Container.php, /www/wwwroot/你的项目/vendor/laravel/framework/src/Illuminate/Routing/Router.php, // ... 把框架核心类都列进来 ]; foreach ($files as $file) { opcache_compile_file($file); }用opcache_compile_file()而不是require的好处是只把文件编译进缓存并注册类但不执行文件里的函数定义之外的动作比如不触发类的常量定义和静态变量初始化——这符合启动阶段“预加载但不运行”的语义。配置完成后重启 PHP-FPM用opcache_get_status()查看preload_statistics确认类加载是否成功。这个配置执行一次后续所有 worker 进程 fork 时自动继承效率非常高。4.2 第二板斧PHP-FPM 进程模型调优FPM 的配置直接决定并发能力是最需要“按机器定参数”的部分。核心配置在php-fpm.conf的 pool 段也就是 www.conf。pm有三种模式static固定子进程数、dynamic动态伸缩、ondemand按需启动。对线上稳定业务我建议用static。为什么因为dynamic模式下的 min/max 伸缩会带来进程创建和销毁的开销高峰期 spawn 进程本身就是耗时操作而且不好预测。静态固定数量后所有 worker 常驻请求来了直接处理没有 fork 抖动。pm.max_children的计算方法先看一下服务器内存情况假设你机器是 8GB当前业务平均一个 PHP-FPM worker 占 80MB 内存通过ps aux | grep php-fpm查看 RSS 列估算正规方法是ps -ylC php-fpm | awk {print $8} | sort -n看均值和最大值。留出 1GB 给系统、MySQL、Redis 等剩余 7GB 除以 80MB大约能开 85 个左右。公式是max_children (总内存 - 系统预留内存 - 其他服务内存) / 单进程平均内存注意单进程内存峰值可能比平均高很多尤其是跑内存密集型操作时所以建议按平均值的 1.5~2 倍估算宁少勿多。开了太多 worker 导致内存耗尽触发 OOM反而会让 QPS 归零。再来是request_terminate_timeout。这个参数非常关键它相当于一个看门狗单个请求执行超过指定秒数直接终止。我习惯设成 30s太大起不到保护作用太小会把本来能通过慢查询优化解决的请求直接掐死。配合request_slowlog_timeout设为 5s并开启慢日志slowlog /var/log/php-fpm-slow.log request_slowlog_timeout 5s request_terminate_timeout 30s这样哪个请求超过 5 秒没处理完会记录当时的调用栈到慢日志。上线这套后我经常能抓到一些匪夷所思的慢调用——比如某天一个接口慢慢日志里直指 curl 扩展在等待一个外部页面返回超时 120 秒直接把 worker 占死了五个小时一看后台队列堆了几十万条任务。这要是没开慢日志光靠猜不知道要排查到什么时候。4.3 第三板斧业务与框架层的生命周期减重配置调优能保底但真正决定 QPS 上限的还是业务代码和框架装配。这条做起来不如改配置那么“爽”但收益最持久。第一个减重方向服务提供者的按需加载。以 Laravel 为例config/app.php里的 providers 数组里有一堆框架自带和扩展包的 provider很多压根用不上比如Illuminate\Encryption\EncryptionServiceProvider、Illuminate\Hashing\HashServiceProvider。我见过一个项目里装了 Laravel Debugbar 却开着生产环境Debug 相关的 provider 每个请求都在执行白吃了几毫秒。把这些用不到的 provider 注释掉是零风险纯收益。第二个方向路由缓存。Laravel 可以用php artisan route:cache把路由编译成缓存文件避免每次请求都重新加载所有路由文件。ThinkPHP 也有相应的路由缓存配置。这个操作对大型应用能省下 10~30ms 的启动时间。注意如果路由里包含闭包定义route:cache 会报错需要先把闭包改成控制器方法。第三个方向减少自动加载的文件数量。Composer 的classmap-authoritative模式值得开启在 composer.json 中设置{ config: { classmap-authoritative: true } }开启后 Composer 不再扫描 PSR-4 目录而是严格按照生成的 classmap 查找类。副作用是如果你部署了不存在的类文件它会直接报错而不会自动扫描到。好处是每次类加载少了目录扫描和文件存在性判断显著减少启动阶段的文件 IO。如果项目允许甚至可以进一步引入 Swoole / Workerman 这类常驻内存方案。让 PHP 进程像 Java 一样启动一次、循环处理请求生命周期里的启动和关闭成本只在首次发生后续请求只需要走执行阶段。这个改造工程量不小但确实是 PHP 突破 QPS 天花板最彻底的一条路。我部署过一个基于 Swoole HTTP Server 的 Gateway 服务同一个业务逻辑压测 QPS 比 FPM 模式提高了将近 5 倍。不过 Swoole 是协程异步模型写惯 FPM 同步代码的团队需要一段适应期管理连接和全局状态的方式完全不同。5. 常见问题与排查技巧实录5.1 怎么快速定位瓶颈在生命周期的哪一段最快的方法是开 PHP-FPM 慢日志看栈这个我前面已经提过。除此之外还有两个百试不爽的手段。第一个是压测找锚点。用ab或者wrk直接压一个最简单的接口入口文件里只放echo Hello压出来的 QPS 就是环境天花板。然后用同样的环境加一个空框架路由对比 QPS 下降了多少。再用一个带数据库查询的业务逻辑继续对比。三轮对照下来哪一段吞噬的 QPS 最多一目了然。我上次做性能体检就是这么干环境天花板 QPS 是 1800加上 ThinkPHP 框架空路由变成 900再加两个 SQL 查询变成 300。瓶颈根本不在数据库在框架初始化的那 50ms。第二个是给耗时打点。代码里用monolog或者简单的microtime(true)记录时间戳分别在入口文件开头、框架 bootstrap 完成、路由解析完、业务逻辑开始、响应输出前各打一个点打成结构化日志。分析日志中相邻点的时间差就能画出生命周期内的时间瀑布图。这个办法特别适合排查“接口不慢但整体慢”的诡异问题——我曾经用打点法发现响应时间里有 20% 花在不应该存在的响应体 gzip 压缩上因为入口文件里写了ob_start(ob_gzhandler)哪怕响应才几 KB 也会强制压缩。5.2 高频问题速查表卡住了先查这几项这里我把实战中遇到的高频问题和排查手段整理成一张速查表方便你在工单式排查时对照症状生命周期阶段优先检查项QPS 整体偏低CPU 也没跑满RINIT/RSCRIPT扩展数量是否过多、框架引导太重重、自动加载文件过多QPS 周期性掉坑波动明显OPcache 阶段opcache.max_accelerated_files是否不足、是否开validate_timestamps且 revalidate 频繁接口平时快高峰期突然崩进程调度阶段FPMpm.max_children是否过小listen.backlog是否已满某个接口把大量 worker 拖死RSCRIPT 执行阶段慢日志定位到阻塞点查外部调用超时和数据库慢查询请求结束后卡滞明显RSHUTDOWN 阶段session 文件写入锁、shutdown function 里有耗时操作、连接关闭握手频繁内存持续增长最终 OOMworker 常驻阶段pm.max_requests是否设置单个 worker 内存泄漏未回收其中pm.max_requests值得单独提一下。它是 FPM 的一个安全阀指定一个 worker 处理多少个请求后自动重启。PHP 本身不是长期运行的但 FPM worker 是长驻的有些扩展或者旧代码会有轻微内存泄漏时间长了内存水涨船高。我通常设成 5000~10000配合 oplog 监控既能保持相对稳定又能定期清理泄漏。不过设得太小会频繁创建销毁 worker反而带来调度开销。5.3 容易误解的三个操作别越调越差首先是最常见的行为盲目调大pm.max_children。很多人觉得“并发不够就多开进程”结果进程数翻倍之后CPU 上下文切换开销变大、内存打满、磁盘 swapQPS 反而显著下降。加大进程数的前提是确认 CPU 还有余量、内存足够并且经过实时压测验证不要靠猜。第二个是关闭 OPcache 来“省检查文件修改时间”。你把opcache.validate_timestamps0必须配合发布流程去主动清理缓存否则线上代码更新后不生效。我见过一个小团队因为没做这一步上线了半个月发新版本毫无反应所有人都在查代码最后才发现是缓存过期策略没搞对。第三个是迷信“把 PHP 代码全改成常驻内存就万事大吉”。Swoole 常驻化之后全局变量的副作用、连接的单例复用、循环引用导致的内存泄漏都会被放大如果团队没有异步编程和内存管理的经验改造后的稳定性可能还不如 FPM 模型。要根据团队实力和业务形态选择方案不要为了性能牺牲可维护性。把这些拆解完我最大的感受是PHP 的 QPS 不是靠某一个“神级配置”就能突飞猛进的它取决于你对生命周期每一段开销的控制精度。我自己的习惯是每次接受一个新的性能优化任务都先画一张“生命周期时间账本”把各阶段耗时填上去再决定从哪里下手。绝大多数项目做完了 OPcache 调优、FPM 参数修正和框架引导减重这三板斧QPS 都能翻一倍以上而这些改动都不需要重写业务代码。如果你手里的项目正好遇到吞吐瓶颈不妨也先按这个思路拆一遍把时间账本摆上桌问题往往自己就浮出来了。