nginx rewrite高级用法需精准把握变量作用域、执行阶段与上下文限制：内置变量如$uri（解码后路径）与$request_uri（原始uri）语义不同；rewrite在rewrite阶段顺序执行，last重新匹配location，break终止当前location内rewrite；if存在作用域陷阱，应优先用try_files或map替代。
Nginx 的变量系统是其配置灵活性的核心，而 Rewrite 规则的高级用法依赖于对变量、正则匹配和上下文作用域的精准把握。写好 Rewrite 不只是套正则，关键是理解变量何时可读、如何组合、在哪个阶段生效。
内置变量的可用性与生命周期
Nginx 变量分预定义变量（如 $uri、$args、$host）和自定义变量（set 指令定义）。但并非所有变量在所有指令块中都可用：
-
$uri 和 $request_uri 含义不同：前者是解码后且未重写的路径（如
/a%20b→/a b），后者是原始请求 URI（含编码、查询串）； -
$args 是查询参数字符串（如
a=1&b=2），修改它不会自动触发重定向，需配合 rewrite 或 return； - set 定义的变量只在当前请求生命周期内有效，且不能在 if 块外引用（Nginx 的 if 是伪指令，有作用域限制）；
- $scheme、$server_port 等变量在 http、server、location 中始终可用，但 $arg_xxx 类变量仅在请求解析后才就绪（即 location 内可靠）。
rewrite 指令的执行阶段与匹配逻辑
Rewrite 在 Nginx 请求处理的 rewrite 阶段 执行（早于 proxy_pass、root 等），且按配置顺序逐条处理。关键细节：
- 每条 rewrite 匹配成功后，默认会重新发起内部跳转（类似内部重定向），再次进入 rewrite 阶段 —— 这意味着后续 rewrite 仍可能执行；
- 加 last 标志：终止当前 location 的 rewrite，重新匹配 location（不跳出 server）；
- 加 break 标志：停止 rewrite 处理，直接执行本 location 后续指令（如 proxy_pass）；
- 加 redirect 或 permanent：返回 302/301，浏览器可见跳转；
- 正则捕获组（
(...)）在 rewrite 中用 $1、$2 引用，注意它们只在当前 rewrite 行有效，跨行不可用。
if + rewrite 的常见陷阱与替代方案
if 在 location 中使用极易引发意外行为，例如：
-
if ($args ~* "debug=1") { rewrite ^(.*)$ $1? break; }—— 看似清除 debug 参数，但 $args 修改不改变原始请求，且 if 内 rewrite 的 break 并不阻止后续 location 指令执行； -
if (!-f $request_filename) { rewrite ^/(.*)$ /index.php last; }—— 正确，但应优先考虑 try_files：try_files $uri $uri/ /index.php?$args;，更高效且无 if 副作用； - 多个 if 条件叠加时，Nginx 不支持 and/or 逻辑，只能靠嵌套或拆成多个 location；
- 避免在 if 中使用 proxy_pass、root 等指令 —— 它们在 if 内部的行为未定义，易出错。
高级技巧：基于变量的动态路由与条件重写
真正灵活的规则依赖变量组合与上下文判断：
- 根据域名后缀做差异化 rewrite：
rewrite ^/api/(.*)$ https://api.$host/$1 permanent;（注意 $host 是客户端 Host 头，非 server_name）； - 提取并重用查询参数：
if ($args ~* "id=(\d+)") { set $id $1; rewrite ^/item$ /item/$id? last; }； - 结合 map 实现多条件映射（比 if 更安全）：map $arg_lang $lang_code { default "en"; "zh" "zh-CN"; "ja" "ja-JP"; } location / { rewrite ^/(.*)$ /$1?lang=$lang_code last; }；
- 用 $sent_http_* 获取响应头做判断？不行 —— 这些变量只在日志或 header_filter_by_lua 中可用，rewrite 阶段不可见。
