缓存清理机制的核心是让更新生效快、不误伤其他资源、不拖慢请求，需区分浏览器缓存与Nginx本地缓存，优先用版本控制规避清理，必须清理时采用精准的URI失效、缓存键清理或重启+清盘组合方式，并通过响应头、日志和真实访问验证效果。
缓存清理机制不是为了“清得越勤越好”，而是让更新生效快、不误伤其他资源、不拖慢请求。核心思路是：区分缓存层级，按需清理；优先用版本控制规避清理，实在要清就精准操作。
区分浏览器缓存与 Nginx 本地缓存，清理策略不同
浏览器缓存靠响应头（如 Cache-Control）驱动，Nginx 本地缓存（proxy_cache）则存在磁盘和内存中。两者不能混为一谈，清理方式也完全不同：
-
浏览器端无需主动“清理”：只要资源带哈希指纹（如
app.a1b2c3.js），旧文件自然失效，新 URL 触发全新缓存；没哈希的资源（如common.css）应设短缓存（max-age=3600），靠过期自动刷新，避免手动干预 - Nginx 本地缓存需可控清除：它不会随前端发布自动失效，必须通过路径、键或工具显式清理。否则用户可能长期看到旧文件，尤其当后端源站已更新但 Nginx 还在返回缓存副本时
精准清理 Nginx proxy_cache 的三种可靠方式
不建议直接删缓存目录（易出错、可能删错层级），推荐以下方法：
-
按 URI 主动失效（推荐）：使用
proxy_cache_purge指令，配合专用 purge location。需在编译 Nginx 时启用--with-http-cache-purge-module：
location ~ /purge(/.*) {<br> allow 127.0.0.1;<br> deny all;<br> proxy_cache_purge my_cache $scheme$host$1;<br>}
清理/static/logo.png就访问curl -X PURGE http://localhost/purge/static/logo.png -
按缓存键构造规则清理：若缓存 key 包含变量（如
$scheme$host$request_uri），可写脚本生成对应 purge 请求；也可用ngx_http_lua_module在 Lua 中动态计算并调用 purge -
重启 + 清盘组合操作（上线/大更时用）：
• 先nginx -s reload清空内存中的缓存索引
• 再rm -rf /var/cache/nginx/*彻底清空磁盘缓存（确保路径与proxy_cache_path一致）
• 注意：该操作影响全局，仅适用于维护窗口期
用版本化路径替代“清理”，更安全高效
与其反复清理，不如让缓存天然失效：
- 将静态资源部署到带版本号的路径下，例如
/v2.3.1/js/app.js，每次发布新版本就切到/v2.3.2/ - Nginx 配置中用
try_files或重写匹配版本前缀：
location ~ ^/v\d+\.\d+\.\d+/(.*) {<br> alias /data/static/$1;<br> add_header Cache-Control "public, max-age=31536000, immutable";<br>} - 这样旧版本资源仍可访问（利于灰度回滚），新请求走全新路径，完全绕开缓存冲突问题
验证是否清理成功，不能只看命令返回
清理后务必验证实际效果，而不是只信终端输出：
- 用
curl -I https://yoursite.com/xxx.js查看响应头中X-Cache-Status是否从HIT变为MIS或BYPASS - 检查 Nginx 错误日志（
error_log）是否有cache file not found类提示，确认旧缓存确实被移除 - 对关键资源做真实浏览器访问，禁用开发者工具的 “Disable cache”，观察 Network 面板中 Status 是否为
200（非304）且响应体内容已更新
