try_files性能好，因其仅做路径拼接与stat()调用，无正则解析、URI重写或location重匹配；配合open_file_cache可进一步降低I/O，实测比rewrite延迟低10%–25%，CPU更平稳。
不大，try_files 是 Nginx 中性能损耗极低的指令之一，远低于 rewrite、if 或正则匹配类操作。它不涉及正则解析、URI 重写或 location 重匹配，只做路径拼接和文件存在性检查（stat() 系统调用），在合理配置下几乎无感知开销。
为什么 try_files 性能好
它的执行机制决定了轻量高效：
- 按顺序拼接路径（如
$uri→$uri/→/index.php?$args），不修改原始 URI - 每个路径只调用一次
stat()判断文件/目录是否存在 - 命中即返回或内部跳转，不进入 rewrite 流程，也不触发 location 重匹配（除非 fallback 是 URI）
- 配合
open_file_cache后，文件存在性检查可被缓存，大幅减少磁盘 I/O
关键调优点
真正影响性能的不是 try_files 本身，而是它所依赖的上下文和配套配置：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
启用 open_file_cache：避免每次请求都做 stat()。推荐配置：
open_file_cache max=10000 inactive=60s;<br> open_file_cache_valid 60s;<br> open_file_cache_min_uses 2;<br> open_file_cache_errors on;
-
避免 fallback 指向高开销后端：比如
try_files $uri @php中的@php是 proxy_pass 或 fastcgi_pass，瓶颈实际在后端，不是 try_files -
精简 fallback 链路：不要写成
try_files $uri $uri/ /index.html /fallback.php这种多级兜底，若前两级已覆盖绝大多数请求，第三级就纯属冗余检查 -
慎用 $uri 变量嵌套复杂逻辑：例如
try_files $uri $uri/index.html /index.php?path=$uri中的$uri若含特殊字符或过长路径，虽不影响 try_files 本身，但可能拖慢后续 PHP 处理
对比 rewrite 的真实开销
如果你原本用 rewrite 实现类似功能（比如重写 SPA 路由），换成 try_files 通常能带来明显收益：
- rewrite 每次都要走 PCRE 正则引擎，匹配、捕获、变量替换、可能触发 location 重匹配
- 实测同场景下，try_files 平均响应延迟比等效 rewrite 低 10%–25%，CPU 波动更平缓
- 尤其在高并发静态资源请求中，差异更显著——rewrite 容易成为 CPU 热点，try_files 几乎不抬升负载
典型高效写法示例
SPA 应用（如 Vue/React）常用配置，兼顾语义清晰与性能：
location / {<br>
root /var/www/app;<br>
try_files $uri $uri/ /index.html;<br>
}注意：
- 不要写成 try_files $uri $uri/ /index.html?$args（加 $args 会强制触发 query string 传递，对 index.html 无意义，还可能干扰缓存）
- root 路径必须准确，避免因路径错误导致反复检查失败
