TP6接口404绝大多数因请求未进入框架，需先验证public/index.php是否执行（如加日志），再检查Nginx的/api/专用location、PATH_INFO传递、路由文件位置、APP_DEBUG缓存及HTTP方法匹配。
TP6 开发 APP 接口报 404，绝大多数情况不是接口写错了，而是请求根本没进到框架里——public/index.php 甚至都没执行。APP 接口调用（如 /api/v1/login）和浏览器访问不同，不走前端路由，对服务器配置更敏感。排查要分两层：先确认是否进框架，再查路由是否匹配。
第一步：验证请求是否真正进入 ThinkPHP
这是最关键的前置判断。如果连框架都没进去，改路由、加控制器全是白忙。
- 在
public/index.php最开头插入一行日志：file_put_contents('/tmp/tp-api-hit.log', date('Y-m-d H:i:s') . " - " . $_SERVER['REQUEST_URI'] . " ", FILE_APPEND); - 用
curl直接测试接口，例如：curl -v http://yourdomain.com/api/v1/login - 查看日志：
tail -f /tmp/tp-api-hit.log。有记录说明进框架了；没记录，说明 Nginx/Apache 拦截了，跳转到原生 404 页面。
第二步：检查 Web 服务器配置（Nginx 为例）
APP 接口通常以 /api/ 为前缀，必须确保该路径被正确转发到 index.php，且携带完整路径信息。
-
location 配置要精准：使用
^~ /api/而非~ .php$，避免被其他规则覆盖location ^~ /api/ { try_files $uri $uri/ /index.php?$query_string; } -
PATH_INFO 必须传递：缺这行，TP6 解析不出
/v1/login这段fastcgi_param PATH_INFO $fastcgi_path_info;
同时确保上面有配套的fastcgi_split_path_info ^(.+.php)(/.+)$; -
root 必须指向 public 目录，例如：
root /var/www/your-app/public;，否则/index.php路径会错位
第三步：确认路由注册与加载是否生效
如果日志有记录，说明已进框架，问题出在路由层。此时需检查：
- 路由文件是否在正确位置：
单应用模式 →app/route/app.php
多应用模式（如 api 应用）→app/api/route/app.php，且config/app.php中已声明'api' => 'app\api\' - 是否漏掉命名空间引用：
use think acadeRoute;必须存在，否则Route::post()报类未找到 - APP_DEBUG = false 时，路由会被缓存。改完路由后，删掉
runtime/route/整个目录 - 检查是否启用了
url_route_must => true（默认开启），意味着所有请求都必须命中注册的路由，否则直接 404
第四步：排除常见干扰项
这些细节容易忽略，但常导致“明明配了却 404”：
- Nginx 配置中是否有
error_page 404 /404.html;？有就注释掉，否则 TP6 的Route::miss()根本没机会执行 - APP 接口请求是 POST，但你只写了
Route::get('/login', ...)—— 要对应方法：Route::post('/login', ...) - TP6.0.0–6.0.7 存在路由解析 Bug，升级到 6.0.12 或更高版本可解决一批诡异 404
- 别在
Route::miss()回调里调用url()辅助函数，它依赖路由匹配结果，此时会出错
