PHP 8.4 中 header() 发送失败主因是输出已提前触发，如BOM、空白符、echo或错误报告输出；可用 headers_sent() 定位位置，推荐首行加 ob_start() 并封装 safe_header() 处理。
PHP 8.4 中 header() 发送失败，大概率是因为输出已提前触发 —— 不是函数坏了，而是你没拦住那“看不见的空格”或“意外 echo”。
为什么 PHP 8.4 的 header() 突然不工作了？
PHP 8.4 并未修改 header() 的核心逻辑，但它对输出缓冲（output buffering）更敏感，且默认禁用了部分旧版兼容行为。常见诱因包括：
- 文件开头或结尾存在 BOM 字节（尤其 UTF-8 with BOM 编码的 .php 文件）
-
echo、print、HTML 内容、甚至换行符在header()前执行 - 启用了
output_buffering = Off且未手动开启缓冲 - 错误报告开启（
error_reporting或display_errors = On）导致警告/notice 直接输出
怎么确认是不是输出已发送？
用 headers_sent() 快速验证，它返回布尔值并可选输出位置信息：
if (headers_sent($file, $line)) {
trigger_error("Headers already sent in {$file} on line {$line}", E_USER_WARNING);
}
如果报错指向某个 .php 文件末尾或配置文件，极可能是 BOM 或多余空白；若指向框架入口或路由层，检查是否有日志写入、调试 var_dump() 或未捕获的异常输出。
立即学习“PHP免费学习笔记（深入）”；
绕过输出限制的三种实操方式
不是所有场景都能“删空格”，得按需选：
-
强制开启输出缓冲：在脚本最顶部（第一行，无空格、无注释、无 BOM）加
ob_start();，后续所有header()都能生效，但注意缓冲内容最终仍要ob_end_flush()或ob_end_clean() -
用
http_response_code()替代状态码头：比如http_response_code(302);不依赖输出时机，但不能设自定义头如Location -
改用现代响应方式（推荐）：在框架中（如 Laravel、Symfony）应使用
Response对象；纯脚本可封装：function safe_header(string $header, bool $replace = true, int $http_response_code = 0): void { if (!headers_sent()) { header($header, $replace, $http_response_code); } }再配合ob_start()开头，双重保险
PHP 8.4 特别要注意的坑
PHP 8.4 默认启用 zend.assertions = -1（生产禁用断言），但如果开发时开过 assert() 且未清理，断言失败会直接输出；另外，ini_set('display_errors', '1') 在 CLI SAPI 下虽不显示，但在 Web SAPI 下仍可能触发输出 —— 这类细节在 8.4 中更容易暴露为 header() 失败。
真正难调试的，往往是那个被 IDE 自动插入的 UTF-8 BOM，或者 Composer 自动加载器里某行末尾的空格。别只盯着 header() 调用本身。
