审计fpm worker跨请求状态污染的核心方法是利用php-fpm的慢日志（slowlog）功能，通过设置`request_slowlog_timeout`和`request_terminate_on_timeout`参数，强制在脚本执行超时后终止当前worker进程并记录堆栈。观察request state的最佳实践是结合nginx访问日志中的`$upstream_response_time`与php-fpm慢日志进行关联分析，因为慢日志中记录的变量快照能直接反映导致超时的具体代码行及当时的全局变量状态。
如何配置并触发慢日志以捕获污染现场？
要捕获跨请求状态污染，必须启用PHP-FPM的慢日志功能。这需要在FPM池配置文件（如www.conf）中开启相关指令。当脚本执行时间超过设定的阈值时，FPM会生成一条包含完整调用堆栈和当时所有全局变量值的日志条目。这种机制不仅能定位性能瓶颈，还能在进程被强制终止前“冻结”其内存状态，从而暴露出未被正确清理的全局变量、静态变量或单例对象残留。
; ; 启用慢日志 php_admin_flag[log_errors] = on php_admin_value[memory_limit] = 128M ; 设置超时阈值为2秒 request_slowlog_timeout = 2s ; 超时后终止进程，防止污染累积到下一个请求 request_terminate_on_timeout = on ; 指定慢日志路径 slowlog = /var/log/php-fpm/www-slow.log
上述配置中，`request_terminate_on_timeout`是关键。如果仅开启慢日志而不终止进程，受污染的Worker将继续处理下一个请求，导致错误扩散且难以复现。开启此选项后，每次超时都会重启一个干净的Worker，虽然牺牲了少量性能，但保证了隔离性。在实际操作中，可以通过模拟长时间运行的脚本或故意引入死循环来测试该配置是否生效。生成的慢日志将明确显示哪一行代码导致了超时，以及该行执行时`$GLOBALS`数组的内容。
如何通过日志关联分析确定污染源头？
单独查看PHP-FPM慢日志只能看到单个请求内部的变量状态，要确认“跨请求”污染，需要结合Nginx日志进行分析。Nginx的`$upstream_response_time`变量记录了从发送请求到接收完上游响应的时间。通过将Nginx日志中的时间戳与PHP-FPM慢日志中的时间戳进行匹配，可以精确定位哪些请求导致了Worker异常。此外，还可以编写简单的监控脚本，定期解析慢日志，提取出现频率最高的全局变量名，这些变量往往是潜在的污染源。
# Nginx日志格式示例，需包含上游响应时间
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" rt=$upstream_response_time uct="$upstream_connect_time"';
# 假设Nginx日志文件为 access.log
# 使用awk提取耗时超过2秒的请求及其时间戳
awk '$10 > 2.0 {print $4, $10}' access.log | head -n 5
在实际审计中，如果发现某个全局变量`$user_session`在不同请求中出现了不一致的值，且该值仅在特定条件下出现，那么很可能是之前的请求未正确销毁该变量。通过对比Nginx日志中的请求ID（如果启用了X-Request-ID）和PHP-FPM慢日志中的时间，可以构建出完整的请求生命周期视图。对于复杂的污染场景，建议在生产环境低峰期开启慢日志，并持续监控一段时间，收集足够的样本数据后再进行深度分析。
静态变量和单例模式在Worker中如何表现？
在PHP-FPM的Worker模型中，静态变量（static variables）和单例模式（Singleton pattern）的生命周期贯穿整个Worker进程的运行期间，而非单个请求。这意味着如果在请求A中修改了静态变量的值，那么在请求B中读取该变量时，将获得修改后的值，除非在请求A结束时显式重置它。这种行为在Web开发中通常被视为Bug，因为它破坏了无状态HTTP协议的基本假设。
<?php class Singleton {
private static $instance = null;
public static $data = [];
public static function getInstance() {
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
}
// 模拟请求处理
$requestId = $_GET['id'] ?? 'unknown';
$instance = Singleton::getInstance();
// 污染：将当前请求ID存入静态属性
$instance->data['last_request_id'] = $requestId;
// 输出当前状态
echo "Current Last Request ID: " . $instance->data['last_request_id'] . "<br>";
// 模拟长时间操作
sleep(3);
?>
运行上述代码时，第一个请求会将`last_request_id`设置为自己的ID。由于Worker进程未被终止（假设超时时间大于3秒），第二个请求进来时，`$instance->data['last_request_id']`仍然保留着第一个请求的值。只有当第三个请求到来且前两个请求都已完成时，该值才会更新。这种隐式的状态共享是导致数据错乱的主要原因。解决之道是在每个请求结束时，通过`register_shutdown_function`或中间件手动重置这些静态结构，或者避免在长生命周期的对象中存储请求级数据。
