触发404的是跳转链条的终点资源（如目标php文件）不可访问或不可执行，而非跳转次数多；需在header()前用file_exists()验证路径，并确保web服务器正确解析php。
header() 跳转链中哪一环触发了 404？
PHP 中“多次跳转致 404”，本质不是跳转次数多，而是某次 header() 执行后，目标 URL 实际返回了 404 状态（比如文件不存在、路径错、权限拒、PHP 未解析），而浏览器或爬虫只看到最终响应——于是误以为“跳转导致 404”。真正的断点不在 PHP 脚本里，而在跳转链条的**终点资源是否真实可访问且可执行**。
常见错误现象：
- 页面 A →
header("Location: /api/v1/data.php")→ 浏览器地址栏变 /api/v1/data.php，但显示 404 -
前端表单提交到
submit.php，该文件内又header("Location: success.php")，结果 success.php 报 404 - SPA 后端路由中，
index.php根据$_GET['p']跳转，但$_GET['p'] = "user/profile"对应的user/profile.php并不存在
用 file_exists() + http_response_code() 主动截断无效跳转
与其让跳转走到死胡同再报 404，不如在发起跳转前就验证目标是否存在。这是最可控、最易调试的切断方式。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有动态生成的跳转目标（如
$target = $_GET['next'] ?? 'home.php'）必须先过file_exists()检查 - 若目标不存在，不要跳转，直接设状态码并输出提示，避免二次请求
- 路径需用服务器绝对路径（
__DIR__ . '/' . $target），而非 URL 路径，防止相对路径错位
php
$target = $_GET['next'] ?? 'home.php';
// 注意：这里要补全扩展名，且过滤掉 ../ 等路径穿越
$target = basename($target);
$full_path = __DIR__ . '/' . $target;
if (file_exists($full_path) && is_readable($full_path)) {
header("Location: /{$target}");
exit;
} else {
http_response_code(404);
echo "Requested page not found: {$target}";
exit;
}
Apache/Nginx 配置劫持导致“假跳转真 404”
你以为 PHP 在跳转，其实 Web 服务器早把请求拦下了——特别是当跳转目标是 .php 文件，但服务器没配置 PHP 解析时，Nginx/Apache 会直接返回 404（不执行任何 PHP 代码），根本不会走到你的 header() 逻辑里。
排查重点：
- 直接在浏览器访问跳转终点 URL（如
/api/submit.php），看是否返回源码、空白页或 404 —— 若是，说明 PHP 解析失败，不是跳转问题 - Apache 查
.htaccess是否有兜底规则（如RewriteRule ^(.*)$ index.html [L]）误吞了 PHP 请求 - Nginx 查
location ~ \.php$块是否被try_files $uri $uri/ /index.html;覆盖，导致 PHP 文件被当成静态资源找不着
别用 Location 跳转去“显示”404 页面
这是最典型的认知偏差：以为 header("Location: 404.php") 就是在“显示 404”，其实它只是重定向到另一个 URL，状态码仍是 302（或 301），**不是 404**。搜索引擎和浏览器都把它当正常跳转，完全达不到语义化错误提示效果。
正确做法是：
- 想让用户看到 404 页面内容 → 用
include '404.php'或readfile('404.php')，并在开头加http_response_code(404) - 想让服务器全局接管 404 → Apache 用
ErrorDocument 404 /404.php，Nginx 用error_page 404 /404.php - 若必须跳转（如旧链接迁移），则跳转目标本身也要返回 404 状态码，否则链路断裂
真正难缠的不是跳转语法，而是你永远不知道下一级 URL 是由 PHP 处理、被服务器拦截、还是被 CDN 缓存成静态 404——所以每次跳转前，先确认终点是否“活”着，比优化跳转逻辑重要十倍。
