fastcgi_cache_bypass 实现“绕过缓存”而非隔离，需与 fastcgi_cache_key、fastcgi_no_cache 配合完成用户身份、请求参数、路径及后端协同的多维缓存控制。
fastcgi_cache_bypass 不是“隔离缓存”，而是“绕过缓存”——它让特定请求跳过已有缓存，直连后端 PHP 处理，同时不干扰其他请求的缓存行为。真正实现缓存策略隔离，需要它和 fastcgi_cache_key、fastcgi_no_cache 配合使用，形成“谁绕行、谁缓存、缓存存成什么样”的完整控制链。
按用户身份隔离：登录态用户不共享游客缓存
游客访问首页可缓存，但登录用户看到的是个性化内容，必须绕开统一缓存。光靠 cache_key 区分不够——如果未登录请求已缓存了 /index.php，而登录用户也命中同一 key，就会返回错误页面。
- 用 fastcgi_cache_bypass $cookie_PHPSESSID; 让带会话 Cookie 的请求直接回源，避免读错缓存
- 再配合 fastcgi_cache_key "$scheme$request_method$host$request_uri$cookie_user_id";，确保不同用户（如 user_id=101 和 user_id=102）生成不同缓存条目
- 二者组合：未登录用户走公共缓存；已登录用户既不读旧缓存（bypass），又各自独立缓存（key 包含 user_id），实现安全隔离
按请求头或参数临时绕过：调试与预览场景
开发时加 ?debug=1、编辑器点“预览”传 ?preview=1、或前端发 Authorization 头，这些都应立刻生效，不依赖缓存。
- 配置 fastcgi_cache_bypass $arg_debug $arg_preview $http_authorization;，任一存在即触发绕行
- 务必同步设置 fastcgi_no_cache 相同变量，防止后端返回的响应被意外写入缓存
- 例如访问
/article/123?preview=1：Nginx 不查缓存、不存响应，PHP 返回实时渲染结果，且不影响 /article/123 的正常缓存
按路径精准控制：后台、仪表盘、API 接口默认不缓存
某些路径天然不适合缓存（如 /wp-admin/、/dashboard、/api/v1/order），硬塞进缓存反而引发数据错乱或权限泄露。
- 用正则提前设标记：set $skip_cache 1;，再匹配路径重置：if ($request_uri ~* "^/(wp-admin|dashboard|api/)") { set $skip_cache 0; }
- 然后 fastcgi_cache_bypass $skip_cache; —— 值为 0 时绕过，值为空时不绕过
- 注意：if 在 location 外使用有局限，更稳妥做法是把这类路径单独写 location 块，直接禁用 cache 指令
与后端协同：让 PHP 主动决定是否绕过
有些逻辑只有 PHP 能判断，比如当前文章是否处于草稿状态、用户是否在 A/B 测试分组中。这时可由 PHP 输出标识，Nginx 捕获并执行 bypass。
- PHP 中输出：header('X-Nocache: 1'); 或 setcookie('nocache', '1');
- Nginx 中捕获：fastcgi_cache_bypass $upstream_http_x_nocache $cookie_nocache;
- 这样 CMS 发布草稿时，PHP 可动态控制该页面不进缓存；正式发布后再移除 header，恢复缓存流程
