CodeIgniter 无法控制 FastCGI，因其仅运行于 PHP-FPM 进程内，真正的 FastCGI 加速需在 Nginx 和 PHP-FPM 层配置，如 fastcgi_pass、fastcgi_cache、pm 设置等。
CodeIgniter 本身不处理 FastCGI，它只是 PHP 应用；真正的 FastCGI 加速发生在 Web 服务器层（如 Nginx + PHP-FPM），不是框架内配置项。 想靠改 config.php 或写个中间件就“启用 FastCGI”是无效的——那属于对请求链路的误解。
为什么 CodeIgniter 控制不了 FastCGI？
FastCGI 是 Web 服务器（Nginx/Apache）与 PHP 解释器（PHP-FPM）之间的通信协议。CI 运行在 PHP-FPM 子进程中，它连 fastcgi_pass 这个指令都看不到，更无法干预连接方式、缓冲策略或缓存行为。
- 你在 CI 里调用
$this->output->cache(5)，只影响应用层页面缓存，和 FastCGI 缓存无关 - 开启
$config['compress_output'] = TRUE是 PHP 层的 output buffering + gzip，和fastcgi_buffering不同层级 - 所谓“CI 中间件注册 FastCGI”纯属概念混淆——钩子（hooks）只能在 CI 生命周期内运行，无法触达 PHP-FPM 或 Nginx 配置
Nginx + PHP-FPM 的关键 FastCGI 配置项
要真正加速 CI 应用，必须在 Nginx 配置中明确控制 FastCGI 行为。以下是最常被忽略但影响显著的几项：
-
fastcgi_pass：优先用 Unix socket（如unix:/run/php/php8.1-fpm.sock），比127.0.0.1:9000少一次 TCP 握手 -
fastcgi_buffering on：默认开启，但若后端输出大文件或流式响应，需设为off避免阻塞 -
fastcgi_buffers 8 32k和fastcgi_busy_buffers_size 64k：防止因缓冲区太小触发频繁磁盘写入（fastcgi_temp_file_write_size） -
fastcgi_cache：这是最有效的加速手段——缓存整个 PHP 响应（含 HTTP 头），绕过 CI 引导流程。注意要配fastcgi_cache_valid 200 302 10m和fastcgi_cache_bypass $arg_nocache
PHP-FPM 层配合要点
Nginx 只是前端代理，PHP-FPM 的配置直接影响并发能力和响应延迟：
-
pm = static或pm = dynamic：避免用ondemand（启动慢，CI 请求冷启动明显） -
pm.max_children：需根据内存估算，例如 2GB 内存、平均进程占 40MB → 设为 40 左右，过高会 OOM -
request_terminate_timeout：CI 若有长查询或未设超时，可能卡住 worker，建议设为60s - 确保
clear_env = no，否则 CI 依赖的$_SERVER环境变量（如PATH_INFO）可能丢失
容易踩的坑：缓存冲突与调试盲区
FastCGI 缓存看似简单，但在 CI 场景下极易出错：
- 未排除带 Session/Cookie 的请求：
fastcgi_cache_bypass $cookie_PHPSESSID必须加，否则登录态错乱 - CI 的
index.php?/news/123和重写后的/news/123被视为不同 key，需统一fastcgi_cache_key，例如：$scheme$request_method$host$request_uri -
fastcgi_cache_valid不覆盖 301/302：重定向响应不会被缓存，但 CI 的redirect()仍走完整流程——别指望它变快 - 调试时禁用缓存，别只删 CI 的
application/cache/：要curl -I http://yoursite/看X-FastCGI-Cache: HIT才算生效
真正起效的 FastCGI 加速，90% 功夫在 Nginx 和 PHP-FPM 的协同调优，而不是改 CI 的某行代码。漏掉 fastcgi_cache_key 或 fastcgi_cache_bypass 中任意一个条件，缓存就可能把登录页缓成游客页——这种问题不会报错，只会静默出错。
