FastCGI 本身不实现动静分离，而是 Nginx 与 PHP 通信的协议；性能跃升关键在于用 fastcgi_cache 缓存“伪静态”动态页面，使 Nginx 直接返回已生成 HTML，跳过 PHP 和数据库。
FastCGI 本身不直接实现动静分离，它是 Nginx 与 PHP 等后端语言通信的协议；真正提升性能的关键，是在动静分离基础上，用 fastcgi_cache 对“伪静态”动态页面做高效缓存——把 PHP 已生成的 HTML 直接存到 Nginx 本地，后续请求跳过 PHP 和数据库，毫秒返回。
动静分离是基础，FastCGI 是通道，缓存才是性能跃升点
传统理解的动静分离，只是让 Nginx 直接服务 .css/.js/.jpg，把 .php 请求交给 PHP-FPM。但这只解决了静态文件阻塞问题，没触达真正的瓶颈：WordPress、Typecho 这类博客的 /2024/08/my-post/ 页面，URL 看似静态，背后每次都要查库、渲染模板、拼 HTML。这类请求占流量 70% 以上，却反复消耗 CPU 和 MySQL 连接。
fastcgi_cache 的价值，就是把这部分“逻辑动态、内容静态”的响应结果（完整的 HTTP 响应体 + 头部）缓存下来，下次同 URL 请求，Nginx 自己发出去，完全不惊动 PHP-FPM。
必须配对使用的两类 location 规则
仅靠一个 fastcgi_pass 不够，需配合精准的 location 分流：
- 匹配静态扩展名（如
\.(css|js|png|woff2)$）的请求，走root+expires，由 Nginx 零延迟读取并加缓存头 - 匹配 PHP 路径（如
location ~ \.php$或 WordPress 的location /+ try_files）的请求，走fastcgi_pass，并在此块内启用缓存指令
四行核心缓存配置缺一不可
缓存失效、命中率低，90% 源于这四部分没写对位置或语义：
-
fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=WP_CACHE:256m inactive=1d max_size=2g;—— 放在http{}顶层，提前创建目录并设对属主（如chown www-data:www-data /var/cache/nginx/fastcgi） -
fastcgi_cache_key "$scheme$request_method$host$request_uri";—— 去掉$args，避免 utm 参数导致重复缓存 -
fastcgi_cache_use_stale error timeout updating http_500 http_503;—— 提升容错，后端短暂异常时仍可返回旧缓存 -
fastcgi_cache_valid 200 301 302 1h;—— 显式声明哪些状态码可缓、缓多久，不依赖后端 Set-Cookie 或 Cache-Control
安全绕过比缓存本身更重要
不能缓的内容，必须明确排除，否则会导致登录态错乱、用户看到别人的数据：
- 含
Set-Cookie头的响应默认不缓存（fastcgi_ignore_headers 已默认包含） - 所有带查询参数的请求（如
?s=xxx、?preview=true）应在 location 中用if ($args) { fastcgi_cache_bypass 1; }强制绕过 - 后台路径（
/wp-admin/、/wp-login.php）、会员中心等，用location ^~ /wp-admin { fastcgi_cache_bypass 1; }隔离
