动态内容可缓存的关键在于识别读多写少、低敏感、参数明确的场景，构造稳定缓存键，结合主动失效与stale-while-revalidate机制，并对私有数据、状态变更等敏感操作坚决绕过缓存。
动态生成内容天然与缓存存在张力——它每次响应可能不同，但又常具备“读多写少、容忍短时延迟、区分度明确”的可缓存特征。关键不是回避缓存，而是让缓存链在动态前提下依然稳定、可控、不污染。
精准界定哪些动态内容值得缓存
不是所有动态接口都该进缓存。优先缓存那些：
- 更新频率低（如商品列表每5分钟变一次，用户权限每小时同步一次）
- 无强身份绑定（避免缓存含 user_id、session_id 的响应；个性化部分用前端异步加载或 ESI 分片）
- 参数组合有限且语义清晰（如
/api/news?category=tech&page=1和?category=sports&page=1应视为两个独立缓存项） - 对实时性不敏感（排行榜、聚合数据、活动倒计时等允许 10–60 秒延迟）
构造稳定、高区分度的缓存键
缓存键不稳定是破坏缓存链的主因。常见错误是把 cookie、authorization、随机跟踪参数（utm_*, _t=）直接混入 key，导致同一逻辑请求生成大量冗余副本。
- 默认剔除干扰变量：禁用
$cookie_*、$http_authorization，除非明确需按用户隔离 - 归一化查询参数：用
map指令过滤无意义参数，例如剔除utm_source、_r=123 - 推荐基础键结构：
proxy_cache_key "$scheme$host$request_uri";——覆盖协议、域名、路径及标准化后的参数，兼顾通用性与稳定性
主动失效 + 容错更新，不让缓存“过期即崩”
依赖 TTL 被动过期，会导致热点内容更新后出现“旧数据残留”或“回源雪崩”。必须双轨并行：
-
发布即 purge：后端配置变更、运营上线后，由发布系统调用 Nginx 的
PURGE接口主动清除对应缓存，例如：curl -X PURGE https://cdn.example.com/purge/api/config -
stale + background update：设置
proxy_cache_use_stale updating;和proxy_cache_background_update on;，让过期缓存仍可返回，同时后台静默刷新 -
加缓存锁：启用
proxy_cache_lock on;，防止高并发下多个请求同时回源打垮后端
敏感操作坚决绕过，不缓存就是最安全的缓存
以下场景必须显式跳过缓存：
- 含用户私有数据的接口（如
/api/user/profile），除非已做 token 化 key 或前端分离 - 状态变更类请求（POST/PUT/DELETE），即使返回 200 也不应缓存响应
- 带未校验输入的路径（如
/user/..%2fetc%2fpasswd），Nginx 需配合if ($request_uri ~ "\.\.") { return 400; }拦截 - 错误响应（404/500）慎缓存，若缓存需设极短 TTL（如 1–5 秒），避免错误被放大
