实时性高的动态内容（如登录页、订单状态页、用户仪表盘、api接口）必须禁用缓存，通过nginx的cache-control: no-store、pragma: no-cache、expires: 0三重响应头彻底阻止存储，并区分动静态资源精细化控制。
实时性要求高的数据（比如登录页、订单状态页、用户仪表盘、API接口返回的动态JSON）必须绕过缓存，确保每次请求都拿到最新结果。Nginx本身不主动“判断内容是否实时”，而是靠响应头精准控制客户端和中间代理是否缓存——关键在于不让缓存生效，而不是等它过期。
针对HTML、JSON等动态内容禁用缓存
这类内容通常由后端生成，更新频繁或含用户私有信息，缓存不仅无益，还可能引发安全或一致性问题。推荐在Nginx中按路径或后缀强制清除缓存语义：
- 在对应
location块中设置三重响应头，覆盖所有常见缓存机制：add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";add_header Pragma "no-cache";add_header Expires "0"; - 避免只写
no-cache：它仍允许缓存存储，只是每次需向服务器验证新鲜度，对实时性不够彻底；no-store才是真正禁止存储的硬性指令。 - 如果该location代理后端服务（如Node.js或Java应用），注意Nginx默认会继承上游响应头。可在
proxy_hide_header中屏蔽后端返回的Cache-Control，再由Nginx统一注入自己的策略。
区分动静资源，避免误伤静态文件
禁用缓存不能“一刀切”。JS/CSS/图片等静态资源仍应长期缓存以提升性能，否则会拖慢整站体验。正确做法是按文件类型或URL路径做精细化控制：
- 对HTML页面（如
location / { ... }或location ~ \.html$ { ... }）启用上述禁用配置； - 对静态资源路径（如
location /static/、location ~* \.(js|css|png|jpg|woff2)$）单独设置长缓存，例如：expires 30d;add_header Cache-Control "public, immutable"; - 若使用构建工具（如Webpack/Vite），建议配合文件哈希命名（
app.a1b2c3.js），让静态资源天然支持强缓存，无需担心更新失效。
敏感与个性化页面必须跳过缓存
包含用户身份、权限、临时令牌或实时状态的页面，即使内容看似“静态”，也不应被共享缓存（如CDN、公司代理）保存。此时需额外强调私有性：
- 在禁用缓存头基础上，加入
private指令：add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0, private";
它明确告诉中间代理“这个响应只对当前用户有效，别存也别共享”。 - 对API接口（如
location /api/），可进一步限制方法：仅对GET以外的请求（如POST、PUT）默认不缓存，而GET /api/orders这类查询接口，若需实时，同样适用上述全禁用策略。 - 若业务允许部分缓存，可用
Cache-Control: max-age=5（5秒过期），但务必确认后端能承受每5秒一次的请求压力，且前端做好加载态提示。
核心逻辑很直接：实时性优先时，缓存不是“设短一点”，而是“不该存在”。用响应头从源头切断缓存链条，比依赖过期时间更可靠、更可控。
