PHP API 返回404的最常见原因是URL未匹配路由规则,需依次检查服务器重写配置、框架路由定义、入口文件加载、.htaccess生效性、框架内部404逻辑及预检OPTIONS请求。

确认请求 URL 是否匹配路由规则
PHP API 返回 404,最常见原因是请求的 URL 根本没被后端框架或服务器识别为有效路由。比如你用 curl http://api.example.com/v1/users,但实际路由只定义了 /api/v1/users 或 /index.php/v1/users。
- 检查 Web 服务器配置:Apache 需启用
mod_rewrite,Nginx 要确保try_files $uri $uri/ /index.php?$query_string;正确转发 - 查看框架路由表:Laravel 运行
php artisan route:list,ThinkPHP 查route/route.php,确认路径、HTTP 方法(GET/POST)、中间件都匹配 - 注意尾部斜杠:/
v1/users和/v1/users/在部分配置下不等价,统一约定并测试
排查 PHP 入口文件是否被正确加载
很多 404 实际是 Web 服务器根本没把请求交给 PHP 处理,而是直接返回静态 404 —— 这时 error_log 里甚至看不到任何 PHP 执行痕迹。
- 临时在
index.php开头加file_put_contents('/tmp/hit.log', "hit\n", FILE_APPEND);,再发请求,看日志有没有写入 - 如果没写入,说明请求没进 PHP:检查 Nginx 的
root是否指向项目根目录(不是 public 子目录),或 Apache 的DocumentRoot配置 - 使用 CLI 模拟:运行
php index.php看是否报错(如找不到 autoload),排除 PHP 自身启动失败
检查 .htaccess 或重写规则是否生效
在 Apache + 无显式 index.php 的场景下,.htaccess 是路由命脉;一旦语法错误或被禁用,所有「干净 URL」都会 404。
- 确认
AllowOverride All已在虚拟主机配置中启用,否则.htaccess被完全忽略 - 简化测试:把
.htaccess临时重命名为.htaccess.bak,改用完整 URL(如/index.php/v1/users)—— 如果这时能通,问题就锁定在重写规则 - 常见陷阱:
RewriteBase写错(如多了一层/api),或RewriteCond %{REQUEST_FILENAME} -f没排除真实存在的静态文件干扰
验证框架或路由器是否捕获到请求但主动返回 404
有些情况请求确实进了 PHP,但框架内部没匹配到路由,于是调用 abort(404) 或抛出 NotFoundHttpException —— 这类 404 会记录在 PHP 错误日志,且可能带堆栈。
立即学习“PHP免费学习笔记(深入)”;
- Laravel 中,在
app/Exceptions/Handler.php的render()方法开头加Log::info('404 requested: ' . request()->fullUrl()); - ThinkPHP 可在
app/common.php中注册全局异常处理,打印$e->getMessage()和$e->getTraceAsString() - 原生 PHP Router(如 FastRoute)需确认
$dispatcher->dispatch()返回值是Dispatcher::NOT_FOUND,而非代码逻辑误判
if ($routeInfo[0] === FastRoute\Dispatcher::NOT_FOUND) {
http_response_code(404);
echo json_encode(['error' => 'API not found']);
exit;
}
调试时最容易忽略的是:你以为在调接口,其实浏览器或 curl 正在发预检 OPTIONS 请求,而你的路由没配它,或者 CORS 中间件提前拦截并静默返回 404。抓包看实际发出的 Method,比只盯文档里的 GET 更可靠。











