应避免在location块中滥用if，尤其禁用if内嵌proxy_pass、fastcgi_pass或复杂条件判断；推荐用map预定义变量替代，以降低运行时开销、防止重匹配与性能退化。
直接查配置里有没有在 location 块中滥用 if，尤其是搭配 proxy_pass、fastcgi_pass 或复杂条件判断的场景——这是“if is evil”引发性能下降最典型的入口。
重点检查 if 出现的位置和上下文
官方明确指出：if 在 location 内部会触发隐式无名 location 创建，并可能引发重复的配置匹配（POST REWRITE 阶段重入 FIND CONFIG）、URI 二次解析、变量多次求值等问题。高频请求下会导致 CPU sys 时间上升、缓存失效加剧。
- 逐个扫描所有
location { ... }块，查找是否包含if ($xxx) { ... }结构 - 特别警惕
if块内出现proxy_pass、fastcgi_pass、rewrite（非return或简单rewrite ... last）等重量级指令 - 检查
if条件是否依赖动态变量（如$http_x_forwarded_for、$arg_token），这类判断每次请求都需字符串解析与匹配
用 map 替代大多数 if 判断逻辑
map 指令在 server 级预编译执行，开销极低，是官方推荐的替代方案。它不改变请求流程阶段，也不会触发重匹配。
- 把基于请求头、参数、cookie 的路由/上游选择逻辑，全部迁移到
map中定义变量，例如：map $http_user_agent $backend { default "app_v1"; "~*curl" "debug_api"; } - 在
location中直接使用proxy_pass http://$backend;，避免任何if - 需要返回特定状态码时，优先用
error_page + return组合，而不是if (...) { return 403; }
验证是否真由 if 引发性能退化
不要凭经验猜测，必须量化对比：
- 临时注释掉所有
if块（保留map和return），执行nginx -t && nginx -s reload - 用
wrk -t4 -c200 -d30s https://your-domain/api/test对比压测结果：QPS、P95 延迟、worker 进程 CPU 的 sys% 是否明显下降 - 检查
error.log是否仍有recv() failed (104: Connection reset by peer)或upstream prematurely closed connection——这些常是 if 导致连接状态混乱的副产物
顺带确认 rewrite 阶段是否被意外拉长
if 本身属于 rewrite 模块，在 SERVER_REWRITE 或 REWRITE 阶段执行。若多个 if 嵌套或与 rewrite 混用，会显著延长该阶段耗时。
- 检查是否在
server块顶层写了if，这会让所有子location都多一次条件判断 - 避免
if+rewrite ... redirect组合做跳转，应改用return 301或return 302 - 确认没有在
if中调用set修改变量后又用于后续 proxy_pass——这种写法极易引发变量作用域错乱
