要实现基于特定 URL 的精准刷新，关键是让 fastcgi_cache_purge 在毫秒级完成单条缓存元数据的主动失效，它只清内存索引而不删文件；需严格把控三件事：缓存 key 的唯一性（必须含原始请求路径，推荐用 $scheme$request_method$host$request_uri$is_args$args）、purge 路径与 key 的完全对齐（包括协议、域名、路径、参数顺序及编码）、触发权限的最小化（仅允许 127.0.0.1 等可信 IP）。
要实现基于特定 URL 的精准刷新，关键不是“异步清理”，而是让 fastcgi_cache_purge 在毫秒级完成单条缓存元数据的主动失效——它本身不删文件，只清内存索引，后续由 Nginx 自动回收磁盘残留。真正需要你把控的是三件事：缓存 key 的唯一性、purge 路径与 key 的严格对齐、触发权限的最小化。
缓存 key 必须含原始请求路径
fastcgi_cache_key 决定了每条缓存的“身份证”。如果 key 里没包含商品 ID 或完整 URI，purge 就找不到目标。
- 推荐写法：
fastcgi_cache_key "$scheme$request_method$host$request_uri$is_args$args"; -
$request_uri包含路径和参数（如/product/123?ref=share），确保带参请求也独立缓存 - 避免用
$uri或$document_uri，它们可能被重写后丢失原始值 - 验证方式：临时加日志
log_format cache '$cache_key';，访问目标页看日志是否输出对应路径
purge location 必须还原相同 key 字符串
ngx_cache_purge 不解析 URL，只比对哈希。你写的 purge key 必须和缓存 key 完全一致，一个字符都不能差。
- 配置示例：
location ~ ^/purge(/.*) {<br> allow 127.0.0.1;<br> deny all;<br> fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1$is_args$args";<br>} -
$1捕获/purge/product/123中的/product/123，等价于原请求的$request_uri -
WORDPRESS是你在fastcgi_cache_path中定义的keys_zone名，大小写敏感，必须完全匹配 - 务必写
deny all;，否则默认放行所有 IP，等于开放缓存删除权限
触发刷新必须协议、域名、路径三重一致
curl 请求不是随便发个 /purge/xxx 就行——它必须模拟原始请求的上下文，否则 key 对不上，返回 200 却没删任何东西。
- 正确命令：
curl -X GET http://127.0.0.1/purge/product/123 - 协议（http/https）、host（域名）、路径（含尾部斜杠与否）、参数顺序、编码格式，都需和原始缓存请求完全一致
- 比如缓存了
https://shop.com/product/123，就不能用http://localhost/purge/product/123去删 - 响应状态码含义：
✓ 200 OK：命中并清除
→ 204 No Content：该 URL 当前无缓存
✗ 403 Forbidden：IP 不在白名单
✗ 404 Not Found：key 不匹配或 location 未生效
验证是否真正生效
别只看页面内容，要查响应头和日志。
- 刷新后立即用
curl -I https://shop.com/product/123查响应头：
应出现X-FastCGI-Cache: MISS或缺失该头（说明已回源） - 对比刷新前后
Age:值：从非零变为0或消失，表示旧缓存已失效 - 检查 Nginx error 日志，确认无
no cache entry或cache zone not found报错 - 注意排除干扰：浏览器缓存、CDN 缓存、PHP OPcache 都可能掩盖 Nginx 层效果，建议用 curl 或隐身模式测试
