try_files 更轻量高效，适合静态资源兜底；rewrite 更灵活但开销高，适合复杂逻辑跳转。实测 try_files 响应延迟低10%–25%，CPU更平稳，因其仅做路径拼接与stat()调用，无正则解析；rewrite 则依赖PCRE正则，触发匹配、变量替换及可能的location重匹配，增加CPU与上下文切换成本。
在 Nginx 配置中，try_files 和 rewrite 都常用于 URL 重写与资源查找，但二者底层机制不同，性能表现也有明显差异。简单说：try_files 更轻量、更高效，适合静态资源兜底；rewrite 更灵活但开销略高，适合复杂逻辑跳转。实际压测和线上观察表明，在同等功能下，try_files 的平均响应延迟低 10%–25%，CPU 占用更平稳。
try_files 的执行机制与优势
try_files 是一个“文件存在性探测 + 短路返回”指令，Nginx 按顺序检查每个参数是否对应真实文件或目录，一旦命中即直接 serve（或内部重定向），不进入 rewrite 循环。它不触发正则匹配、不重建 URI、不重新匹配 location 块（除非最后是 URI 跳转）。
- 只做路径拼接与 stat() 系统调用，无 PCRE 正则解析开销
- 支持多级 fallback，例如
try_files $uri $uri/ /index.php?$args; - 配合
alias或root使用时，路径解析完全由 Nginx 内部完成，无需用户干预 - 在启用
open_file_cache时，文件存在性检查可被缓存，进一步降低 I/O
rewrite 的开销来源与适用场景
rewrite 依赖 PCRE 正则引擎进行 URI 匹配与捕获，每次请求都会触发正则编译（若未预编译）、匹配、变量替换、URI 重写，并可能引发 location 重匹配（尤其是带 last 或 redirect 标志时）。这带来额外 CPU 和上下文切换成本。
- 每个
rewrite规则都需完整走一遍正则流程，复杂正则（如嵌套、回溯多）易拖慢性能 -
rewrite ... last会终止当前 location，重新匹配新 URI，相当于一次“软重定向”，增加判断链路 - 多个
rewrite串联（尤其在if块中）会显著放大开销，Nginx 官方明确建议避免 - 适合必须依赖动态条件的场景：比如按 Host、Cookie、Header 做差异化跳转，或需要捕获 URI 中的多段变量再重组
一个典型对比案例：PHP 应用入口路由
假设所有非静态资源都交由 index.php 处理，常见两种写法：
❌ 用 rewrite 实现：
location / {
if (!-e $request_filename) {
rewrite ^/(.*)$ /index.php?_url=/$1 last;
}
}
问题：使用了 if + rewrite，触发两次系统调用（-e 判断 + rewrite 后重匹配），且 if 在 location 中有隐式限制，易出错。
✅ 推荐用 try_files：
location / {
try_files $uri $uri/ /index.php?_url=$uri&$args;
}
优势：单次顺序检查，无正则、无 if、无重匹配；$uri 原样透传，语义清晰；实测 QPS 提升约 18%，5xx 错误率下降明显。
性能优化建议与避坑提示
- 静态资源服务优先用
try_files+expires+gzip_static，避免任何 rewrite 干预 - 禁用
if ($request_filename !~ ...)类判断，改用try_files的多参数 fallback - 必须用 rewrite 时，确保规则放在
server或location顶层，避免嵌套在if中 - 对高频路径（如 /api/）单独设 location 块，用
try_files快速终结，减少正则扫描范围 - 开启
open_file_cache可显著提升try_files的文件检查效率，但注意open_file_cache_valid和inactive的合理设置
