企业官网建设流程全解析

写过 PHP 的朋友，多半都听过这类吐槽：PHP 是脚本语言，QPS 上不去，高并发要靠堆机器，生命周期太短，每一次请求都得重新“从零开始”。这话一半对一半错。QPS 确实是衡量 PHP 应用吞吐能力的核心指标，但瓶颈到底出在生命周期的哪一段，很多人其实没有真正拆开看过。我这些年排查过不少 PHP 性能问题，最有用的一个习惯就是把一次请求的完整生命周期拆解开，像庖丁解牛那样，把启动、编译、执行、关闭每一段单独拎出来量化，再谈优化。这篇文章就按这个思路来写：先讲清楚 QPS 的内在与 PHP 生命周期之间的因果关系，再逐层拆解每个阶段的时间成本，最后给出可以直接落地的调优手段和排查手册。不管你是被线上报警逼着查性能的运维，还是在本地写完接口被领导问“能不能撑住活动流量”的开发，这篇文章应该都能帮到你。

1. 先建立整体认知：QPS 的数学本质与 PHP 的宿命

1.1 QPS 到底是什么：一条公式看透吞吐能力

QPS（Queries 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~3ms，FPM 调度和请求初始化占 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 降到了 20ms，QPS 直接涨了六倍。当然实际项目不会全都脱离框架重写，但这个实验足以说明启动阶段占了多少资源。所以提升 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.enable=1 opcache.enable_cli=0 opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=1 opcache.revalidate_freq=60 opcache.interned_strings_buffer=32 opcache.fast_shutdown=1 opcache.enable_file_override=1

注意这里的validate_timestamps=1是为了本地开发调试方便，线上如果代码通过发布系统部署，可以改成 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_user=www

preload.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 高频问题速查表：卡住了先查这几项

这里我把实战中遇到的高频问题和排查手段整理成一张速查表，方便你在工单式排查时对照：

其中pm.max_requests值得单独提一下。它是 FPM 的一个安全阀：指定一个 worker 处理多少个请求后自动重启。PHP 本身不是长期运行的，但 FPM worker 是长驻的，有些扩展或者旧代码会有轻微内存泄漏，时间长了内存水涨船高。我通常设成 5000~10000，配合 oplog 监控，既能保持相对稳定又能定期清理泄漏。不过设得太小会频繁创建销毁 worker，反而带来调度开销。

5.3 容易误解的三个操作，别越调越差

首先是最常见的行为：盲目调大pm.max_children。很多人觉得“并发不够就多开进程”，结果进程数翻倍之后，CPU 上下文切换开销变大、内存打满、磁盘 swap，QPS 反而显著下降。加大进程数的前提是确认 CPU 还有余量、内存足够，并且经过实时压测验证，不要靠猜。

第二个是关闭 OPcache 来“省检查文件修改时间”。你把opcache.validate_timestamps=0必须配合发布流程去主动清理缓存，否则线上代码更新后不生效。我见过一个小团队因为没做这一步，上线了半个月发新版本毫无反应，所有人都在查代码，最后才发现是缓存过期策略没搞对。

第三个是迷信“把 PHP 代码全改成常驻内存就万事大吉”。Swoole 常驻化之后，全局变量的副作用、连接的单例复用、循环引用导致的内存泄漏都会被放大，如果团队没有异步编程和内存管理的经验，改造后的稳定性可能还不如 FPM 模型。要根据团队实力和业务形态选择方案，不要为了性能牺牲可维护性。

把这些拆解完，我最大的感受是：PHP 的 QPS 不是靠某一个“神级配置”就能突飞猛进的，它取决于你对生命周期每一段开销的控制精度。我自己的习惯是每次接受一个新的性能优化任务，都先画一张“生命周期时间账本”，把各阶段耗时填上去，再决定从哪里下手。绝大多数项目做完了 OPcache 调优、FPM 参数修正和框架引导减重这三板斧，QPS 都能翻一倍以上，而这些改动都不需要重写业务代码。如果你手里的项目正好遇到吞吐瓶颈，不妨也先按这个思路拆一遍，把时间账本摆上桌，问题往往自己就浮出来了。