nginx响应头优化核心在于精简内容、避免冗余与动态计算。应减少重复add_header、禁用server_tokens、慎用map变量、优先expires指令、合理控制vary头。
Nginx 本身不执行“响应头序列化”这一计算密集型操作——它只是按配置拼接字符串并写入响应头部缓冲区。所谓“序列化性能”问题，实际多源于冗余头字段、重复设置、作用域错配或动态计算开销（如 map 变量频繁求值）。优化重点不在“加速序列化”，而在于精简头内容、避免运行时冲突、减少条件判断开销。
以下是从实操角度出发的几类关键优化方式：
减少响应头数量与重复设置
Nginx 每次响应都会遍历所有 add_header 指令并追加到响应头缓冲区。若在多个嵌套块（如 http → server → location）中重复添加相同头（如多次 add_header Cache-Control ...），不仅增大响应体积，还会触发内部头合并逻辑，增加开销。
- ✅ 只在最精确的作用域设置必要头：静态资源用
location块，安全头用server或http块； - ✅ 禁用默认
Server头：server_tokens off;避免每次响应都插入Server: nginx/1.24.0； - ❌ 避免在
http块中add_header X-Content-Type-Options "nosniff"后，又在某个location中再次add_header同名头——后者会覆盖前者，但中间仍发生两次解析。
避免 map + add_header 的高频动态求值
像 add_header Cache-Control $cache_control; 这类依赖 map 变量的配置，会在每次响应时根据 $sent_http_content_type 计算 $cache_control 值。若 map 规则复杂或匹配分支多（如几十种 MIME 类型），可能引入微小但可测的 CPU 开销。
- ✅ 对常见静态类型（
.js,.css,.png）使用location块直接add_header，绕过map； - ✅ 将
map逻辑收敛到顶层http块，避免在server或location中重复定义； - ✅ 不要用正则过度匹配：
~*text/.*比~*text/html更耗时，优先用精确前缀。
合理使用 expires 替代部分 Cache-Control 设置
expires 指令由 Nginx 内置时间计算模块处理，比 add_header Cache-Control "max-age=..." 更轻量（后者是纯字符串拼接，但需先构造变量再插入）。对简单过期策略（如“缓存 1 年”），优先用：
location ~* \.(js|css|png|jpg|gif)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
而非：
add_header Cache-Control "public, max-age=31536000, immutable";
前者由 Nginx 时间模块一次计算，后者每次响应都做字符串组装。
控制 Vary 头的滥用
add_header Vary Accept-Encoding; 是 gzip 必需的，但若叠加 add_header Vary Origin; 或 add_header Vary User-Agent;，会显著降低 CDN 和浏览器缓存命中率，间接导致更多 200 响应（而非 304），加重后端和网络负担。
- ✅ 仅在真实需要时设
Vary：比如 CORS 场景下Vary: Origin合理； - ❌ 不要为所有请求加
Vary: User-Agent—— 它几乎从不提升用户体验，却让缓存失效成倍增加。
不复杂但容易忽略。
