要实现管理员发布后无延迟刷新缓存，必须分离 bypass（读时绕过）与 purge（写时清除）职责：bypass 仅用于后台等动态场景，静态内容页须允许缓存并由 cms 自动调用精准 purge 接口清除，同时确保 cache_key 与 purge key 完全一致，并限制 purge 接口访问权限。
要让管理员发布新内容后能无延迟刷新特定路径的全站缓存，fastcgi_cache_bypass 本身不负责“刷新”，它只控制“绕过缓存”，真正实现“无延迟更新”的关键是配合 cache purge（清除）机制，并确保 bypass 规则不干扰 purge 的触发逻辑。调优核心在于：让 bypass 只作用于需动态响应的请求（如后台、登录态），而把“主动清缓存”这件事交给独立、可控、精准的 purge 接口。
明确 bypass 和 purge 的分工
bypass 是“读时跳过”，适用于每次请求都需实时计算的场景（如后台页面、带 preview 参数的预览页）；purge 才是“写时清除”，适用于内容变更后主动失效缓存。管理员发布新内容时，应触发 purge，而非依赖 bypass——否则所有用户访问都会变慢，失去缓存意义。
- bypass 配置不当（比如对 /post/123 也 bypass），会导致该路径永远不进缓存，无法被 purge 清除
- 正确做法：/post/123 这类静态化内容页必须允许缓存（即不 bypass），但提供 /purge/post/123 接口供 CMS 调用清除
- 管理员操作流程应为：发布 → CMS 自动 curl http://127.0.0.1/purge/post/123 → 缓存秒级失效，下次访问重建
确保 purge 能精准命中目标路径
能否无延迟刷新，取决于 purge 请求构造的 key 是否与原始缓存 key 完全一致。关键配置如下：
- 缓存 key 必须稳定包含路径：推荐使用
fastcgi_cache_key "$scheme$request_method$host$request_uri$is_args$args";，确保 /post/123 和 /post/123?ref=share 生成不同 key - purge location 中还原 key 的变量必须严格对应：例如
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1$is_args$args";，其中$1来自location ~ ^/purge(/.*)，直接捕获原始 URI 路径部分 - 验证方法：临时加
log_format cache '$cache_key'; access_log /var/log/nginx/cache.log cache;，访问 /post/123 和 /purge/post/123，比对日志中两行 key 字符串是否完全一致
管理员操作通道要安全、自动、免人工
不能靠管理员手动 curl，而应由 CMS 或发布系统自动触发：
- 在 Nginx 中限制 purge 接口仅允许本地或内网 IP（如
allow 127.0.0.1; allow 10.0.1.0/24;），禁止公网访问 - CMS 在文章保存成功后，调用
curl -X GET http://127.0.0.1/purge/post/123（协议、域名、路径必须与前端访问一致） - 若需批量清除（如栏目页+所有子文章），可扩展 purge 规则支持正则匹配，或由 CMS 循环调用单条 purge
避免 bypass 规则污染 purge 生效路径
常见错误是把所有带参数或含 admin 的规则，无差别 applied 到全站 PHP location，导致商品页、文章页也被 bypass，从而无法缓存、更无法 purge：
- 将 bypass 逻辑按路径隔离：后台路径（/wp-admin/, /admin/）单独设置 bypass；前台内容页（/post/, /product/）禁用 bypass，专注做好 purge
- 不要用
fastcgi_cache_bypass $query_string这类粗粒度规则，它会让 /post/123?utm=xxx 永远 bypass，丧失缓存价值 - 若需保留某些参数缓存（如分页），应在 cache_key 中保留
$args，而非用 bypass 屏蔽整个请求
