方案一 rewrite为GET的参数

这种方法在网上比较常见
以类似/list/1这样的api为例

rewrite ^/list/(.+)/?$ backend.php?target=$1

然后在backend.php中使用$_GET["target"]即可

有一种说法是这种方式无法支持http POST请求，POST请求需要使用307进行重定向，但是我实测并不存在这种情况，POST请求的参数也可以正常拿到（同时被rewrite成GET请求的部分也没有问题，POST和GET是可以同时发送的）
（也许是因为nginx更新了？）

方案二 request uri

这种方法其实更简单

if (!-e $request_filename) {
    rewrite ^(.*)$ /backend.php last;
}

这段代码把所有原来应该404的请求rewrite到了backend.php，没有使用GET参数的形式

在php中可以使用$_SERVER["REQUEST_URI"]来获得请求的路径
比如localhost/a/b/c/的request uri就是/a/b/c/，然后可以使用explode()函数来将其拆解为数组进行解析
至于为什么rewrite之后request uri不会丢，因为rewrite并不会产生地址重写，浏览器看到的还是原来的访问地址，而这正是request uri的来历

方案三 path info

这种方式我并没有实践过，因为nginx默认并没有支持path info
首先了解一下什么是path info

是类似localhost/a.php/b/c的访问形式，此处a.php是一个php脚本文件，但是却在网址中被作为了类似“文件夹”的形式
要实现这种方式，首先要对nginx默认对php文件的判断进行更改
将原来的location ~ \.php$ {改为location ~ \.php(\/.*)*$ {
原来的形式只会将.php文件交给php处理，但是现在则是路径中包含.php的都交给php处理
如果没有这个修改，在path info模式下会直接404
之后，就可以进行类似localhost/a.php/b/c的访问了

但是，现在你依然只能使用方法二中的$_SERVER["REQUEST_URI"]来获得访问路径，而此时的访问路径会变成恼人的/a.php/b/c的形式，原因是nginx + php的组合默认并不支持能够直接返回/b/c的$_SERVER["PATH_INFO"]，需要对nginx.conf中的php解析部分进行一些修改
增加

fastcgi_split_path_info       ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO       $fastcgi_path_info;

但是我实测依然并不能正常使用PATH INFO（逃

方案二三是可以混合使用的