维护期间应通过精准 location 匹配+状态码/路径/头信息组合实现局部短缓存，如 location = /status { expires 60s; }、proxy_cache_valid 503 10s;，并用 map 动态控制灰度，上线前验证响应头，下线后 purge 缓存并重载配置。
维护期间需要临时缩短缓存有效期，核心是“快速生效、按需覆盖、不干扰常态策略”。不能全局改 expires 或 proxy_cache_valid，而应通过精准的 location 匹配 + 状态码/路径/头信息组合，实现局部、可逆、可验证的短缓存控制。
用独立 location 块覆盖关键路径
对即将维护的页面或接口路径（如 /status、/health、/api/v1/maintenance），单独定义 location，绕过原有缓存规则：
- 匹配路径优先级高于通用正则，例如：
location = /status { ... }或location ^~ /api/v1/maintenance { ... } - 在该块内显式设短时效：
expires 60s;或add_header Cache-Control "public, max-age=60" always; - 若走反向代理，同时加
proxy_cache_valid 200 60s;，避免上游响应头被忽略
按响应状态码动态降级缓存
维护中常返回 503（Service Unavailable）或自定义 423（Locked），可针对这些状态码单独设极短缓存，防止浏览器或 CDN 长期缓存错误页：
-
proxy_cache_valid 503 10s;—— 仅缓存 10 秒，确保用户很快看到最新维护状态 -
proxy_cache_valid 423 30s;—— 适用于需人工确认的锁定场景 - 配合
proxy_cache_use_stale error timeout http_503;，允许在上游异常时短暂返回旧缓存，提升可用性
用 map 指令结合请求特征灵活控制
当维护需灰度生效（如只对特定 IP、Header 或 Cookie 用户启用），可用 map 动态生成缓存策略：
- 定义变量：
map $http_x_maintenance_mode $cache_ttl { "on" "10"; default "3600"; } - 在 location 中引用：
expires $cache_ttl;或add_header Cache-Control "max-age=$cache_ttl" always; - 配合
add_header X-Maintenance-Active $cache_ttl;方便前端或监控识别当前策略
上线前验证与下线后清理
短缓存策略是临时手段，必须闭环管理：
- 改完立即用
curl -I检查目标 URL 的Cache-Control和Expires响应头是否更新 - 若使用 proxy_cache，维护结束前执行
proxy_cache_purge清除已缓存的短时效内容，避免残留 - 恢复常态配置后，建议重启 Nginx 或至少重载（
nginx -s reload），确保 map 变量和 location 优先级重新加载
