ThinkPHP伪静态规则兼容旧版PATHINFO模式的技巧【技巧】

在实际项目中，尤其是接手一些历史遗留系统时，经常会遇到TP6对旧版PATHINFO格式的URL直接返回404的情况。根本原因其实不复杂：旧版URL（比如 /index.php/user/profile/123）被整体当作路径信息传入了，而TP6在入口处会默认剥离 index.php，导致剩下的路径解析出来是空的或者完全错乱。要修复它，核心就是两件事：开启一个配置参数，再手动补上一个全局变量。

旧版 PATHINFO 路径（如 /index.php/user/profile/123）为什么在 TP6 直接 404

问题的症结在于TP6默认把 index.php 当作入口文件剥离，之后才开始解析剩余路径。而旧的伪静态规则是把 /index.php/user/profile/123 这个完整的字符串作为 PATH_INFO 传进去的。结果就是，框架的 Request 对象拿到的 pathinfo 要么是空的，要么就是一串乱码。这根本不是路由规则没写对，而是最前面的入口层就没拿到有效的路径段。

解决起来也不复杂，需要做两步操作：
• 在 config/app.php 里把 'url_common_param' 设置为 true
• 在 public/index.php 文件的顶部，手动修正一下 $_SERVER['PATH_INFO']：

if (!empty($_SERVER['PATH_INFO']) && strpos($_SERVER['PATH_INFO'], '/index.php/') === 0) {    $_SERVER['PATH_INFO'] = substr($_SERVER['PATH_INFO'], 10);}

至于Apache的 .htaccess，保持原样不动就行。但得确认服务器已经开启了 mod_rewrite，并且虚拟主机的配置里 AllowOverride All 是生效的。

如何让 Route::rule() 匹配 /user/profile/id/123 这类旧 URL 格式

很多人会尝试用 [:module]/[:controller]/[:action]/[:id] 这种可选参数语法来匹配旧URL，但这里有个关键点：它本质上不是正则捕获，而是依赖于前面的 PATH_INFO 已经被正确提取了。如果入口那一步没修好，这条路由根本就不会被触发。

一个比较靠谱的做法，是直接用闭包来兜底，别依赖框架的自动解析：

Route::any('[:module]/[:controller]/[:action]/[:id]', function () {    $module = request()->param('module', 'index');    $controller = request()->param('controller', 'index');    $action = request()->param('action', 'index');    return redirect("/{$module}/{$controller}/{$action}")->code(301);});

这里有几个地方需要留心：
• 必须把 'url_route_must' 设为 false，否则没匹配到路由会直接报错
• [:xxx] 这种写法只表示“这一段如果存在就取值”，它不保证顺序，也不要求必填
• 如果真要做正则匹配，得用 Route::pattern() 配合 Route::rule() 的第三个参数（正则表达式字符串）来实现

PATHINFO 模式下参数顺序错乱或收不到怎么办

PATHINFO模式默认是按位置来绑定参数的：比如 /user/profile/123，那 $id = 123；如果是 /user/profile/123/news，那就是 $id = 123, $type = 'news'。这里没有命名参数的概念，一旦参数顺序乱了，或者某个值缺失了，就会出错。

解决方案通常有两条路：
• 在方法签名里给参数设默认值：public function read($id = 0, $type = 'article')
• 改用显式的命名路由：Route::get('read/:id/:type', 'Index/read')->pattern(['id' => 'd+', 'type' => 'w+'])
• 绝对不要想着靠 input('id') 去“碰运气”取参数——那是PATHINFO位置推导的副作用，非常不可靠

另外，生成URL的时候也必须用数组形式：url('Index/read', ['id' => 123, 'type' => 'news'])，别直接拼接字符串路径。

Nginx 下 PATHINFO 模式失效的典型表现和修复点

在Nginx环境下的典型表现是：/index.php/user/profile 能正常访问，但换成 /user/profile 就返回404。这说明Nginx没有把原始的路径完整地透传给PHP-FPM。

关键的配置就两行，缺一不可：

fastcgi_split_path_info ^(.+.php)(/.+)$;fastcgi_param PATH_INFO $fastcgi_path_info;

实际配置中经常踩的坑：
• 把这两行写在了 location ~ .php$ 块的外面，或者漏掉了 fastcgi_param
• 宝塔面板自带的「ThinkPHP」伪静态模板是为TP5设计的（走 s= 参数），TP6开启路由后默认不带 s=，必须手动替换掉或者关掉预设规则
• 如果应用部署在二级目录下（比如 /myapp/），那 rewrite 规则的目标地址必须带上目录前缀，例如 rewrite ^/myapp/(.*)$ /myapp/index.php?s=$1 last;

最稳妥的写法是用 try_files：try_files $uri $uri/ /index.php?$query_string;，它能保留完整的 REQUEST_URI，避免 rewrite 破坏原始的结构。