方案一 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(逃

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