必须使用 cache-control: no-store, no-cache, must-revalidate 组合指令，精准配置于敏感路径（如 /api/payment/），并禁用 etag 和 last-modified，确保 https 下机密接口响应绝不缓存。
要确保 HTTPS 路径下的机密交易接口（如支付、转账、身份验证等）在浏览器中绝不留存本地缓存，核心是让浏览器彻底放弃存储响应内容——不是“不直接使用”，而是“连临时文件都不写”。这必须用 no-store 指令，且需配合其他指令形成防御性组合，避免被客户端或中间插件绕过。
必须启用 no-store 指令
no-store 是唯一能真正禁止缓存的指令：它要求浏览器和所有中间节点（包括开发者工具的“Network”面板缓存、HTTP代理、甚至某些安全扩展）不得将响应体或头信息以任何形式写入磁盘或内存。其他指令如 no-cache 或 max-age=0 仍允许缓存副本存在，只是强制每次使用前校验，不符合“绝不留存”的要求。
- 正确写法：
Cache-Control: no-store - 错误写法：
Cache-Control: no-cache, max-age=0（仍会缓存，仅强制验证） - 错误写法：
Cache-Control: private, max-age=0（私有缓存仍可存在）
补充 must-revalidate 和 no-cache 增强语义一致性
单独 no-store 已足够阻止缓存，但加上 must-revalidate 和 no-cache 可覆盖部分老旧客户端或非标准实现的解析偏差，强化“不可缓存”的意图表达：
-
must-revalidate：明确要求一旦缓存过期（即使理论上不会发生），也必须回源验证——进一步堵住边缘情况 -
no-cache：与no-store并存时，不影响其效力，但能兼容部分只识别no-cache的旧代理逻辑 - 推荐组合：
Cache-Control: no-store, no-cache, must-revalidate
Nginx 配置示例（精准匹配交易路径）
不要全局设置，而应针对具体敏感路径（如 /api/checkout、/auth/token）做 location 级别拦截，避免误伤其他接口：
location ^~ /api/payment/ {
add_header Cache-Control "no-store, no-cache, must-revalidate";
# 同时建议禁用 ETag 和 Last-Modified，避免协商缓存机制残留
add_header ETag "";
add_header Last-Modified "";
# 其他业务逻辑...
}
- 使用
^~前缀确保前缀匹配优先于正则，提升性能与确定性 - 避免用
expires -1或expires epoch替代 —— 它们只影响Expires头，对no-store无意义，且可能与Cache-Control冲突 - HTTPS 本身不改变该配置行为，Nginx 在 TLS 终止后即按明文规则注入响应头
额外验证要点
配置生效后，需通过实际请求确认响应头是否正确输出，且无覆盖：
- 用 curl 检查：
curl -I https://yourdomain.com/api/payment/init，确认返回头含Cache-Control: no-store, no-cache, must-revalidate - 打开浏览器开发者工具 → Network → 查看该请求的 Response Headers，确认无其他中间件（如反向代理、CDN、应用框架）覆写或删除该头
- 测试页面回退、刷新、F5、Ctrl+R 等操作，确认每次均触发全新请求（Status 始终为 200，而非 304）
