404错误主因是请求路径与服务器实际URL不匹配，需检查AJAX URL是否指向真实存在的PHP文件、确认Web服务器正确解析PHP、排除框架路由干扰、验证运行环境支持PHP执行。
PHP AJAX 请求返回 404，绝大多数情况不是 PHP 或 JS 写错了，而是请求路径没对上服务器实际能响应的 URL。
检查 XMLHttpRequest 或 fetch 的 URL 是否指向真实存在的 PHP 文件
浏览器发出的 AJAX 请求，本质是一次 HTTP 请求，和在地址栏输入 URL 效果一致。如果返回 404，说明 Web 服务器（如 Apache/Nginx）根本没找到对应资源。
- 确认你写的 URL 是相对路径还是绝对路径：
./api.php、api.php、/api.php、http://localhost/project/api.php—— 它们解析位置完全不同 - 打开浏览器开发者工具 → Network 标签页，点击触发 AJAX 的操作，查看「Name」列中请求的完整 URL，右键「Open in new tab」—— 如果新标签页也显示 404，就坐实是路径问题
- 常见陷阱：
fetch('api.php')在http://localhost/admin/index.html中执行，实际请求的是http://localhost/admin/api.php，但你的api.php其实放在http://localhost/api.php
验证 PHP 文件是否被 Web 服务器识别为可执行脚本
即使文件物理存在，如果服务器未配置 PHP 解析规则，也会返回 404（而不是 500 或空白），尤其在 Nginx 或某些共享主机上。
- 直接在浏览器访问该 PHP 文件 URL（比如
http://localhost/test.php），看是否输出预期内容，还是下载源码或 404 - Nginx 用户重点检查
location ~ \.php$块是否覆盖了你请求的路径；Apache 用户确认.htaccess没有错误重写或拒绝规则 - 共享主机用户注意：有些环境要求 PHP 文件必须放在特定目录（如
/cgi-bin/）才能执行，普通目录只允许静态文件
排查 Laravel / ThinkPHP / WordPress 等框架的路由干扰
现代 PHP 应用多数不直接暴露 .php 文件，而是通过统一入口（如 index.php）+ 路由分发。此时请求一个不存在的「裸 PHP 文件」必然 404。
立即学习“PHP免费学习笔记（深入）”；
- 如果你用的是 Laravel，别写
fetch('/user.php')，应该走fetch('/api/user')并在routes/api.php中定义对应路由 - WordPress 插件开发时，AJAX 必须通过
admin-ajax.php中转，并正确传入action参数，否则直接请求自定义 PHP 文件会被 WordPress 主题/插件拦截或忽略 - ThinkPHP 注意
url_route_must配置：开启后所有请求必须匹配路由规则，未定义的 URL 一律 404
确认请求方法（GET/POST）与服务端接收逻辑匹配
虽然 404 和请求方法无关，但容易混淆判断。比如你用 fetch 发 POST，但 PHP 文件里只写了 $_GET['id']，结果读不到参数以为“没进到文件”，其实文件已加载成功（状态码是 200），只是逻辑没执行——这种不是 404，别被误导。
- 先确保状态码真是 404（Network 面板看 Status 列），不是 200 + 空响应 / 500 / CORS 错误
- PHP 端加一句
<?php die('reached'); ?>放在文件开头，再发起请求：如果页面显示 'reached'，说明文件已执行，问题出在后续逻辑或输出控制；如果仍是 404，说明根本没走到这一步 - 部分 CDN 或 WAF（如 Cloudflare、安全狗）会把非标准请求（如带特殊 header 的 POST）默认拦截并返回 404，临时关闭它们测试
最常被忽略的一点：本地开发用 VS Code Live Server 或 Python http.server 启的服务，根本不支持 PHP 执行——它只会把 .php 当纯文本返回或直接 404。必须用真正集成了 PHP 的环境，比如 XAMPP、Docker、Laravel Valet 或 Nginx+PHP-FPM 组合。
