企业官网建设流程全解析

刚接触Nginx缓存的时候，我一度以为缓存清理就是一行rm命令的事。直到后来负责的站点在更新活动页后，用户连续几个小时刷到的都是旧页面，领导还在群里问是不是服务器挂了，我才明白，Nginx缓存清理这活儿，看着简单，真要处理好还挺讲究。你不仅要知道缓存写在哪个目录，还得搞清楚它是由哪个key生成的，甚至连Nginx进程的工作用户是谁、目录权限对不对，都会影响清理效果。这篇文章我会从底层原理到具体操作，把Nginx缓存清理这件事拆开揉碎讲清楚，你照着做，基本就不会被缓存问题坑了。

1. Nginx缓存为什么要清理：先搞清缓存类型

1.1 容易被人忽视的“两级缓存”模型

在接触业务站点之前，我以为缓存只有一套，实际上常规架构里一般存在两层。一是用户浏览器里的缓存，由服务器通过Cache-Control、Expires等响应头告诉浏览器能缓存多久；二是Nginx自己维护的中间层缓存，比如proxy_cache、fastcgi_cache、uwsgi_cache。用户发来的请求先到Nginx，Nginx如果没命中缓存，才回源到后端应用服务器；如果命中了，就直接把磁盘上或内存里的副本返回给用户。

这两级缓存经常交错影响。比如你更新了商品详情页，后端数据库和页面模板都已经变了，浏览器里的老页面却还在，这是第一层缓存的问题；但如果用户清掉浏览器缓存后访问，看到的还是旧页面，那就得怀疑Nginx这一层了。也就是说，所谓Nginx缓存清理，绝大部分场景指的是清第二层，也就是在Nginx进程内部生成的缓存副本。

有一个判断手段非常实用：在Nginx配置里加上add_header X-Cache-Status $upstream_cache_status，然后刷新页面试试。第一次请求看到MISS，第二次请求看到HIT，基本就能确认请求命中了Nginx缓存。看到EXPIRED表示超过了配置的过期时间，Nginx会回源重新获取；看到BYPASS表示请求绕过了缓存。这一步定位，能避免我们对着浏览器缓存瞎忙活。

1.2 Nginx自身缓存与浏览器缓存的差别

用生活化的类比来解释：Nginx的缓存有点像小区快递柜，包裹先存在柜子里，你去取的时候随时都在；浏览器缓存则像你家冰箱，提前放进去的食物打开冰箱就能拿。前者由小区的管理员也就是Nginx管理，后者由你自己也就是浏览器管理，清理方式自然完全不同。

从操作层面看，Nginx自身的缓存清理是服务端行为。你要么删除缓存目录下的文件，要么借助缓存清理模块精准删除某一个URL对应的缓存副本。浏览器缓存清理则是客户端行为，普通用户只能通过浏览器设置清空，或者开发人员通过修改响应头让浏览器明白“这个资源不缓存”“这几个接口不能缓存”，再配合强制刷新常见快捷键。

这也是很多团队容易产生误会的地方。后端同学说“我已经清了Nginx缓存”，前端同学说“我也清了自己的浏览器缓存”，但页面依然不对。出现这种情况时，要去检查是否存在CDN的中间缓存，或者看请求到底有没有走预期的那一台Nginx，比如负载均衡后面有多台Nginx实例，只清了其中某一台，另外几台还存着旧缓存。这些细节我放到第五部分详细讲。

1.3 什么情况下你会迫切需要一个清理动作

缓存清理不是每天都要做的事，但下面几个场景几乎是必踩的：

• 上线新版本。页面模板或静态资源被替换，但缓存文件还是旧文件的内容，用户看到旧页面，甚至JS、CSS版本更新了，缓存里对应的URL还是老版本。
• 图片、附件等二进制文件被更新。常见于直接把原图覆盖到服务器目录，但Nginx缓存副本仍然保存旧图。
• 接口数据异常。后端返回了带错误状态或临时促销数据的响应，被Nginx缓存起来，接口恢复正常后，缓存还会继续输出错误内容一段时间。
• 磁盘空间告急。proxy_cache_path虽然有max_size控制，但业务增长太快，缓存占用可能把分区撑满，业务表现为写入失败，页面出现5xx错误。
• 权限变更。比如之前用root启动过Nginx，后来改成普通用户运行，缓存目录里残留的文件属主不对，重新生成缓存时报权限错误，Nginx就频繁回源。
• 测试阶段调优。你改了缓存有效期、缓存键策略，需要观察旧缓存对结果的影响，就得先清掉旧数据再看效果。

这些场景里，有的是主动清理，有的是被动排查。无论哪种，关键都在第一件事：找到缓存到底放在哪，以及每个缓存文件对应什么请求。

2. 动手之前，先定位Nginx把缓存写到了哪里

2.1 通过配置找到缓存根目录

定位缓存目录最直接的方法，就是看Nginx配置文件里proxy_cache_path、fastcgi_cache_path或uwsgi_cache_path的路径。

典型的代理缓存配置长这样：

proxy_cache_path /data/nginx_cache/static levels=1:2 keys_zone=static_cache:10m max_size=10g inactive=60m use_temp_path=off;

字段含义是这样的：/data/nginx_cache/static是缓存文件存储目录；levels=1:2是目录层级规则，Nginx会把缓存文件分散到两层目录里，避免单个目录下文件过多，I/O效率下降；keys_zone=static_cache:10m是命名缓存区域，大小10MB，这个区域只存放cache key的索引元数据，不存页面内容；max_size=10g表示控制缓存总上限，超过之后由Nginx的cache manager进程按LRU策略清理；inactive=60m表示60分钟内都没有命中的缓存会被视为不活跃，由后台进程清理。

很多刚入门的人觉得levels最难理解。简单说，levels=1:2表示最终文件的相对路径是“一层目录名取最后一个字符，二层目录名取最后两个字符，再加上完整的MD5文件名”。比如某文件名为5e2fb1a3c4d56789...，它可能存放在一级目录“9”下的二级目录“89”里。这种设计不是Nginx故意绕人，而是防止大量缓存文件堆在同一个目录里，导致stat、open等系统调用变慢。

如果配置文件层级比较多，可以用grep快速搜索：

nginx -T 2>/dev/null | grep -E "proxy_cache_path|fastcgi_cache_path|uwsgi_cache_path"

这条命令会输出所有加载生效的缓存路径配置。建议顺带检查是否有局部server块覆盖了全局缓存配置，有些站点会在server或location级别重新指定缓存区域路径，排查的时候容易漏。

2.2 看懂缓存文件名的MD5密钥规则

缓存文件为什么是一串看不懂的字母，答案是Nginx默认用proxy_cache_key生成缓存键。键的默认值是“$scheme://$host$request_uri”，也就是完整的访问URL串。既然请求URL是可见的，缓存文件名就是对这个URL串做MD5哈希后的值。

举例，如果缓存键是http://example.com/product/123，那么先算出MD5值：

printf '%s' "http://example.com/product/123" | md5sum

得到一串32位的十六进制字符串，比如1a2b3c4d5e6f7890abcdef1234567890。根据levels=1:2的规则，一级目录用最后1个字符，二级目录用最后2个字符，文件本身则放在二级目录里面。也就是说，最后的实际路径类似/data/nginx_cache/static/0/90/1a2b3c4d5e6f7890abcdef1234567890。

如果配置里自己定义了proxy_cache_key，比如写成“$host$request_uri”，那计算时就不能带scheme前缀。这一点非常坑，很多人在手工计算缓存文件名时删不到文件，就是因为没有按实际配置的键格式去算。

手工定位单个缓存文件时，我习惯用一段脚本：

url="http://example.com/product/123" hash=$(printf '%s' "$url" | md5sum | awk '{print $1}') dir1=${hash:31:1} dir2=${hash:30:2} file="/data/nginx_cache/static/$dir2/$dir1/$hash" ls -l "$file"

注意这里的层级顺序要根据实际配置调整，我这边只是演示级联规则，别照抄就完事。实际项目里，更稳妥的做法是先确认缓存键是什么，再从nginx -T输出里把proxy_cache_key找出来。

2.3 用curl验证缓存命中状态

有了配置和缓存键，下一步就是实际请求确认。我常用两个curl参数：-I只拿响应头，-o /dev/null不保存响应体。先访问一次让缓存生成，再访问第二次观察状态。

curl -I http://example.com/product/123

常见响应头里会带x-cache-status，如果没带，说明配置里没有添加add_header X-Cache-Status $upstream_cache_status，那就先给Nginx配置加上再reload。不过要注意，在add_header所在的块里，如果想同时输出多个自定义头，不能一股脑写多个add_header，部分版本当存在add_header时，会覆盖掉代理源设置的头部，这也算一个历史遗留坑。

验证完命中状态后，你再清理缓存就很有底气。你删掉的到底是哪个URL的副本，删完之后重新请求应该能从MISS开始重新缓存。如果清理后还是看到HIT，要么是删错了位置，要么是多机环境中请求被负载均衡转发到了另一台Nginx实例。

3. Nginx缓存清理的几种实操方案

3.1 简单粗暴但有效的全量清理

最直接的方式，清空缓存根目录。

rm -rf /data/nginx_cache/static/*

注意目录后面有一个星号，不是直接删根目录本身。直接rm -rf缓存根目录也可以，但目录正被Nginx进程使用时，后续Nginx会重新创建必要目录，不过如果缓存路径是由进程启动时创建的，直接删掉根目录后，Nginx在运行期可能进不去写入阶段，必须重新reload或重启才恢复。所以稳妥做法是删除目录“内部”的文件，保留目录本身。

缓存文件量小时这条命令无所谓，量大了千万别直接传rm。几万个甚至几十万个碎片文件的递归删除，会让磁盘I/O飙升，业务高峰期会拖慢所有读写操作。更舒服的做法是先把旧目录改名，再建一个同路径的新目录：

mv /data/nginx_cache/static /data/nginx_cache/static_old mkdir -p /data/nginx_cache/static chown nginx:nginx /data/nginx_cache/static

这样Nginx继续往新目录写，旧的目录慢慢在后台删。删除时可以用ionice降低优先级：

ionice -c3 rm -rf /data/nginx_cache/static_old

ionice -c3表示使用idle调度，只在磁盘空闲时清理，比较适合不想影响线上业务的场景。如果磁盘性能很弱，宁可分批删除也不要一次性梭哈。

3.2 按页面、API或正则表达式精确清理

全量清理适合活动上线、迁移等大动作，日常更常见的是精确清理某一条URL。原理就是前面说的：先把URL按缓存键规则算成MD5，再删对应文件。

一个我在实操中常用的简化脚本：

#!/bin/bash url="http://example.com/product/123" key=$(printf '%s' "$url" | md5sum | awk '{print $1}') cache_base="/data/nginx_cache/static" find "$cache_base" -name "$key" -type f -delete

这个方案不用关心两级目录的结构，遇到多台Nginx机器时，把同一个脚本分发到每台机器执行就行。需要匹配一组URL时，可以先把URL列表保存在文件里逐行处理，或者结合正则匹配文件内容。但缓存文件是二进制的，文件内容里不一定能找到关键正则，靠文件名MD5去匹配更靠谱。

另外一种更省事的思路，是故意让Nginx回源覆盖缓存：调用接口时带一个特殊参数，比如直接在URL后面加“?nocache=随机数”。如果配置的cache key默认包含完整request_uri，那么这个带参数的请求就不会命中原来的缓存。这个技巧适合即时验证，不适合长期使用，因为会污染缓存，多出垃圾副本。

3.3 定时任务自动清理

自动清理分两个层次。第一层是Nginx自身的cache manager进程，它会在后台按inactive、max_size等参数维护缓存生命周期。每当缓存项超过inactive时间，或者整个缓存总量快达到max_size，Nginx会自动删除旧文件。这一层不归我们手动控制，但对磁盘容量维护至关重要。

第二层才是我们手动加上的定时任务。通常用在业务方出现大量“僵尸缓存”，比如带有随机参数但未正确使用缓存键的接口，生成了上百万个不会再次命中的URL。这时可以写个脚本，每天深夜删除N天前创建的文件：

find /data/nginx_cache/static -type f -mtime +7 -delete

配合crontab大约长这样：

0 4 * * * /usr/local/bin/nginx_cache_clean.sh >> /var/log/nginx_cache_clean.log 2>&1

这个脚本在执行前最好检查一下nginx进程是否在运行，否则容易出现奇怪的权限错误；还要注意find -delete在某些老版本和大量文件的高并发删除场景下也可能打满磁盘，建议加上nice和ionice。定时任务的好处是减少人工介入，坏处是如果脚本写得粗糙，可能出现删错范围的风险，所以我建议先用find统计数量，再执行删除。

3.4 使用缓存清理模块

如果不想计算MD5，也不想删除整个目录，还可以用ngx_cache_purge模块。这是Nginx社区里常用来做精准清理的方案。它提供一个purge指令，匹配到特定请求时直接删除对应缓存文件。

你可以通过编译Nginx时加入参数，或者用动态模块方式加载。这里给出配置思路：

location ~ /purge(/.*) { allow 127.0.0.1; allow 10.0.0.0/8; deny all; proxy_cache_purge static_cache $scheme://$host$1; }

这样内部管理机需要清理静态资源时，只要访问https://域名/purge/product/123，模块就会把对应缓存删掉。这个动作等于把“清理”开放成了HTTP接口，权限控制非常关键。如果这层location不加allow/deny限制，等同于任何人访问都会触发对Nginx的删除操作，很容易变成“在线事故”。

使用模块的优点是可以被监控系统调用，比如哨兵系统发现某个页面缓存异常时，直接发一条PURGE请求就能快速恢复。缺点是编译和升级Nginx时要额外维护模块，部分系统仓库版本没有现成包。要不要引入，取决于你是不是经常需要按URL精确清理。

3.5 内容过期参数：让缓存自动失效

手动清理再方便，也不如让缓存本身设计得“短命”。在Nginx配置里通过proxy_cache_valid控制缓存时间：

proxy_cache_valid 200 304 12h; proxy_cache_valid 404 1m;

意思是200和304状态码的响应缓存12小时，404缓存1分钟。也可以配合后端返回的Cache-Control头来覆盖，如果后端动态判断某些页面不能缓存，Nginx就不会生成缓存。

实际项目中，我更推荐把“清理压力”前移：后端应用在更新数据时，主动调用一个内部接口清除相关URL，或者直接把页面响应头设为不缓存。Nginx缓存清理是兜底动作，真正高效的做法是让需要频繁变化的接口干脆不缓存，或者快速过期。否则你今天清一次，明天缓存又生成，永远都在追赶问题。

4. 不同场景下的缓存清理配置参考

4.1 反向代理场景

最常见的Nginx反向代理缓存是对后端源站的静态资源和页面做加速。基本配置长这样：

proxy_cache_path /data/nginx_cache/static levels=1:2 keys_zone=static_cache:10m max_size=10g inactive=60m; server { listen 80; server_name example.com; location /static/ { proxy_pass http://backend_upstream; proxy_cache static_cache; proxy_cache_key "$scheme$host$request_uri"; proxy_cache_valid 200 304 1h; add_header X-Cache-Status $upstream_cache_status; } }

这种方式的好处是减少回源请求，保护后端。风险是后端资源更新了，缓存却不及时。如果你用了ngx_cache_purge模块，可以在固定location里动态清理。没有模块的话，按前面的MD5规则算好位置，找到文件删除就行。

反向代理里还有一个细节：如果开启了gzip压缩，并且源站响应头里的Vary或Content-Encoding有差异，Nginx可能缓存出多个版本的压缩和非压缩副本。碰到这类问题，建议先统一后端响应的请求头策略，否则清理起来很容易漏掉其他版本副本。

4.2 FastCGI动态页面场景

动态站点比如PHP、Java等用fastcgi_cache，作用相近。配置文件示意：

fastcgi_cache_path /data/nginx_cache/fastcgi levels=1:2 keys_zone=fcgi_cache:10m inactive=60m; location ~ \.php$ { fastcgi_pass unix:/tmp/php-cgi.sock; fastcgi_cache fcgi_cache; fastcgi_cache_key "$request_method$host$request_uri"; fastcgi_cache_valid 200 60m; add_header X-Cache-Status $upstream_cache_status; }

动态页面缓存最怕的是带登录态或用户个性化内容。如果页面里有用户ID信息，而缓存键没排除Cookie，用户A登录后看到的页面可能被缓存并返回给用户B，这就是很严重的隐私泄漏问题。我通常会在配置里加上：

fastcgi_ignore_headers Cache-Control Set-Cookie;

这行配置告诉Nginx忽略源站的Set-Cookie头，避免响应带有Set-Cookie时直接跳过缓存。但注意，这只是让响应进入缓存，不代表用户数据安全。还是需要在业务里区分哪些页面能公共缓存，哪些页面必须个性化。

清理此类缓存时，原理和代理缓存完全一致。但动态页面常常包含HTTP头、HTTPS、带参数等多种变体，如果你平时没有把cache key整理规范，临时排查会非常痛苦。建议在配置里统一把$request_method也加进键，避免POST请求误命中GET缓存。

4.3 静态文件与浏览器缓存场景

静态文件通常由Nginx直接提供，不一定走proxy_cache，可能只是用了alias或root。这类文件被浏览器缓存的时间由expires指令控制：

location /assets/ { alias /data/site/assets/; expires 30d; add_header Cache-Control "public, immutable"; }

浏览器在30天内不会再向服务器发起资源请求，除非用户强制刷新。这种长期缓存的策略对性能很好，但更新文件名时必须同步改名，比如main.css改成main.20240506.css，否则用户拿到旧文件名对应的旧缓存。线上更新时，很多人只改了文件内容，没改文件名，结果怎么清Nginx缓存都没用，因为浏览器压根没把请求发到Nginx。

如果确实需要更新同名静态文件又无法改名，可以临时把expires调成0，或者设置Cache-Control为no-cache，让浏览器在下一轮请求时强制回源。这个过程不是一个简单的Nginx清理动作能解决的，要配合前端打包工具一起设计。真正懂得“缓存清理”的人，一定会知道这个道理：同样一个更新，在Nginx层需要清proxy缓存，在浏览器层需要改文件名或调整Cache-Control。

顺带提一下open_file_cache，它缓存的是文件句柄、元数据，不是页面内容。如果文件被替换但inode变化，Nginx一般会自动感知；但如果用相同文件名覆盖并且系统时间戳未刷新，测试时可能看到陈旧内容。常规项目里刷新静态文件最快的方式就是改文件名或者加query参数。

5. 缓存清理过程中的高频坑与排查实录

5.1 403问题：权限、属主、autoindex

Nginx缓存清理场景里，403频繁出现。一种情况是Nginx的worker进程没有权限访问缓存目录，导致回源后无法写入缓存，缓存一直MISS，且页面日志出现403。原因通常是缓存目录的属主不对。比如你用sudo mkdir创建了目录，目录属主是root，而Nginx是nginx用户运行，写入时毫无悬念地被拒绝。

解决办法是把目录给Nginx工作用户：

chown -R nginx:nginx /data/nginx_cache chmod -R 700 /data/nginx_cache

如果不知道Nginx运行用户，看nginx.conf第一行的user指令，或者执行ps aux | grep nginx，观察worker进程属于哪个用户。

另一种403和autoindex相关。有人为了方便文件浏览开启了autoindex on，把某个目录直接暴露成下载列表。恰巧这个目录刚好是缓存目录，等于把缓存文件的MD5文件名全部公开展示。如果站点文件夹下有敏感文件，又开了autoindex，就直接全文暴露了。我的建议是autoindex只在内网管理用途打开，并且用location严格限制IP访问，公网站点一般不要开。

5.2 缓存清完仍旧内容：浏览器与CDN残留

这是排查率最高的“假缓存问题”。Nginx缓存确实已经清掉了，但页面显示的还是旧内容。此时先不要怀疑清理动作，应该观察响应头。

用curl -I连续请求两次，对比关键字段。如果看到Cache-Control: max-age=3600且页面没有变化，说明浏览器在本地缓存生效，服务器根本没有收到请求。这时候你清Nginx缓存当然没用。解决方法是让用户强制刷新，或者在发布流程里使用Cache-Control和ETag配合协商缓存，确保文件更新后浏览器能够拿到200响应而不是直接读取本地缓存。

如果页面源已经更新，但用户访问区域还绕了一层CDN，那你们还需要清CDN缓存。CDN和浏览器缓存、Nginx缓存三者经常一起出现，Nginx缓存清理只是其中一环。排查顺序是：先看浏览器是否有缓存，再看请求有没有真正到达自己的Nginx，最后看Nginx是否返回HIT。有些人一上来就清Nginx，清了半天问题没解决，那是因为前面的链路根本没查。

5.3 Windows下Nginx配置cache的几个坑

很多开发机用Windows上的Nginx调试，报错里会出现类似[emerg] createfile() "d:/phpstudy_pro/www/admin2.com/nginx.htaccess"这类信息。这个错误看着吓人，其实常见原因有三个。

第一，磁盘路径里存在中文、空格或者特殊字符，Nginx在Windows下的win32 API对路径支持不够稳健。第二，配置文件保存时使用了带BOM的UTF-8编码，Nginx在读取文件时把头部BOM当成异常字节，直接报错。第三，nginx.htaccess这类文件名如果被当成了Nginx配置文件，但它在Windows下指向的路径与实际磁盘位置不符，或者文件不存在。

遇到这类报错，先用文本编辑器把配置文件另存为“无BOM的UTF-8”，再检查路径是否和真实磁盘路径一致。Windows下尽量统一用正斜杠表示路径，避免反斜杠转义混乱。测试配置时先用nginx -t，确认没问题再启动。

这里还要补充一点，Windows下的Nginx一般只用于本地开发，真正生产环境千万避免用Windows跑Nginx。一来文件句柄、缓存管理性能差很多，二来很多开源性能优化在Windows上效果一般，既然是要深入研究缓存清理，还是把主力环境放到Linux更省心。

5.4 清理缓存时磁盘IO飙升怎么办

大目录清理，最怕的是磁盘IO占用瞬间打满，业务响应变慢。我踩过一次，线上某台Nginx的缓存目录里有几十万个文件，直接rm -rf后系统负载狂飙，页面全部卡顿。从那以后我清理大目录都遵循一个原则：先隔离，再异步删除。

隔离的意思是先把旧目录改名为old，然后在原路径新建一个空目录。Nginx后续写入集中在新目录，不会和删除操作抢同一批inode。删除旧目录时用ionice降低优先级：

cd /data/nginx_cache mv static static_old_$(date +%Y%m%d) mkdir static ionice -c 3 rm -rf static_old_$(date +%Y%m%d)

另外，Nginx自己的cache manager进程在max_size达到上限后就会开始淘汰缓存，这个过程本身是平滑的。如果你设置了max_size，但inactive时间又特别长，缓存文件可能既不超期也不触发容量上限，那它们会一直躺在磁盘上。这种时候再考虑手动清理也不迟。

6. 几个实战排查案例，帮你把前面知识串起来

6.1 案例一：磁盘满导致缓存目录无法写入

有一次线上各接口突然大面积5xx，一查磁盘使用率已经100%。定位后发现某个日志目录占了一大半空间，Nginx缓存目录体积也不小。业务入口是Nginx反向代理，Nginx尝试写入新缓存时磁盘没有空间，只能回源，同时因为临时文件无法落盘，回源也受到影响。

处理时我先用du -sh /data/nginx_cache/static找出缓存目录的体量，再把大日志文件归档清空。接着把缓存目录整体mv到旁边，新生成一个空目录，这样不需要等待删除完成就能恢复服务。最后重新配置proxy_cache_path里的max_size，把上限调到一个稳妥的范围。这个教训让我养成了一个习惯：所有涉及Nginx的机器都会在监控里加上缓存目录使用率。

6.2 案例二：业务更新后留下大量僵尸缓存

某次运营活动结束后，产品方把活动页面里的图片批量替换为新版，但活动页URL没有变。发布脚本只替换了源站图片，没有清Nginx缓存，导致活动页图一直显示旧版。排查时先用curl -I看x-cache-status，确认是HIT，然后按URL算出MD5，找到缓存文件删除。清理完再请求一次，状态变成MISS，页面立即恢复。

后面我在发布脚本里加了一步：先调用清缓存接口，再检查文件。不是所有发布都要求清缓存，但至少给出一个可选参数，让需要清理的时候不用临时登录服务器找缓存位置。这个过程让我意识到，缓存清理不该是末日时刻的应急动作，而应该是发布流程里的标准动作之一。

6.3 案例三：API接口数据被缓存污染

某个接口返回了当前登录用户的信息，刚开始没配置缓存，后来为了优化性能，在Nginx加了一层fastcgi_cache，但cache key没有把Cookie或用户标识放进去。结果用户A登录时页面请求被缓存，用户B访问时Nginx直接返回了A的响应。把整个页面的缓存清掉后临时正常，下一轮又出现类似问题。

最终解决是把这类含用户维度的API单独取出，关掉Nginx缓存，只允许公共接口走缓存。排查结论让我意识到，缓存清理只能解决“缓存错了”的结果，真正要解决的是“不该缓存的内容不能进缓存”。如果你发现自己整天在清理同一个接口，更要想办法从缓存键和缓存策略上根除。

这段时间摸下来，我对Nginx缓存清理最大的感受是：清理本身不复杂，复杂的是搞懂什么能缓存、什么必须清理，以及缓存生命周期到底在哪里管理。建议每一位刚接手的基础运维都先做一件事，拿nginx -T把自己服务里所有cache相关配置和路径列出来，再对照着每个页面验证一遍命中状态。这套功夫做在前头，后面遇到“缓存清不掉”“页面不变”的情况，你至少知道问题出在哪一层，而不是盲目去删文件。缓存清理说到底只是一枚扳手，真正值钱的是你知道该拧哪个螺丝，以及为什么拧它。