推荐用 return 301 替代 rewrite 实现零开销跳转，因其在请求早期直接返回，避免重写引擎开销；应使用内置变量如 $request_uri 确保参数完整、协议安全，并合并多级跳转为单次直达，禁用隐式跳转以防止冲突。
用 return 301 替代 rewrite 实现零开销跳转
rewrite 指令会强制 Nginx 进入重写引擎，触发正则匹配、URI 重解析、location 二次查找，带来明显 CPU 和内存开销。return 301 则在请求处理早期直接返回响应，不走任何后续流程，是唯一推荐的高性能重定向方式。
关键变量组合确保参数完整、协议安全
避免手动拼接 URL 导致编码错误或参数丢失，优先使用内置变量：
- $request_uri：包含原始路径与完整查询字符串（含中文、特殊符号），适用于全量透传
- $scheme://$host$request_uri：自动适配 HTTP/HTTPS，并保持当前域名和路径，适合同站协议升级
- $scheme://new-domain.com$request_uri：跨域迁移时保留全部路径与参数，无需正则捕获
- return 301 https://example.com$new_path?$args;：仅透传参数，路径由变量控制，适合结构化重定向
合并多级跳转为单次直达
历史配置叠加常导致链式跳转（如 /a → /b → /c），每多一次 301，移动端首屏延迟增加近 100ms。应归并规则，删除中间环节：
- 把分散在不同 location 块中的 return 301 或 rewrite redirect 全部梳理出来
- 定位跳转终点，将所有上游路径直接指向最终地址
- 例如：原配置中 /old → /temp → /new，应改为 /old { return 301 /new; }，/temp 规则可移除
- 用 curl -I 或浏览器 Network 面板验证，确保响应头中 Location 直达目标，且只出现一次 301
禁用隐式跳转，防止规则冲突
很多性能损耗来自“看不见”的跳转，比如 CDN 已跳 HTTPS，Nginx 又重复判断；或 try_files fallback 与重定向共存引发 404 后再跳：
- HTTPS server 块内不再写任何 return 301 或 if 跳转逻辑，只专注服务
- HTTP server 块统一收口跳转，做到“入口即终态”
- 检查 access_log 中高频出现的 301 请求来源，确认是否来自冗余规则或上层代理
- 若使用 CDN 或 Ingress，优先在其层完成跳转，Nginx 仅保留兜底逻辑
