开启 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——若有，说明没绕过成功
