Nginx全局变量本身不直接拖慢性能，但滥用set定义的自定义变量会在每次请求时重复执行赋值逻辑，尤其在http/server块中定义时开销显著；应下沉至location块、用map替代if+set、避免$request_body等高开销变量，并优先使用内建变量。
全局变量本身不会直接拖慢 Nginx，但不当使用会引入额外开销，尤其在高并发场景下容易放大性能损耗。
变量解析发生在每次请求处理时
Nginx 的内建变量（如 $remote_addr、$request_time）是惰性求值的，只在被引用时才计算，开销极小；但自定义变量（通过 set 指令定义）会在所在配置块的作用域内每次请求都执行赋值逻辑。如果 set 出现在 http 或 server 块顶层，它就会对每个请求重复执行，哪怕后续并未用到该变量。
- 避免在
http块中滥用set，尤其是涉及复杂字符串拼接或调用模块函数（如map或正则匹配）的操作 - 把变量定义尽量下沉到
location块中，确保只在真正需要时才计算 - 用
map指令替代多层if + set，更高效且支持缓存
变量缓存机制有限，不能自动优化重复计算
Nginx 不会对自定义变量做跨请求缓存，也不自动去重相同表达式。例如连续写两遍 set $host_upper "${host}";，就等于做了两次字符串复制；若用 map 预定义映射关系，则结果可复用。
-
map块中的键值映射在配置加载时预编译，运行时仅查表，比运行期set快得多 - 避免在日志格式中频繁调用需实时计算的变量（如
$request_body），它会触发请求体读取，显著增加延迟和内存压力 - 禁用不必要的变量插值，比如
log_format main "req: $remote_addr $request";是安全的，但"body: $request_body"会强制读取并缓存整个请求体
作用域误用导致隐式重复与逻辑错误
全局定义的变量（如在 http 块中 set $flag "on";）会被所有请求共享同一内存地址，但 Nginx 多进程模型中每个 worker 是独立进程，变量实际是 per-request 生命周期——这里“全局”仅指配置可见性，并非跨请求共享。常见误区是以为设一次就能复用，结果发现每次请求仍要重新赋值。
- 不要依赖“全局变量”保存状态，Nginx 无进程间变量共享能力
- 若需跨 location 传递数据，优先用
add_header+ 后端解析，或用proxy_set_header转发，而非靠变量链式传递 - 调试时临时加的
set务必注释或删除，上线配置中每条set都有成本
内建变量比自定义变量更轻量
像 $uri、$args、$status 这类内建变量由核心模块直接提供，底层对接解析器字段，几乎无额外 CPU 开销；而 set $x "$uri?$args"; 这类操作需字符串拼接、内存分配、编码处理，QPS 上万时差异明显。
- 优先使用内建变量满足需求，查阅 官方变量索引 确认是否存在对应字段
- 用
rewrite_log on;+error_log ... debug;可观测变量解析行为，但仅用于诊断，线上禁用 debug 日志 - 压测前后对比
nginx -T | grep set | wc -l，控制自定义变量总数在个位数级别更稳妥
