浏览器缓存本身非等保三级强制审计项，但配置不当会间接违反数据完整性、安全审计和访问控制要求；nginx通过精准设置cache-control等响应头，既提升性能又支撑合规：静态资源用immutable+max-age=31536000并配expires 1y，html设no-cache/must-revalidate，api接口默认no-store。
浏览器缓存本身不直接属于等保三级的强制审计项，但若配置不当，可能间接违反“数据完整性”“安全审计”和“访问控制”要求——比如缓存敏感 HTML 或 API 响应导致越权信息残留、未校验的旧页面绕过新权限逻辑、或缓存日志中暴露脱敏失败的参数。Nginx 通过精准控制 Cache-Control 等响应头，既能提升性能，又能支撑等保合规落地。
静态资源：用 immutable + 长期 max-age，确保内容不变性
带哈希或版本号的 JS/CSS/图片/字体（如 app.f3a8b2.js、logo.e9d1c4.png）内容实质固定，适合长期强缓存：
- 在 location 块中匹配扩展名：
location ~* \.(js|css|png|jpg|gif|woff2|svg)$ - 设置响应头：
add_header Cache-Control "public, immutable, max-age=31536000"; - 同时配
expires 1y;补全Expires头（兼容老旧客户端） -
关键前提：文件名必须含构建时生成的唯一哈希——否则
immutable会锁死错误版本，造成更新不可见
HTML 页面：禁用强缓存，强制每次校验
入口 HTML 通常动态生成，含权限判断、菜单状态等实时逻辑，浏览器不能跳过服务器直接复用本地副本：
- 匹配根路径或 HTML 文件：
location = / { ... }或location ~* \.html$ - 设
add_header Cache-Control "no-cache, must-revalidate";或"private, max-age=0" - 避免使用
max-age=300等短时效值——仍可能跳过服务端权限校验，导致用户看到过期结构或越权按钮 - 配合 ETag 或
Last-Modified（Nginx 默认开启），使校验请求返回 304，节省带宽又不失安全性
API 与 JSON 接口：默认 no-store，防敏感数据滞留
JSON 接口常返回用户数据、令牌、权限列表等高敏内容，浏览器不得缓存：
- 对
/api/、/v1/或*.json路径，显式关闭：add_header Cache-Control "no-store"; -
no-store比no-cache更严格：禁止写入磁盘、内存甚至 DevTools 的 Application → Cache Storage - 若个别接口允许弱缓存（如天气预报每10分钟更新），可设
max-age=600, stale-while-revalidate=30，但需确认后端未自带冲突的Cache-Control（Nginx 的add_header是追加，非覆盖）
缓存策略验证与等保衔接点
配完不验证，等于没配；而验证方式直接影响等保日志审计有效性：
- 重启后用
curl -I https://yoursite.com/app.js或浏览器开发者工具 Network 标签页，检查响应头是否含预期Cache-Control和Expires - 特别关注 HTML 和登录页响应头：必须不含
public或长max-age，否则测评时会被判定为“未控制前端缓存风险” - 若启用了
proxy_cache，检查X-Cache-Status和Age头，确保 HTML 不被 Nginx 自身缓存——等保要求“所有用户请求必须经服务端鉴权”，Nginx 缓存 HTML 会绕过后端权限逻辑 - 日志中记录的
$request_uri和$http_cache_control（需自定义 log_format）可用于回溯异常缓存行为，满足“安全事件可审计”要求
