nginx server块中if仅作轻量条件跳转，须统一收口于顶层、禁用location嵌套、优先正则预筛+变量缓存、高频分支前置、快速拒绝非法请求，并优先选用location/map等更稳原生指令替代。
在 Nginx 的 server 块中使用 if 指令处理复杂逻辑分支，本质是用轻量条件跳转替代重写或外部脚本，但必须严格约束使用边界——它不是编程语言的 if，而是配置层的“快捷开关”。真正复杂的判断不该塞进 if，而应前置到上游（如负载均衡器、API 网关）或后置到应用层。
只在 server 块用，避开 location 块嵌套
if 在 location 块内会触发隐式上下文重建，导致 rewrite、proxy_pass 等指令行为异常，且难以调试。所有条件判断应统一收口到 server 块顶层：
- 用
$scheme、$host、$request_method等内置变量做路由分流 - 把用户代理、来源域名、请求头特征等一次性提取并赋值给自定义变量（如
set $route_type "api"），后续逻辑基于该变量展开 - 禁止在
location /admin内再写if ($arg_token = "")—— 改为在server块里统一判断并设置标记
用正则预筛 + 变量缓存降复杂度
避免多层 if 嵌套。对需组合判断的场景（如“是移动端且来自微信内置浏览器且访问 /pay 接口”），优先用单条正则捕获关键特征，存入变量后再分支：
if ($http_user_agent ~* "(Mobile|Android|iPhone).*MicroMessenger") { set $is_wechat_mobile "1"; }if ($request_uri ~* "^/pay/") { set $is_pay_path "1"; }- 后续只需
if ($is_wechat_mobile = "1" && $is_pay_path = "1") { ... }—— 语义清晰，无嵌套
高频路径前置，失败快速终止
if 按书写顺序逐个求值，第一个为真即停止。把命中率最高的分支放在最前：
- 若 85% 请求是 GET，10% 是 POST，5% 是其他方法，就按
if ($request_method = GET)→if ($request_method = POST)→if ($request_method !~ ^(GET|POST)$)排序 - 用
return 444或return 405快速拒绝非法请求，不留给后续逻辑处理 - 避免在条件中调用耗时操作（如
-f /var/www/xxx检查不存在的文件），改用静态标记或 upstream 健康检查兜底
能用更稳方案就别用 if
if 是最后手段。以下情况请直接换用原生指令：
- 单纯根据 URI 路径分发：用
location ^~ /api/或location ~ \.php$，比if ($request_uri ~ /api/)更高效、更可靠 - 需要重定向 HTTPS：用
listen 80; return 301 https://$host$request_uri;，而非if ($scheme != https) - 需根据 Cookie 或 Header 设置不同 upstream：用
map指令预定义变量，再在proxy_pass中引用，零运行时开销
不复杂但容易忽略：if 的布尔逻辑是短路的，但 Nginx 不支持 AND/OR 运算符，多个条件必须用 && 或 || 拼接，且每个子表达式都需独立括号；同时，空字符串、未定义变量、数值 0 都被视作 false，这点和 Shell 不同，需显式判空。
