应优先用 map 替代 if + 正则匹配，因 map 在启动时构建哈希表、查询 o(1)；http→https 跳转需置于 server 块顶层；禁用嵌套 if、if 内 rewrite last 及动态正则；文件存在性判断推荐 try_files。
避免 Nginx Rewrite 规则中因过多 if 判断导致性能下降，核心是减少运行时条件判断和正则匹配开销。if 块本身不慢，但嵌套使用、配合 rewrite 或正则表达式时，会触发 PCRE 引擎反复编译与回溯，尤其在高并发下极易成为瓶颈。
优先用 map 替代 if + 正则匹配
map 指令在 Nginx 启动时完成哈希表构建，查询为 O(1)，完全避开每次请求的正则执行。适合处理大量静态路径映射（如 /old → /new）或简单 host、协议判断。
- 在
http{}块顶部定义映射，例如：map $uri $redirect_to {<br> /old /new;<br> /about /about-us;<br> default "";<br>} - 在
server{}中只做一次变量判空：if ($redirect_to) { return 301 $redirect_to; } - 切勿在
map中写正则（如~^/v\d+/），否则退化为运行时匹配，失去性能优势
把重定向逻辑提到 server 块最顶层
越早响应，越少执行后续流程（location 匹配、root 解析、缓存检查等）。HTTP → HTTPS 这类通用跳转应直接写在 server 块开头，而非包裹在某个 location 内。
- 正确写法：
if ($scheme = http) { return 301 https://$host$request_uri; }
放在listen和server_name下方、任何location之前 - 避免拆成两步：先跳 HTTPS，再跳 www；应合并为单次跳转，防止链式重定向
精简 if 使用场景，禁用危险组合
if 仅适用于简单、确定性判断，比如固定字符串比较或基础变量判空。以下情况必须规避：
- 嵌套
if块（如if ($a) { if ($b) { ... } }）—— 每层都增加判断开销 -
if内含rewrite ... last—— 会触发 location 重新匹配，可能造成循环或遗漏 proxy_pass -
if ($arg_x ~ ".*")类动态正则 —— 变量未过滤即参与匹配，易被构造攻击并引发 ReDoS - 多个
if共享同一变量赋值逻辑 —— 变量求值时机不可控，结果难预测
用 try_files 替代 if + rewrite 的文件存在性判断
常见需求如“先找缓存文件，不存在则代理到后端”，用 if (-e $request_filename) 实际会触发两次系统调用（-e 检查 + rewrite 后重匹配），而 try_files 是原子操作，更轻量可靠。
- 低效写法：
if (-e $request_filename) {<br> rewrite ^/(.*)$ /cache/$1 break;<br>} - 推荐写法：
try_files /cache/$uri /cache/$uri/ @backend;
搭配location @backend { proxy_pass ... }
