ThinkPHP框架报Header already sent的输出缓冲区处理技巧-ThinkPHP-PHP中文网

根本原因是php输出缓冲区被提前触发，如bom、空格、echo或未捕获的notice等导致header()调用前已有输出；thinkphp的response类在发送响应前调用header()，一旦输出已发生即报错。

thinkphp框架报header already sent的输出缓冲区处理技巧

为什么 `header()` 会报 “Header already sent” 错误

ThinkPHP 运行中突然抛出 Warning: Cannot modify header information - headers already sent，根本原因不是框架本身，而是 PHP 输出缓冲区（output buffer）被提前触发了——哪怕只多了一个空格、BOM 字符、echo 或未捕获的 Notice 都会冲掉 header 发送机会。

ThinkPHP 的 Response 类在发送重定向或 JSON 响应前会调用 header()，一旦 PHP 已经向浏览器输出了任何内容（哪怕只是换行），就再也无法修改 header。

常见诱因：UTF-8 BOM 头（尤其 Windows 编辑器保存时默认加）、控制器/模型里写了 var_dump() 或 print_r()、配置文件末尾有多余空行、扩展日志写入时触发了 warning 并直接输出
ThinkPHP 6+ 默认开启 ob_start()，但仅对 echo/print 等显式输出有效；错误、notice、warning 默认直出，不进缓冲区
别指望 ob_get_level() 返回非零就万事大吉——它只反映当前缓冲层数，不保证没被意外 flush 过

如何快速定位“谁先输出”的源头

靠肉眼排查几十个文件几乎不可能。直接启用 PHP 内置追踪机制，比翻日志高效得多。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

在入口文件 public/index.php 最开头加：

if (headers_sent($file, $line)) { die("Headers already sent in $file on line $line"); }

更彻底：临时在 thinkphp/library/think/Response.php 的 send() 方法第一行插入 error_log("send() called at " . debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 1)[0]['file'] . ':' . debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 1)[0]['line']);，配合 tail -f /var/log/php_errors.log 查输出链路
注意：Xdebug 的 xdebug.output_trace 开启后也会干扰缓冲行为，调试阶段建议关闭

ThinkPHP 下安全控制输出缓冲的实操方式

不要依赖框架自动处理，主动接管缓冲生命周期才是稳定解法。

在 public/index.php 最顶部（<?php 后立刻）加：
```
if (!headers_sent()) { ob_start('ob_gzhandler'); }
```
—— 注意必须在任何输出、include、require 之前
禁用所有非必要调试输出：把 app_debug 设为 false，关掉 log.record，避免 Log::write() 触发 warning 直出
若需调试，改用 think\facade\Log::debug() 记日志，而非 dump() 或 echo；dump() 在生产环境必须删掉
检查所有配置文件（config/ 下）是否以 UTF-8 无 BOM 格式保存；用 file -i config/app.php 验证编码，BOM 会显示为 charset=utf-8; with BOM

JSON/下载响应时仍报错？重点查 MIME 和 Content-Length

即使缓冲区正常，Response::json() 或文件下载仍可能失败，问题常出在 header 冲突或长度计算失准。

Response::download() 内部会调用 ob_end_clean()，但如果之前有 ob_start() 未配对 ob_end_flush()，会导致缓冲区嵌套混乱
手动设 header 时，别混用：header('Content-Type: application/json') + Response::json() 会重复设 Content-Type，部分 Nginx + FastCGI 组合下直接报错
下载大文件时，ob_get_length() 可能返回 false，导致 Content-Length 缺失；应改用 filesize($path) 显式设置
Apache 下若启用了 mod_deflate，而 PHP 又开了 ob_gzhandler，gzip 嵌套压缩会破坏二进制文件校验——下载场景务必关掉 ob_gzhandler

最麻烦的其实是那些“看起来没输出”的地方：Composer 自动加载的警告、PDO 构造失败的致命错误、甚至某些扩展（如 xhprof）的钩子函数里偷偷 echo。真要压测或上线前，得用 strace -e trace=write -p $(pgrep php-fpm) 抓底层 write 调用，才能确认第一字节从哪来。