add_header不能覆盖已存在的cache-control头，因其仅追加不覆盖；正确方式是用expires设静态资源、proxy_cache_valid或后端控制动态内容，必要时用headers-more模块的more_set_headers强制覆盖。
在 Nginx 中，add_header 可以向响应头中添加自定义 HTTP 头，但**不能用于覆盖或修改已由 Nginx 内部指令（如 expires、etag）或上游服务设置的 Cache-Control**。直接用 add_header Cache-Control "..." 在多数场景下是无效的——尤其当后端应用（如 PHP、Node.js）或 Nginx 自身的 expires 已设置了该头时，新添加的头会被忽略或重复出现，导致行为不可控。
为什么 add_header 不适合设 Cache-Control
add_header 是“追加”而非“覆盖”机制：它只在响应头尚未存在同名字段时生效；一旦 Cache-Control 已被设置（例如通过 expires 指令、proxy_pass 后端返回、或 FastCGI 应用输出），add_header 就不会起作用，甚至可能造成多个 Cache-Control 头并存（违反 HTTP 规范，部分客户端取第一个，部分取最后一个，结果不确定）。
正确设置 Cache-Control 的推荐方式
应优先使用语义明确、行为确定的原生指令：
-
静态资源用
expires：对 CSS/JS/图片等，配合expires+add_header ETag ...更可靠。例如：location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {<br> expires 1y;<br> add_header Cache-Control "public, immutable";<br>}
这里expires会自动设置Cache-Control: max-age=...和Expires，而immutable是补充属性，因max-age和immutable不冲突，可安全追加。 -
动态内容用
proxy_cache_valid或后端控制：若走反向代理，应在proxy_cache_valid中定义状态码对应的缓存时长，Nginx 会自动写入合规的Cache-Control；更灵活的做法是让后端（如 Express、Django）直接输出精确的Cache-Control，Nginx 不干预。 -
必须覆盖时，用
more_set_headers（需安装 headers-more 模块）：该模块提供more_set_headers "Cache-Control: ..."，可强制覆盖已有头。编译 Nginx 时加入 headers-more 即可使用。
精细化缓存的典型配置示例
按资源类型区分策略，避免一刀切：
-
HTML 页面（不缓存）：
location = / {<br> add_header Cache-Control "no-cache, no-store, must-revalidate";<br> add_header Pragma "no-cache";<br> add_header Expires "0";<br>} -
API 接口（协商缓存）：
location /api/ {<br> add_header Cache-Control "no-cache";<br> # 让客户端发起 If-None-Match 请求<br> add_header ETag $upstream_http_etag;<br>} -
带版本号的静态资源（强缓存 + immutable）：
location ~ ^/static/[a-f0-9]{8,}/(.+\.(js|css|png))$ {<br> expires 1y;<br> add_header Cache-Control "public, immutable";<br>}
验证与调试技巧
部署后务必用工具验证实际响应头：
- 终端执行：
curl -I https://yoursite.com/style.css，检查是否仅有一个Cache-Control头，且值符合预期； - 浏览器开发者工具 → Network → 点击请求 → Headers → Response Headers，观察是否有重复或冲突字段；
- 注意：Nginx 的
add_header在if块中受限（仅限 1.7.0+ 且有严格限制），避免在if中设置关键缓存头。
