怎么解决开启 fastcgi_cache 之后验证码图片或 Session 引发全网串视的严重 Bug

开启 fastcgi_cache 后验证码空白、Session 错乱，本质是动态内容被错误缓存，需排除验证码和 Session 相关路径（如 /captcha、/login）、配置 fastcgi_cache_bypass 1 和 fastcgi_no_cache 1，并确保 cache_key 包含 $cookie_PHPSESSID、响应头含 Vary: Cookie、图像响应禁用 gzip。

开启 fastcgi_cache 后验证码图片空白、Session 值错乱、不同用户看到同一张验证码或验证总失败——这不是缓存“太强”，而是缓存没避开关键动态内容。本质是 Nginx 把本该每次生成的验证码图片（或含 Session ID 的响应）当成静态资源缓存了，导致所有用户取到同一个缓存副本。

必须排除验证码和 Session 相关路径的缓存

验证码接口（如 /captcha 或 /index.php?s=captcha）和任何写入/读取 Session 的关键接口（如登录、校验）绝不能进 FastCGI 缓存。Nginx 默认不区分，需显式绕过：

• 在 location 块中匹配验证码路径，加 fastcgi_cache_bypass 1; 和 fastcgi_no_cache 1;
• 示例配置：

  location ~ ^/(captcha|login|check-captcha) {    fastcgi_cache_bypass 1;    fastcgi_no_cache 1;    include fastcgi_params;    fastcgi_pass php_backend;}

• 若用 ThinkPHP 路由，注意真实 URL 可能带 index.php?s=xxx，需用正则匹配参数：location ~ .php.*s=(captcha|login)

检查 Vary 响应头是否缺失或冲突

Session 依赖 Cookie（尤其是 PHPSESSID），而缓存若忽略 Cookie 差异，就会把 A 用户的 Session 响应返回给 B 用户。必须让缓存区分不同 Session：

• 后端 PHP 应输出 Vary: Cookie（ThinkPHP 默认会，但需确认未被覆盖）
• Nginx 配置中确保 fastcgi_cache_key 包含 Cookie 或 Session ID，例如：

  fastcgi_cache_key "$scheme$request_method$host$request_uri$cookie_PHPSESSID";

• 若用 Redis 存 Session，且多个子域共享，还需确保 $cookie_PHPSESSID 在跨域时能稳定传递（见二级域名 Session 共享配置）

禁用缓存对二进制图像响应的干扰

验证码是 image/png 响应，但 FastCGI 缓存可能误判 MIME 类型、压缩图像流或与 GD 输出缓冲冲突：

• 在验证码入口开头强制清空输出缓冲：ob_clean();，再调用 Captcha::create()
• Nginx 中为图像响应关闭 gzip 压缩（避免破坏二进制流）：

  location ~ .(png|jpg|gif)$ {    gzip off;    expires 1s;}

• 确认 PHP 的 output_buffering 在 php.ini 中未设为 On（建议设为 Off 或数值，避免多层缓冲叠加）

验证缓存键与缓存失效逻辑是否合理

即使绕开了路径，若缓存 key 设计不当，仍可能混用：

• 避免使用纯 $request_uri 作 key——它不含 Cookie，无法区分用户
• 不要在验证码接口中返回 Cache-Control: public，应设为 private, no-store, no-cache
• 临时加调试：在验证码方法里输出 session_id() 和 $_COOKIE['PHPSESSID']，确认每次请求 Session ID 是否变化；再看响应头是否有 X-FastCGI-Cache: HIT——若有，说明没绕过成功