Nginx的location和rewrite只匹配URI的path部分（?之前），不处理query string；问号是参数分隔符，非路径字符，不能在正则中直接写?匹配；需用$args、map或if判断参数，%3F可直接在正则中使用。
在 Nginx 中，Rewrite 规则默认使用 PCRE 正则表达式引擎，而问号 ? 是正则中的特殊元字符（表示前一个字符可选），**不能直接写在 location 或 rewrite 的匹配模式中来匹配 URL 中真实的 ?**。URL 中的问号实际是请求参数分隔符，它及其后的内容（query string）**默认不会参与 location 和 rewrite 的路径匹配**。
理解 Nginx 匹配范围：问号不在 path 中
Nginx 的 location 和 rewrite 指令只处理 URI 的 path 部分（即 ? 之前的部分）。例如请求：GET /api/v1/users?id=123&name=test
Nginx 实际用于匹配的只有 /api/v1/users，?id=123&name=test 属于 query string，存放在 $args 或 $query_string 变量中，不会被正则 pattern 扫描到。
因此——
✅ 如果你想匹配带特定参数的请求，应结合 if 判断 $args 或使用 map；
❌ 不要试图在 rewrite 正则里写 \/users\?id= —— 这既不生效，还会因未转义 ? 导致编译报错。
需要匹配“字面问号”？通常出现在非标准场景
极少数情况，你确实需要匹配 path 中含字面 ? 的 URI（例如某些老旧 API 把 ? 当作路径分隔符，或前端路由误用了未编码的 ?）。这时需注意：
- 浏览器会自动对 URL 中 path 里的
?进行编码为%3F，所以真实到达 Nginx 的 path 是/path%3Fparam，而非/path?param - 若客户端未编码且服务端仍收到 raw
?（非常规，依赖底层 HTTP 解析行为），Nginx 通常已将其截断，无法可靠捕获 - 如确需匹配编码后的
%3F，可在正则中直接写%3F（无需额外转义），例如：rewrite ^/old/path%3F(.*)$ /new/path/$1? last;
正确处理带参跳转：用 $args + break/redirect
常见需求是“把带特定参数的请求重写到新路径”，例如将 /old?id=123 → /new/123：
- 先用 location 匹配 path：
location = /old { ... } - 再用 if 判断参数（注意：
if在 location 中可用，但避免嵌套复杂逻辑）：
if ($args ~ "^id=(\d+)$") {<br> rewrite ^/old$ /new/$1? last;<br>}
（末尾?表示丢弃原始参数） - 更健壮的做法是用
map提前提取参数值，避免 if 性能隐患：
map $args $new_id {<br> ~^id=(\d+)$ $1;<br> default "";<br>}
然后在 location 中：
if ($new_id) {<br> rewrite ^/old$ /new/$new_id? last;<br>}
总结关键点
问号不是路径一部分：别在 rewrite 正则里写 \? 去匹配 URL 中的 ?，它根本进不了匹配流程。
参数走变量：用 $args、$query_string 或 map 处理查询参数。
编码字符可直写：若需匹配 URL 编码后的 %3F，正则中写 %3F 即可，不用 \% 或 \3F。
避免 if 嵌套：复杂参数逻辑优先用 map + 简单 if，提升可读与性能。
