Nginx的location匹配不依赖配置顺序，而是按精确匹配（=）、前缀匹配（^~）、最长前缀、正则匹配（~、~*）的严格优先级执行，查询参数全程忽略。
location 匹配不按配置顺序执行，这是正常现象
Nginx 的 location 匹配**完全不依赖配置文件中的书写顺序**。很多人把 location /api 放在 location / 前面，以为就能优先匹配，结果请求 /api/v1 还是进了 / —— 因为 Nginx 有自己严格的优先级算法，顺序只影响「同级匹配」时的 fallback 行为，不是决定性因素。
- 精确匹配
= /path永远最高优先级，命中即终止 -
^~ /static/是前缀匹配里的“硬中断”：一旦匹配成功，连正则都不看了 -
~ /api/.*和~* \.php$属于正则匹配，统一在前缀匹配（不含^~）之后评估，且只取**第一个成功匹配的正则**（按配置顺序） -
/api（无修饰符）和/都是普通前缀匹配，Nginx 会选「最长的前缀字符串」，所以/api/v1必然比/优先，哪怕它写在后面
phpEnv 下常见冲突：/api 和 /index.php 同时存在时怎么防误匹配
phpEnv 默认带 location ~ \.php$，但如果你又加了 location /api，而 API 请求是 /api/v1/user，它不会进 PHP 处理；可一旦你写成 location /api/，再发 /api/index.php，就可能被 /api/ 先截住，导致 PHP 不执行 —— 这是典型路径重叠陷阱。
- 避免用
location /api去代理后端服务，改用location ^~ /api/：确保所有以/api/开头的请求都走代理，不进 PHP 正则分支 - 如果必须让
/api/index.php执行 PHP，就把location ~ \.php$放在location /api/之后，并确认它没被^~或=阻断 - 测试时用
curl -I http://localhost/api/v1/test看响应头的X-Powered-By或Content-Type，比看页面更准
为什么 /admin 和 /admin/ 匹配结果不同
这是新手最容易栽跟头的地方：location /admin 实际匹配的是「以 /admin 开头的所有路径」，包括 /admin/foo、/admin.php，甚至 /administrators —— 只要前缀对就得算。
-
location = /admin：只认字面量/admin，不带查询参数也行，多一个/或少一个字母都不行 -
location /admin/：匹配/admin/xxx，但不匹配/admin（结尾无斜杠） -
location ^~ /admin/：既限定前缀，又阻止后续正则检查，适合静态管理后台目录 - phpEnv 中若启用了
try_files $uri $uri/ /index.php?$query_string，注意/admin请求会被重写成/admin/再试一次，可能触发 301 跳转
调试 location 匹配最有效的办法：看 error_log + rewrite_log
光靠猜或 reload 后测页面，效率极低。Nginx 真实匹配路径的过程，只有打开日志才能看清。
立即学习“PHP免费学习笔记（深入）”；
- 在
http或server块里加：error_log /path/to/nginx-error.log notice;（notice 级别才输出 location 匹配信息） - 临时开启重写日志：
rewrite_log on;，配合error_log ... debug;（注意 debug 日志量极大，仅调试时开） - 发一次请求后，立刻查日志里类似这样的行：
"location: /api/"或"using configuration \"= /health\"" - phpEnv 的 nginx.conf 通常在
C:\phpEnv\nginx\conf\nginx.conf（Windows）或/opt/phpenv/nginx/conf/nginx.conf（Linux），改完记得nginx -t && nginx -s reload
真正容易被忽略的点是：查询参数（?a=1&b=2）在所有匹配阶段都被直接忽略，它不参与任何 location 判定 —— 所以 /login?next=/admin 和 /login 走的是同一个 location，逻辑分流得靠后端或 if ($args ~ next=) 这类额外判断，不能指望 location 分开。
