PHP的FastCGI模式是一种常驻内存的网关接口实现，它通过独立的进程管理器（如PHP-FPM）来接管PHP解释器的生命周期。与每次请求都重新拉起进程的传统CGI不同，FastCGI预先启动一组worker进程，等待Web服务器转发请求后直接处理，处理完不退出而是继续待命。这种模式在主流LNMP架构中几乎成为标配，但很多人在迁移时并不清楚它到底改变了什么。
FastCGI的工作原理
在FastCGI模型中，Web服务器（例如Nginx）并不直接执行PHP脚本，而是将请求通过FastCGI协议发送给后端的PHP-FPM服务。PHP-FPM作为进程管理器，维护一个master进程和多个worker进程。master负责监听端口、接收请求并分发给空闲worker，worker加载PHP解释器并执行脚本，执行结束后保留在内存中等待下一个任务。
这种机制避免了传统CGI下“每来一个请求就fork一个进程并初始化解释器”的高昂成本。我们可以用一段简化的PHP-FPM配置来理解进程管理方式：
[www] ; 静态模式：固定启动10个worker pm = static pm.max_children = 10 ; 动态模式示例 ; pm = dynamic ; pm.start_servers = 5 ; pm.min_spare_servers = 3 ; pm.max_spare_servers = 8 ; 每个worker最多处理500个请求后重启，防止内存泄漏 pm.max_requests = 500
从上面的配置可以看出，FastCGI的进程管理非常灵活。静态模式适合内存充足且流量平稳的服务，动态模式则能根据负载自行伸缩。同时，通过pm.max_requests定期回收worker，可缓解长期运行带来的内存碎片与泄漏问题。
FastCGI模式的主要优点
最显著的优点是性能提升。由于PHP解释器和相关扩展只需在worker启动时加载一次，后续请求省去了重复初始化开销。在压力测试中，同样硬件下FastCGI的QPS往往是CGI的数倍甚至更高。此外，进程常驻让OPcache等字节码缓存真正发挥作用，脚本编译结果可跨请求复用。
另一个优点是资源调度可控。管理员能够通过PHP-FPM精细限制单池进程数、用户权限及慢日志。例如下面代码开启慢请求记录，便于排查卡顿：
; 超过2秒记为慢请求 request_slowlog_timeout = 2s slowlog = /var/log/php-fpm/slow.log ; 限制单个worker内存，防失控 php_admin_value[memory_limit] = 128M
这种集中式的进程与权限管理，使多站点共用一台服务器时隔离性更好，也比让Web服务器内嵌PHP模块（如Apache的mod_php）更轻量，因为Web服务自身不必承担解释器崩溃的风险。
FastCGI模式的主要缺点
常驻内存的首要代价是内存占用。每个worker都会独立加载PHP及扩展，10个worker就可能占用数百兆内存。如果pm.max_children设置过大，在低配机器上极易触发OOM。相比CGI“用完即焚”的干净释放，FastCGI需要运维对内存模型有清晰预估。
其次是故障传播与状态污染。worker进程处理完请求若不妥善清理全局变量或单例，可能把上一次请求的状态带入下一次，造成难以追踪的bug。以下代码展示了不安全的静态变量复用：
<?php
class Counter {
private static $count = 0;
public static function inc() {
self::$count++;
return self::$count;
}
}
// 在FastCGI常驻环境下，两次请求会累加，而非从0开始
echo Counter::inc();
?>
此外，当PHP代码出现段错误时，对应worker退出，master虽会拉起新进程，但瞬间抖动可能影响少量用户。传统CGI因进程孤立，单个请求崩溃一般不影响其他请求，这也是FastCGI在极端稳定性要求场景下的隐忧。
与传统CGI的对比总结
我们可以用一张简表来看清两者差异：
| 维度 | 传统CGI | PHP FastCGI |
|---|---|---|
| 进程创建 | 每请求fork | 预启动常驻 |
| 响应速度 | 慢 | 快 |
| 内存占用 | 低且释放及时 | 高且需手动调优 |
| 并发能力 | 弱 | 强 |
| 部署复杂度 | 简单 | 需配进程管理器 |
总体来看，FastCGI以内存和运维复杂度换取了吞吐量与延迟的大幅优化，适合绝大多数线上Web服务。传统CGI仅建议在极低频、强隔离的命令行或调试场景中使用。理解这些优缺点，才能在实际架构中做出合理取舍。
实践中的配置建议
若你正准备将PHP切换为FastCGI，建议先估算单worker内存占用，再用公式“可用内存乘以0.8除以单worker内存”得出pm.max_children上限。同时开启OPcache并设置pm.max_requests以防内存泄漏累积。
下面是一段Nginx转发到PHP-FPM的典型配置，注意FastCGI协议通过套接字或端口通信：
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
只要Web服务器与PHP-FPM网络通畅，这种解耦架构便于横向扩展，比如将PHP-FPM独立部署到专用机器，进一步提升资源利用率。掌握上述要点，FastCGI的缺点便可控，优点则能充分释放。