重写比重定向快，因为重写是服务器内部操作，仅一次请求；重定向需客户端二次发起请求，增加网络往返延迟。重写不改变浏览器地址栏，开销小，适合高频路径转换；重定向返回3xx状态码触发新请求，适用于https跳转、域名归一等必要场景。
重写比重定向快，因为重写是服务器内部操作，只用一次请求；重定向要客户端再发一次请求，多一次网络往返。
重写（rewrite）的性能特点
重写发生在 Nginx 内部，不改变浏览器地址栏，也不触发新请求。它只是把原始 URI 按规则替换后继续走后续处理流程（比如匹配 location、转发给后端或返回静态文件）。
- 开销极小：仅执行正则匹配 + 字符串替换，无网络 I/O
- 适合高频路径转换：如 /user/123 → /api/user?id=123，或 SPA 的 history 路由 fallback
- 推荐用 last 标志终止当前 rewrite 链，避免重复匹配；用 break 可提前结束，但不再进入 location 匹配
- 注意正则效率：避免过度复杂的 regex（如嵌套量词、.* 开头），否则可能拖慢每个请求解析
重定向（return / rewrite ... permanent|redirect）的性能特点
重定向本质是让客户端换一个地址重新发起请求，因此必然引入额外延迟——尤其是跨域或高延迟网络下更明显。
- 必须返回 3xx 状态码和 Location 头，触发浏览器二次请求
- 适合必要场景：HTTPS 强制跳转、域名归一（www → non-www）、废弃路径迁移
- return 301 比 rewrite ... permanent 更轻量：前者直接响应，后者仍需走 rewrite 模块解析
- 大量重定向会增加 CDN 缓存负担（301 可缓存，但 302 不宜长期使用）
真实瓶颈往往不在 rewrite 或 redirect 本身
真正影响性能的，通常是它们之后的操作：
- 重写后若指向一个复杂 PHP 脚本或未缓存接口，慢的是后端，不是 rewrite
- 重定向若指向第三方域名或慢速站点，延迟来自目标服务，不是 Nginx
- 滥用 try_files 配合大量磁盘检查（如 try_files $uri $uri/ /index.html）在高并发下可能成为 I/O 瓶颈
- 开启 access_log 或复杂 log_format 也会带来可观开销，尤其在日志同步写入时
简单压测建议
用 ab 或 wrk 对比两种配置的实际吞吐与延迟：
- 测试纯 rewrite：curl -I http://test.local/product/123 → 应返回 200，URI 已内部映射
- 测试重定向：curl -I http://test.local/old → 应返回 301 + Location，且耗时明显高于前者
- 关注 avg latency 和 req/s，同时观察 Nginx worker 进程 CPU 占用是否异常升高
