nginx缓存清理需先确认路径再操作，避免误删；推荐使用ngx_cache_purge模块通过purge请求精准清除指定url缓存，proxy_cache与fastcgi_cache须分别处理且不可混用。
确认缓存路径再动手删，别直接 rm -rf /var/cache/nginx/*
盲目清空整个 /var/cache/nginx/ 目录会连带删掉所有缓存 zone 的数据，包括你没打算动的其他站点缓存。更危险的是：如果多个 proxy_cache_path 指向同一父目录（比如都用 /var/cache/nginx 作根），rm -rf 会一锅端。
正确做法是先定位真实缓存目录：
- 运行
sudo nginx -T 2>&1 | grep proxy_cache_path，看输出里实际生效的路径和keys_zone名称 - 注意
levels=1:2表示缓存文件按哈希散列到子目录，真实文件不在顶层，但rm -rf *仍会递归清除全部 - 若配置中用了变量（如
$hostname），路径可能动态生成，得结合proxy_cache_key和请求实际计算
用 ngx_cache_purge 实现按 URL 精准清理
手动删文件只能全量或靠脚本猜哈希，而 ngx_cache_purge 支持 HTTP PURGE 请求，直接按原始 URL 清对应缓存——这才是线上环境该用的方式。
但注意它不是默认模块，必须重新编译 Nginx：
- 检查当前 Nginx 是否已含该模块：
nginx -V 2>&1 | grep -o ngx_cache_purge，无输出就得重编译 -
proxy_cache_purge指令的参数必须和proxy_cache_key严格对齐，否则 404 或静默失败；常见坑是漏了$is_args$args导致带查询参数的 URL 清不掉 - 权限控制别只写
allow 127.0.0.1，生产环境建议绑定内网运维 IP 段，避免被外网滥用
清理时用：curl -X PURGE http://example.com/api/data?version=2，返回 200 表示命中并删除，404 表示未缓存或 key 不匹配。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
nginx -s reload 不等于清缓存，只是重载配置
很多人以为 nginx -s reload 会清掉内存里的缓存状态，其实它只重新加载配置、平滑切换 worker 进程，proxy_cache 和 fastcgi_cache 的磁盘文件和共享内存（keys_zone）完全不受影响。
真正能间接触发部分清理的只有：
-
systemctl restart nginx：会终止旧 worker，新进程启动时不会继承旧缓存元数据，但磁盘文件还在，下次请求仍可能复用 - 配置中显式关闭缓存，如加
proxy_cache off;后 reload，后续请求不再写入，但已有缓存文件仍占磁盘 -
inactive=60m这类过期策略是后台异步清理，不实时，且依赖访问触发
FastCGI 缓存要单独处理，路径和机制都不同
proxy_cache 和 fastcgi_cache 是两套独立系统：前者代理后端 HTTP 服务，后者缓存 PHP-FPM 等 FastCGI 响应，它们的配置指令、缓存路径、清理方式互不兼容。
查 FastCGI 缓存位置不能用 proxy_cache_path，得找 fastcgi_cache_path：
- 执行
sudo nginx -T 2>&1 | grep fastcgi_cache_path获取路径 - 常见路径是
/var/run/nginx-cache或/dev/shm/nginx-cache（内存盘），删法一样，但绝不能和 proxy 缓存混为一谈 - 没有官方 purge 模块支持 FastCGI 缓存，想精准清理只能靠改
fastcgi_cache_key配合版本号，或停服务后清盘
最易被忽略的一点：如果你同时开了 proxy_cache 和 fastcgi_cache（比如 Nginx 既反代又直跑 PHP），两个缓存层可能嵌套生效，清的时候得两边都查、两边都动。
