## 一句话结论
PHP依靠MINIT、RINIT、RSHUTDOWN、MSHUTDOWN四段生命周期管控资源；FPM进程启动/销毁仅执行一次MINIT/MSHUTDOWN，每一次HTTP请求都会执行RINIT/RSHUTDOWN，常驻Swoole/Octane无自动请求隔离。

## 体系讲解
### 一、SAPI 基础概念
SAPI是PHP引擎和运行环境的中间抽象层，不同运行载体对应独立SAPI：
- fpm-fcgi：PHP-FPM服务
- cli：命令行、Swoole、RoadRunner、Laravel Octane常驻服务
- apache2handler：Apache内置PHP模块
SAPI负责IO封装、请求参数解析、调度生命周期钩子。

### 二、四大生命周期钩子完整对照表
| 阶段 | 扩展宏 | 触发层级 | 执行频次 | 核心工作 |
| ---- | ---- | ---- | ---- | ---- |
| 模块初始化 | PHP_MINIT_FUNCTION | 进程级 | 进程启动仅1次 | 注册类、函数、INI配置、分配进程全局内存 |
| 请求初始化 | PHP_RINIT_FUNCTION | 请求级 | 每次请求开始 | 重置执行器上下文、填充$_GET/$_POST/$_SERVER超全局变量 |
| 请求收尾 | PHP_RSHUTDOWN_FUNCTION | 请求级 | 每次请求结束 | 执行shutdown回调、释放请求临时资源、清理执行上下文 |
| 模块销毁 | PHP_MSHUTDOWN_FUNCTION | 进程级 | 进程退出仅1次 | 释放进程全局内存、注销扩展注册的配置与符号 |

### 三、FPM vs CLI（Swoole）生命周期核心差异
1. **PHP-FPM（fpm-fcgi SAPI）**
    每个Worker进程独立生命周期：
    - Worker启动：执行MINIT；
    - 每一次HTTP请求：RINIT → 执行业务脚本 → RSHUTDOWN；
    - Worker关闭/重载销毁：执行MSHUTDOWN。
    引擎天然隔离请求：RINIT每次重置执行环境，静态变量、超全局变量不会跨请求污染。

2. **Swoole/Hyperf/Octane（cli SAPI）**
    进程长期驻留，只会完整走一次MINIT+MSHUTDOWN；
    每一次客户端请求**不会自动触发RINIT/RSHUTDOWN**；
    $_GET/$_POST不会自动清空、类静态属性、单例对象状态永久留存，极易出现跨请求数据污染，框架必须手动模拟请求隔离（沙箱、协程上下文、每次请求重置静态数据）。

### 四、超全局变量填充逻辑
$_GET、$_POST、$_COOKIE、$_SERVER 在**RINIT**阶段由SAPI读取FastCGI/请求报文自动填充。
- FPM：每次请求全新生成，天然隔离；
- Swoole：无自动填充重置，框架需要手动从$request对象解析，手动赋值超全局数组。

### 五、对常驻内存框架的工程影响
1. 静态类属性、单例缓存、全局变量跨请求共享；
2. 原生超全局变量残留旧请求数据；
3. 原生shutdown_function仅在脚本结束触发，无法替代RSHUTDOWN全局清理；
4. 解决方案：框架沙箱隔离、协程上下文、请求后置手动清空全局状态。

## 考察意图
1. 分清进程级钩子(MINIT/MSHUTDOWN)与请求级钩子(RINIT/RSHUTDOWN)执行频次；
2. 理解FPM请求隔离的底层来源是RINIT自动重置执行上下文；
3. 解释Swoole等常驻服务跨请求污染的根本生命周期原因；
4. 具备基础扩展生命周期认知，能区分进程全局与请求全局资源。

## 高频追问简答
### 1. FPM修改php.ini reload是否生效，为什么？
生效。Reload发送USR2信号，旧Worker处理完当前请求退出，新Worker进程重启执行MINIT，重新加载最新php.ini；
仅FPM主进程配置（监听端口、进程池数量）需要完整restart。

### 2. register_shutdown_function 和 RSHUTDOWN 执行顺序？
脚本执行完毕 → shutdown_function回调执行 → 对象__destruct析构 → RSHUTDOWN钩子；
致命错误依然会执行shutdown_function，但RSHUTDOWN可能执行不完整。

### 3. 扩展C层全局变量，FPM请求间会自动重置吗？
不会。`ZEND_BEGIN_MODULE_GLOBALS`定义的全局变量属于进程内存，不在执行器上下文EG中，RINIT不会自动清空，扩展必须在RINIT手动重置。

### 4. FPM和Swoole的$_POST填充逻辑区别？
FPM：RINIT自动解析FastCGI报文生成全新$_POST；
Swoole：无RINIT，不会自动重置，框架手动解析请求体，赋值覆盖$_POST。

## 高频易错点
1. 误区：MINIT每次请求都会执行
MINIT是进程启动一次性执行，只有Worker新建才会触发，单进程处理万次请求仅执行一次；
2. 误区：Swoole天然拥有FPM一样的请求隔离
Swoole使用CLI SAPI，不会自动执行RINIT/RSHUTDOWN，无原生隔离，必须框架手动处理；
3. 误区：reload无法加载新php.ini
reload会重建Worker进程，新进程执行MINIT重新读取配置，无需完全重启服务。

## 代码示例：常驻进程静态变量污染演示
```php
<?php
// Swoole常驻服务，静态属性跨请求污染
class Counter
{
    // 静态属性保存在进程全局，不会自动重置
    public static int $num = 0;
}

$server = new Swoole\Http\Server('0.0.0.0', 9501);
$server->on('request', function ($req, $res) {
    Counter::$num++;
    // 多次请求数字持续累加，FPM环境不会出现
    $res->end("当前请求计数：" . Counter::$num);
});
$server->start();

// 修复方案：每次请求手动重置，模拟RINIT清理逻辑
// $server->on('request', function ($req, $res) {
//     Counter::$num = 0;
//     Counter::$num++;
//     $res->end("当前请求计数：" . Counter::$num);
// });
```

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺