$request_uri 是最直接可靠的变量，天然携带完整路径和原始参数，用于 return 或 rewrite 可实现零丢失跳转；强制 HTTPS、域名重定向优先用它；rewrite 中需显式加 ? 保留参数；复杂逻辑推荐 map 替代 if；上线前须实测 Location 头与编码完整性。
关键在于用对变量——$request_uri 是最直接、最可靠的选择，它天然携带路径和全部原始参数，无需拼接、不会漏掉问号或值。
优先使用 $request_uri 实现零丢失跳转
这个变量是 Nginx 内置的完整请求 URI，比如用户访问 /search?q=test&sort=asc，$request_uri 就是完整的 /search?q=test&sort=asc。在 return 或 rewrite 中直接引用它，参数自动保留。
- 适合 HTTP → HTTPS 强制跳转：
return 301 https://$host$request_uri; - 适合域名或路径重定向：
return 301 https://new.example.com$request_uri; - 避免用
$uri?$args拼接，容易因 $args 为空导致末尾多出 ?，或在某些上下文中被覆盖
rewrite 中保留参数要显式加问号
如果必须用 rewrite（比如要做路径变更），且目标地址不含协议，则需手动确保参数附带过去。Nginx 不会自动补全 query string，必须显式写出 ?。
- 正确写法（参数原样传递）：
rewrite ^/old/(.*)$ /new/$1? permanent;注意结尾的 ?，它告诉 Nginx 把原始 $args 追加到新路径后 - 错误写法（会丢参）：
rewrite ^/old/(.*)$ /new/$1 permanent;—— 缺少 ?，参数被清空 - 若需改写部分参数，可结合 $arg_XXX 变量，例如：
if ($arg_q) { rewrite ^/cn/show/$ /cn/getinfo/?kw=$arg_q? permanent; }
注意 if 块中的限制与替代方案
虽然 if 在简单判断时可用，但它在 location 中有执行顺序风险，且不能嵌套。涉及参数判断时更推荐用 map 指令预处理，或直接用 $request_uri 匹配。
- 安全判断完整带参 URI：
if ($request_uri ~ "^/cn/show/\?q=[^&]+") { ... } - 避免只依赖 $uri（它不带参数），否则判断会失效
- 复杂逻辑建议移至 map 块，例如统一提取、重命名或过滤特定参数
验证是否真的保留了参数
上线前务必实测，不能只看配置语法正确。重点检查三点：
- 用 curl -I 检查跳转状态码是否为 301 或 302
- 观察 Location 响应头里的 URL 是否包含原始 ? 后全部内容
- 在浏览器开发者工具 Network 标签中查看重定向后的最终请求地址
- 特别留意中文、特殊符号、空格等编码是否完好（$request_uri 已做 URL 编码，无需额外 encode）
