根本原因是PHP输出缓冲区被提前触发，如BOM、空格、echo或未捕获的Notice等导致header()调用前已有输出；ThinkPHP的Response类在发送响应前调用header()，一旦输出已发生即报错。
为什么 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 内置追踪机制，比翻日志高效得多。
- 在入口文件
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 下安全控制输出缓冲的实操方式
不要依赖框架自动处理，主动接管缓冲生命周期才是稳定解法。
立即学习“PHP免费学习笔记（深入）”；
- 在
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 调用，才能确认第一字节从哪来。
