1. PHP一次请求的完整生命周期：从模块初始化到脚本结束
1.1 五种生命周期阶段详解
很多PHPer写了好几年代码，问起"PHP是怎么跑起来的"，第一反应是"浏览器发请求，服务器执行PHP，返回HTML"。这个说法没错，但太笼统了。真实情况是，PHP每次处理请求都要经历五个阶段：模块初始化（MINT）、请求初始化（RINT）、脚本执行、请求关闭（RSHUTDOWN）、模块关闭（MSHUTDOWN）。
听着抽象，我拿一次真实的页面访问来拆解。假设你访问https://example.com/index.php，Nginx拿到请求后发现是PHP文件，通过fastcgi协议转发给PHP-FPM。PHP从收到这个请求开始：
- RINT（请求初始化）：PHP创建当前请求的运行环境，加载配置文件，注册autoload机制，初始化session模块、数据库连接模块等下发给当前请求的资源。这个阶段做的是"每次请求都要重新准备"的事。
- 脚本执行：定位到index.php文件，进行语法解析（Lex/Parse），生成opcode，然后交给Zend引擎一条条执行。你的业务代码全部跑在这个阶段，包括
require、函数调用、类定义、echo输出。 - RSHUTDOWN（请求关闭）：执行finally块、析构函数、session写入，然后释放本次请求占用的所有临时资源——没错，你在脚本里new出来的对象、连上的PDO连接、打开的临时文件，都在这个阶段被统一回收。
MINT和MSHUTDOWN则是在PHP进程刚启动（初始化Zend引擎、注册内置函数列表）和进程准备退出（释放全局资源）时各执行一次，不是每次请求都跑。
理解这五个阶段，你才能明白一个关键问题：PHP本身是无状态的，状态只能靠外部存储（Session、Cookie、数据库、缓存）来维持。因为RSHUTDOWN把请求级的资源全清了，你没法在PHP原生内存里跨请求保存任何东西。这也解释了为什么PHP不需要像Java那样担心线程间的数据竞争——每个请求都是独立、隔离、用后即焚的。
1.2 PHP与Web服务器"对话"的底层通道：SAPI
生命周期讲清楚了，再往下挖一层：PHP靠什么跟Web服务器对接？答案是SAPI（Server API）。PHP本身是一个语言解释器，它不关心前端是Nginx、Apache还是命令行，它只定义一套接口规范，只要外部环境实现了这套接口，就能把请求喂给PHP，然后拿回执行结果。
CLI和FPM就是最常用的两种SAPI形态：
- CLI（Command Line Interface）：独立的可执行程序，直接在终端跑，不依赖任何Web服务器。
- FPM（FastCGI Process Manager）：PHP官方出品的进程管理器，以独立的服务方式运行，专门对接Web服务器。
这条信息链很重要。很多人配置Nginx时会写fastcgi_pass 127.0.0.1:9000;或unix:/run/php/php8.2-fpm.sock;，这条配置的本质就是：Nginx把HTTP请求按照FastCGI协议封装好，通过TCP或Unix Socket转发给PHP-FPM，PHP-FPM里的worker进程接收、执行、把结果原路返回。
严格来说，CLI和FPM躺着的是两种完全不同的执行模型。CLI是"一个进程从生到死只服务一次请求"，FPM是"常驻进程池，一个worker进程服务完一个请求后不退出，继续接下一个"。这个差异是所有后续讨论的出发点。
2. CLI模式：单进程、单请求、用完即走的执行模型
2.1 CLI的本质：你做的一切操作都在两条命令之间
CLI模式里，PHP就是一个纯粹的命令行工具。你在终端敲php index.php，系统创建一个PHP进程，加载配置、执行index.php里的代码、输出结果、进程退出。整个过程从进程创建到资源释放，通常不到一秒。
它没有GCD机制，没有worker，没有并发，所以天然适合以下几类场景：
- 计划任务（Cron）：每天凌晨跑一次数据统计、定时发邮件、清理过期数据。写个
php /var/www/cron.php，加进crontab，完事。 - 队列消费者：比如用Laravel的
php artisan queue:work跑常驻的队列监听进程，一个进程不断从Redis队列里取任务执行。注意这种场景下是用CLI跑常驻进程，不是像Web请求那样用完即走，需要自己管理内存。 - 脚本处理：批量导入数据、批量生成报表、数据迁移。比如你从生产库导了个CSV，用
php import.php把它拆分成几万条insert打进另一个库。 - 开发调试：
php -r "echo phpinfo();"这种一句话脚本，快速验证某个函数是否存在、某个扩展是否加载。
CLI模式下，$_SERVER['REQUEST_METHOD']、$_GET、$_POST这些超全局变量全是空的（除非你解析命令行参数后手动填充）。你在Web环境下写习惯的代码，直接丢到CLI下跑，大概率会因为依赖了这些Web环境变量而报错。这是初学者最容易踩的坑。
2.2 CLI使用独立的配置域：php.ini 里的"一处修改，两处生效"
同一个PHP安装，CLI和FPM默认读的是同一份php.ini，但使用上有很多隐含差异。我举几个最典型的：
- memory_limit：Web请求通常限制128M或256M，因为每个请求都是并发的，不能让一个请求吃光内存。但CLI脚本经常需要处理大数据——比如一个脚本要从100万行Excel里读取并分组统计，128M可能不够。所以PHP官方有个约定：
memory_limit在CLI模式下默认值是-1（不限制）。如果你自己改了php.ini里的memory_limit=128M，那CLI也会被限制住，跑大脚本会直接被Allowed memory size of 134217728 bytes exhausted干掉。 - max_execution_time：同样，CLI默认是0，不限制执行时间。因为计划任务经常要跑几分钟甚至几小时，你不可能让cron脚本被30秒超时打断。但你没意识到的是，代码里如果用了
set_time_limit(1)，CLI下也会生效，脚本跑1秒就死给你看。 - error_log：CLI模式的错误默认直接输出到终端（STDERR），而FPM模式下是写到日志文件里。这意味着你在终端跑脚本时看到一堆warning，不代表线上FPM日志里也有——反过来，你在浏览器里看不到的报错，可能在php-fpm.log里躺着。
所以，修改php.ini之前，一定要先明确你是要让CLI生效还是FPM生效。最稳妥的做法是分文件配置：/etc/php/8.2/cli/php.ini和/etc/php/8.2/fpm/php.ini分开改。Debian系的PHP包默认就是这种分目录结构，为什么这样设计，你现在应该懂了。
2.3 内置Web服务器 php -S 的原理边界
CLI还有一个被低估的工具：内置Web服务器。用php -S localhost:8000就能起一个测试用Web服务。它本质上是一个用PHP自己实现的最小化HTTP服务器，底层依赖PHP内置的socket监听，每收到一个HTTP请求就当场创建一个执行环境跑PHP脚本。
但它有个硬伤：默认是单进程、串行处理。也就是说，同时来10个浏览器请求，它会一个一个处理，前面的卡住，后面的全部排队。这意味着php -S只适合三种场景：本地开发环境临时调试、给新手演示PHP到底怎么处理请求、测试不依赖复杂Web配置的路由。
还有一点：php -S默认不解析.htaccess，不支持URL重写（除非你用-t指定Router脚本自己实现）。所以如果你在开发Laravel这类需要Pretty URL的框架，php -S就不够用了，得靠php artisan serve——它其实也是用php -S起服务，但带上了一个Router文件把请求转发给index.php。
3. FPM模式：常驻进程池如何扛住高并发
3.1 从mod_php到PHP-FPM：为什么Nginx时代要换方案
在讲PHP-FPM之前，得先明白它为什么存在。早年间Apache是绝对主流，PHP以mod_php的形式作为Apache的模块加载。Apache每处理一个请求，就直接在自己进程内调用PHP解释器。这种方案的好处是"简直无缝"，坏处是Apache进程本身很重，而且每个Apache进程都要常驻一份PHP解释器。你开了30个Apache进程，就等于常驻30份PHP运行时，内存开销巨大。并发一上来，Apache进程数爆炸，服务器内存直接顶爆。
Nginx当初选择FastCGI方案，核心出发点就是剥离Web服务器和PHP解释器。Nginx只管静态文件、HTTP协议、负载均衡，遇到PHP文件就通过fastcgi协议转发给外面独立的PHP进程去处理。Web服务器和PHP完全解耦，Nginx承担轻量级并发（一个worker可以同时维护几千个TCP连接），PHP进程池则专门处理计算密集的PHP脚本。
这就是PHP-FPM诞生的场景。它实现了FastCGI协议，同时管理一个worker进程池，负责接收Web服务器转来的请求、执行、返回。你不再需要为每个请求创建一个新PHP进程，worker进程复用，请求处理完就接下一个。
3.2 master-worker架构与fastcgi通信细节
PHP-FPM的运行架构是两个层级：一个master进程 + 一堆worker进程。
- master进程做的事：读取php-fpm.conf配置、启动/停止worker、监听socket（TCP或Unix Socket）、在worker挂掉时重新拉起、执行graceful reload（重载配置时不中断现有请求）。
- worker进程做的事：真正的累活。每个worker静态持有自己的PHP运行时环境，一个worker同一时间只能处理一个请求。请求处理完，环境初始化阶段状态被重置，然后继续接收下一个请求。
从Nginx到PHP的完整链路是这样的：
浏览器 → Nginx（解析URL，识别.php后缀）→ fastcgi_pass 转发 → PHP-FPM master（监听9000端口/socket）→ 分配给空闲worker → worker执行RINT → 执行脚本 → RSHUTDOWN → 返回HTTP响应给Nginx → Nginx返回给浏览器这里有一个知识盲区：fastcgi协议本身只是通信规矩，不是进程模型。你完全可以用spawn-fcgi配合php-cgi跑一个裸的FastCGI进程，但没有PHP-FPM的自管理能力（没有进程管理、没有配置热加载、没有状态监控）。PHP-FPM的价值就是把这套进程管理做成了完善的产品。
Unix Socket vs TCP：php-fpm.conf 里的listen参数两种选择。我以前遇到过这个问题：本机通信用unix:/run/php/php8.2-fpm.sock更优，因为避免了TCP协议栈开销和端口转发；跨机通信（比如Nginx和PHP-FPM运行在不同机器上）只能走TCP，比如listen = 9000。新手最容易犯的错是：Nginx配置里写127.0.0.1:9000，但php-fpm实际监听的却是unix socket，两者对不上导致502。排查第一件事就是先ss -lntp | grep 9000或ls -l /run/php/*.sock看监听状态。
3.3 三种进程管理模式：static、dynamic、ondemand
php-fpm.conf 中最核心的配置是pm，它有三种模式，选错了性能天差地别：
| 模式 | 行为逻辑 | 适用场景 |
|---|---|---|
| static | 启动时固定创建pm.max_children个worker，数量不变 | 服务器配置固定、流量稳定、内存充裕 |
| dynamic | worker数量在pm.min_spare_servers和pm.max_spare_servers之间动态调整，峰值不能超过 max_children | 大多数云服务器，流量波动的常规业务 |
| ondemand | 平时一个worker都不启动，有请求来了才创建，闲置一段时间后回收 | 内存很紧张的VPS，或低频访问的个人站点 |
static模式的哲学是"我就要这么多，来多少都是它扛"。好处是稳定、无创建/销毁开销，坏处是高峰扛不住、低谷浪费内存。dynamic模式靠master不断计算空闲worker数来增减——这是最常用的模式，但要注意：频繁增删worker是有代价的，每个worker创建时都要完整初始化PHP运行时（几毫秒到几十毫秒），所以pm.start_servers可以稍微设大一点，减少冷启动。
ondemand模式看起来美好，但有个隐患：流量突发时，master要一边接请求一边创建worker，创建速度跟不上请求洪峰，前端就直接504了。我见过有人用ondemand跑一个500M内存的云主机，平时没问题，一到秒杀活动就崩。所以ondemand只适合"几乎没流量但如果我不小心访问了它也能正常响应"的场景。
这三个模式的参数搭配，我自己常用的经验是：4核8G服务器，跑常规Laravel应用，dynamic模式配pm.max_children=50、pm.start_servers=10、pm.min_spare_servers=5、pm.max_spare_servers=20，然后监控内存用量做微调。
3.4 关键参数与调优思路：worker不是越多越好
关于FPM性能，最经典的问题就是"pm.max_children设多大"。它直接决定并发能力——因为每个worker同一时间只能处理一个请求，并发100就需要100个worker才能同时响应。
计算方式是：单worker内存 × max_children ≤ 服务器可用内存。你先压测一下业务脚本的平均内存占用，拿pm.max_children乘以平均内存，留出操作系统和其他服务的余量。比如脚本平均吃20M内存，服务器有2G给PHP用，那max_children最多给100，多了会触发OOM Killer，直接把worker进程杀掉。
还有三个容易忽视的参数：
request_terminate_timeout：单个请求的最大执行时间。默认是0（不限制）。但如果你的PHP脚本因为死循环卡住了，worker就会被永久占用，慢慢把进程池拖垮。我会把它设成60秒，给一些极端场景兜底。代价是超长任务（比如大文件导出）可能被迫中断，这种任务应该丢给CLI队列而不是HTTP请求里做。listen.backlog：socket等待队列长度。高并发下如果太小，Nginx侧会出现connect() failed (111: Connection refused)，需要调大到1024或更高。request_slowlog_timeout+slowlog：性能排查利器。设置超过3秒的执行记录到慢日志，你能精确看到哪个脚本哪一行卡了很久，这是定位FPM性能瓶颈最直接的手段。
调优没有银弹，我的习惯是：先看pm.status模块。开启pm.status_path = /status，在Nginx里配一个location，然后访问curl http://127.0.0.1:9000/status?full，会输出当前进程池的实时状态——活跃进程数、空闲worker数、队列长度、慢请求数。这是判断进程池是否健康的最直接指标，比瞎猜参数靠谱得多。
4. CLI与FPM的关键差异对照：别再混为一谈
4.1 一张表看懂两种模式的本质差异
我直接把平时最容易在这两种模式上栽跟头的差异点列成一张表：
| 对比维度 | CLI | FPM |
|---|---|---|
| 工作方式 | 一次性进程，跑完即退 | 常驻worker池，处理完请求继续待命 |
| 并发模型 | 无并发，一条道走到黑 | 多worker并发，一个请求占一个worker |
| 配置生效 | 改php.ini后每次新进程自动读 | 改php.ini后需要systemctl reload php8.2-fpm |
| max_execution_time | 默认0（不限制） | 受php.ini值和request_terminate_timeout双重影响 |
| memory_limit | 默认-1（不限制） | 受php.ini值限制，通常128M |
| 超全局变量 | $_GET/$_POST等为空 | 完整填充了HTTP请求信息 |
| 错误输出 | 直接打到终端STDERR | 写入错误日志文件 |
| 应用场景 | crontab、队列、数据处理、脚本 | Web请求、API接口、页面渲染 |
| 生命周期 | MINT→MSHUTDOWN，单请求 | RINT/RSHUTDOWN在每次请求间反复 |
这里最值得展开的是max_execution_time的行为差异。它看起来像是一个统一的超时控制，但实测下来有个反直觉的地方：CLI模式下即使你手动设了set_time_limit(1)，它也不是精确到1秒就杀，而是以指令执行的自然边界来判定的。比如一个循环里每条指令耗时忽略不计，你写个死循环，它会一直在循环转，直到有外部系统调用（sleep、socket读写）才会触发超时。精确地说，max_execution_time 不单独计时，而是利用CPU时钟滴答来粗测。这些细节在你排查"为什么超时配置不生效"时非常有用。
4.2 代码里的环境感知：为什么同一份代码两种模式表现不同
再往实际开发里说一层。你写代码时可以用php_sapi_name()来判断当前处于哪种SAPI，进而决定要不要include某个框架的Web入口文件。比较常见的写法：
if (php_sapi_name() === 'cli') { // 命令行专用逻辑：解析argv，不走Web路由 } else { // Web/FPM逻辑：走HTTP路由 }用Laravel的话，artisan命令就是靠这种方式和Web请求分开的。artisan本质上也是一个PHP脚本，但它通过SAPI检测判断自己运行在CLI下，然后加载console kernel而不是http kernel。
还有一个容易踩的坑：环境变量和当前工作目录。CLI模式下，脚本里的getcwd()取决于你从哪个目录执行命令，$_SERVER['PWD']保存了启动目录；而FPM模式下，工作目录通常是php-fpm.conf里chdir指定的目录。如果你代码里有相对路径的file操作（比如fopen("data.json", "r")），CLI下跑得通，FPM下一脸懵，就是因为工作目录不同。正确做法是永远用__DIR__拼绝对路径。
4.3 常驻进程的思维转变：CLI队列worker不是普通的CLI脚本
CLI模式下还有一种特殊形态特别值得单独说：常驻的队列消费者。比如Laravel的php artisan queue:work --daemon。
普通CLI脚本跑完就退，内存即使泄漏也无所谓，反正进程死了内存全回收。但queue:work是常驻的——它这个进程不退出，主循环不断从Redis队列取任务、执行。这时候你就必须用常驻进程的思维去要求自己：
- 内存盯紧：每执行完一个任务，检查一下内存增长。如果任务里有不干净的长连接对象、静态类变量累积，内存会慢慢涨上去，最后OOM被系统杀掉。正确姿势是在每次循环里显式
unset大对象，或者在业务框架开了event loop的前提下用gc_collect_cycles()手动触发垃圾回收。 - 连接要会复用：CLI常驻进程里，PDO连接可以一直复用——这反而是好事，省去每次任务重新握手的开销。但要注意，数据库server如果重启过，这个长连接就断了，你需要在循环里检测重连。
- 优雅退出：用
pcntl_signal(SIGTERM)捕获停止信号，让当前任务跑完再退，而不是任务执行到一半被kill。这里又牵涉到pcntl扩展和信号处理的细节了。
从架构视角看，CLI队列和FPM其实是两种并行运行形态：FPM管用户的同步请求，CLI管异步任务。它们共享同一份业务代码，但运行模型完全不同。
5. 实操中频繁踩坑的PHP运行环境问题与排查思路
5.1 FPM页面502/504的完整排查链路
我在运维PHP应用时，遇到最多的就是502 Bad Gateway和504 Gateway Timeout。很多新手一看到502就慌，其实排查路径非常固定：
第一步：确认PHP-FPM进程是活着的。使用systemctl status php8.2-fpm或ps -ef | grep php-fpm。如果master进程都挂了，说明严重故障，看/var/log/php8.2-fpm.log最后几十行。有一次我发现worker全没了、master也在反复重启，最后查出来是OPcache扩展在reload时崩了。
第二步：确认监听地址匹配。Nginx配置里写的是9000端口还是unix socket？php-fpm.conf里listen参数到底是什么？不一致就是connect() failed (111: Connection refused)。这步我用一条命令解决：curl -I http://127.0.0.1:9000/status或curl --unix-socket /run/php/php8.2-fpm.sock http://localhost/status。
第三步：看进程池是不是被打满了。如果日志里有WARNING: [pool www] server reached pm.max_children setting, consider raising it，说明并发超出了进程池容量。这时候不是急着调大max_children，而是先看请求是不是被某个慢请求堵住了。配合slowlog定位是哪个脚本慢。我曾经排查过一次事故，最后发现是某个接口内部调用了外部API，外部服务ttfb要20秒，直接把所有worker占满了。解决思路是给这个调用加超时和异步化，而不是无限加worker。
第四步：看PHP错误日志。如果worker执行脚本时致命错误退出，会写在error_log里。常见情况是Allowed memory size exhausted或者某个扩展在特定请求下崩溃。memory报错的话，优先优化脚本而不是调大memory_limit——调大只延缓问题，而且压榨了并发空间。
5.2 CLI模式下最常见的坑：依赖了Web环境
CLI排错有一个反复出现的主线：代码里隐式依赖了Web环境。典型症状是：线上正常，crontab里跑同一个脚本报错。
排查思路我可以给你一套：
- 在脚本开头加一行
var_dump(php_sapi_name(), getcwd(), ini_get('memory_limit'));，先确认运行环境跟你预期一致。 - 检查
$_SERVER和$_ENV的依赖。CLI的$_SERVER['argv']是存在的，但$_SERVER['HTTP_HOST']、$_SERVER['REQUEST_URI']不存在。代码里如果用了$_SERVER['HTTP_HOST']拼URL，CLI下直接报undefined index。 - 检查Session和Header。CLI下没有session机制（session_start会报warning），header函数也不可用。如果脚本处理数据时需要模拟Web环境，考虑用
$_SERVER['argv']手动指定参数，或者重构代码把环境依赖抽离出去。
我自己的习惯是：CLI脚本永远只用短标签语法 + 显式传参，不依赖任何超全局变量。因为CLI脚本的生命常常比Web代码长很多——你今天跑完就删了，明天可能要拿它复现一个数据问题，到时候最怕的就是脚本没法脱离Web环境独立运行。
5.3 实操选型清单：什么场景该用CLI，什么场景该用FPM
最后分享一个选型清单，这是我长期维护项目时的判断依据。你在设计架构或排查线上问题时，先问问自己：这个任务是谁触发的？它必须马上响应吗？
优先选CLI的场景：
- 定时任务、异步任务、批处理——任何不需要用户在线等待的任务。
- 内存开销大、执行时间长、耗CPU高的任务。这类任务放FPM就是毒药，它会一直霸占worker，挤占正常请求。
- 需要依赖Shell命令、进程控制、信号处理的任务，CLI对系统交互的权限和灵活性远超FPM。
优先选FPM的场景：
- 用户在浏览器里发起的请求，需要即时响应。这个不用多说。
- 需要Web环境（HTTP头、Cookie、Session）的任务，只能在FPM下跑。
- 任务本身内存和时间开销可控，能在几秒内返回。
混合架构的实践：我现在维护的项目方案就是"FPM + CLI队列"并存。用户上传文件后，Web请求只负责把文件存下来、写入Redis任务队列、立刻返回"处理中"。真正的大规模图片处理、日志分析，都靠CLI队列后台慢慢跑。用户无感知，服务不卡顿，这才是利用两种模式各自优势的合理架构。
做个最后提醒：排查PHP运行环境问题时，第一反应不要是改参数、加配置，而是先定位你当前运行的是哪种SAPI。CLI和FPM的排障工具箱完全不同，搞混了，整个排查方向都会跑偏。我见过太多人把Web请求的503问题当成php.ini配置问题纠结半天，结束发现是php-fpm的listen路径和Nginx的fastcgi_pass对不上。先确认SAPI，再聊别的。
