fastcgi_cache是低侵入、见效快的旧系统并发性能提升方案，通过Nginx层缓存动态响应，拦截重复请求于PHP执行前，无需改代码、不升级组件、不依赖开发配合。
对旧版系统做并发性能提升，fastcgi_cache 是一条低侵入、见效快的路径。它不改动代码、不升级 PHP 或数据库，只靠 Nginx 层缓存动态响应结果，把重复请求拦截在 PHP 执行之前——相当于给老系统套上一层“响应快照膜”。关键在于“无痛”：不改业务逻辑、不引入新组件、不依赖开发配合。
确认旧系统是否适合接 fastcgi_cache
不是所有旧系统都适合缓存。先快速判断三个硬条件：
- Nginx 版本 ≥ 1.11.6（宝塔面板默认 1.22+ 通常满足，进【软件商店】→ 查看已安装 Nginx 版本即可）
- PHP 运行模式为 php-fpm（进站点【设置】→ 【PHP版本】选项卡，确认不是 Apache 模式或纯 CGI）
- 页面内容更新频率低：比如企业官网、产品介绍页、文档中心、静态化 CMS（如早期 WordPress 配合 WP Super Cache 的场景）
如果登录态强、实时数据多（如后台管理页、订单详情、用户仪表盘），就避开这些路径，只缓存公开、稳定、非个性化的内容。
缓存策略要“窄而准”，避免缓存污染
旧系统往往没做缓存控制头（Cache-Control、Vary），不能全站开缓存。推荐用 location 精确命中：
- 只缓存以 .php 结尾且无查询参数的页面：location ~ ^/index\.php$ { … }
- 或缓存特定目录，如 /news/、/about/、/help/ 下的所有 PHP 请求
- 显式跳过带敏感参数的请求：添加 fastcgi_cache_bypass $arg_token $arg_sessionid; 防止登录态被缓存
- 用 fastcgi_cache_key 定制键值，排除影响缓存一致性的变量，例如：fastcgi_cache_key "$scheme$request_method$host$request_uri";（去掉 $args 和 cookie）
缓存生命周期必须“短而稳”，兼顾新鲜与可用
旧系统难做主动刷新，所以靠时间驱动更稳妥：
- 200/301/302 响应缓存 5–30 分钟（如 fastcgi_cache_valid 200 30m;），比 1 小时更安全
- 其他状态码（404、500、304）统一缓存 1–2 分钟，防刷又不误事
- 启用 fastcgi_cache_use_stale error timeout http_500 http_503，让出错时仍可返回旧缓存，保障可用性
- 设置 fastcgi_cache_min_uses 2，避免单次访问就写入缓存，减少无效缓存条目
上线前必做的三件事
避免缓存引发线上事故：
- 在配置中加一行 fastcgi_cache_lock on;，防止高并发下同一请求多次穿透到 PHP
- 用 curl -I 访问目标页面，检查响应头是否含 X-FastCGI-Cache: HIT / MISS（需在配置中加 add_header X-FastCGI-Cache $upstream_cache_status;）
- 首次启用后观察 10 分钟内 PHP-FPM 进程活跃数（如通过宝塔【监控】→ 【PHP 运行状态】），下降 30% 以上说明生效
