必须在敏感路径的nginx配置中精确匹配并设置cache-control: no-store, no-cache, must-revalidate, max-age=0、pragma: no-cache和expires: 0，同时禁用fastcgi头忽略、反向代理缓存，并验证响应状态码为200且size显示“from network”。
直接在响应头中写入 Cache-Control: no-store, no-cache, must-revalidate, max-age=0，并配合 Pragma: no-cache 和 Expires: 0，才能真正阻止浏览器和中间代理缓存敏感页面。仅设 no-cache 不够——它允许暂存但强制校验，而 no-store 才是彻底禁止存储的硬性开关。
明确匹配敏感路径并注入强缓存控制头
不要全局一刀切，而是精准作用于登录页、用户中心、订单详情等动态敏感路径：
- 用正则 location 精确匹配后缀或路径，例如：
location ~* ^/(login|profile|order|api/user) { ... } - 在该块内添加完整响应头：
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";<br> add_header Pragma "no-cache";<br> add_header Expires "0";
- 注意：若使用 FastCGI（如 PHP），需禁用其忽略指令：
fastcgi_ignore_headers Cache-Control;，否则后端可能覆盖你设置的头
避免已缓存内容“滞留”导致配置失效
新配置上线后，旧缓存仍可能被浏览器复用（尤其 F5 刷新时返回 304）：
-
no-store对新请求立即生效，但无法清除浏览器已存的旧缓存文件 - 建议搭配版本化 URL 或资源指纹（如
/profile?v=20260729），让浏览器视为全新资源 - 开发/测试阶段可临时加
add_header X-Reload-Required "1";辅助验证是否真走服务端
防止反向代理层缓存干扰
如果 Nginx 同时作为反向代理启用 proxy_cache，单靠响应头还不够：
- 在敏感 location 中显式禁用代理缓存：
proxy_no_cache 1;<br>proxy_cache_bypass 1;
- 确保后端返回的
Cache-Control: private或no-store未被proxy_ignore_headers屏蔽 - 对带 Cookie 或 Authorization 的请求，务必在
proxy_cache_key中包含$http_cookie，避免不同用户共享缓存
验证是否真正生效
别只看响应头是否存在，要确认行为符合预期：
- 打开开发者工具 → Network 标签 → 刷新页面，检查响应状态码：应始终为 200（而非 304），且 Size 列显示“from network”，非 “from memory cache” 或 “from disk cache”
- 尝试 Ctrl+R（强制刷新）和 Ctrl+Shift+R（清缓存重载），两者都应发新请求
- 用 curl 模拟请求：
curl -I https://yoursite.com/login，确认返回头含Cache-Control: no-store
