proxy_cache可缓存动态接口，但需有节制：优先缓存读多写少、实时性要求低的接口，精准构造cache_key，按状态码分级设置短时效缓存，并配合bypass、purge等机制主动管理生命周期。
直接用 proxy_cache 缓存动态接口是可行的，但不能照搬静态资源那一套——关键在于“有节制地缓存”，既要提速，又不能返回过期或错乱的数据。
明确哪些动态接口适合缓存
不是所有 API 都该缓存。优先考虑：
- 读多写少、变更频率低的接口，比如商品详情（
/api/products/123）、城市列表、配置信息 - 对实时性要求宽松的场景，例如用户等级展示、统计类数据（允许秒级或分钟级延迟）
- 高并发、低计算开销但频繁回源的请求，比如未登录用户的首页推荐
- 明确排除登录态强相关、支付、提交类等绝对不可缓存的路径（如
/api/order/create）
精准定义缓存键（proxy_cache_key）
默认 key 容易导致缓存污染。比如带分页参数 ?page=1 和 ?page=2 若共用同一 key，会互相覆盖。应显式构造唯一、语义清晰的 key：
- 包含协议、域名、路径、必要参数（剔除干扰项如
utm_*、ts时间戳） - 示例：
proxy_cache_key "$scheme://$host$request_uri$is_args$arg_id$arg_category"; - 若需区分用户角色或登录态，可加入
$cookie_token或$http_authorization，但注意：含用户标识的缓存必须严格隔离，否则造成数据泄露
分级设置缓存有效期（proxy_cache_valid）
动态内容不适用“缓存1年”这种策略。应按响应状态码和业务含义分别控制：
-
proxy_cache_valid 200 302 10s;—— 成功响应只缓存 10 秒，兼顾新鲜度与压力缓解 -
proxy_cache_valid 404 1m;—— 缓存 404 结果 1 分钟，避免反复查询不存在的资源 - 配合后端返回的
Cache-Control: max-age=30，可用proxy_cache_use_stale updating实现“后台更新时仍返回旧缓存”，进一步平滑抖动
主动控制缓存生命周期
靠过期时间被动清理不够灵活，需辅以主动机制：
- 用
proxy_cache_bypass $arg_nocache $cookie_admin;让开发或管理员加?nocache=1直接绕过缓存调试 - 配合 Purge 接口（如 Nginx Plus 或第三方模块），在数据变更后主动清除对应 key，例如发布新商品后调用
curl -X PURGE https://api.example.com/api/products/123 - 用
proxy_no_cache拦截敏感请求，如含Authorization头但未携带有效 token 的请求，一律不缓存
