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() 或未捕获的异常输出。

绕过输出限制的三种实操方式

不是所有场景都能“删空格”，得按需选：

• 强制开启输出缓冲：在脚本最顶部（第一行，无空格、无注释、无 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() 调用本身。