headers already sent错误的根源是首个非法输出位置，如BOM、空行或echo语句，需用hexdump或VS Code确认并清除BOM，保存为UTF-8无BOM格式，尤其ThinkPHP配置文件和think入口文件。
直接看报错位置和触发文件
PHP 报出 headers already sent 时，末尾通常带具体路径和行号，例如：headers already sent by (output started at /var/www/app/config/app.php:1)。这个行号非常关键——它不是 header() 被调用的位置，而是**第一个非法输出发生的地方**。常见情况包括：app.php 文件开头有 BOM、结尾多了一个空行、或某处写了 echo / print 却没注意。
不要跳过这一步去改 header() 调用逻辑，先打开报错指出的那个文件，用十六进制编辑器（如 VS Code 的 Hex Editor 插件）确认第 1 行是否含 \xEF\xBB\xBF；或者用命令快速扫描：
grep -rl $'\xEF\xBB\xBF' app/ config/ public/
只要扫出来，就说明该文件是污染源，必须清除 BOM 并保存为 UTF-8 无 BOM 格式。
ThinkPHP 配置文件是重灾区
ThinkPHP 的 config/ 下所有 PHP 文件（如 app.php、cookie.php、session.php）极易被忽略：它们不经过框架路由，却在自动加载早期就被 require 进来，一旦含 BOM 或结尾空行，就会在 session_start() 或 header() 前吐出三个字节，直接崩掉整个响应流程。
立即学习“PHP免费学习笔记（深入）”；
- VS Code 右下角状态栏点编码 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - 检查每个配置文件末尾是否有多余换行：光标移到最后一行末尾，按
End后再按一次→，如果还能移动，说明有不可见空格 - 禁止在配置文件里写
echo、var_dump、print_r—— 它们不是调试入口，是生产环境的定时炸弹
ob_start() 是临时止血，不是根治方案
在 public/index.php 开头加 ob_start() 确实能让页面“看起来正常”，但它只是把错误吞掉，掩盖了真实污染点。更危险的是：它会让 headers_sent() 返回 false，导致你误判 session 或 cookie 写入成功，而实际上浏览器根本没收到 Set-Cookie 头。
真正该做的是：
- 只在调试阶段加
ob_start()，并配合if (headers_sent($file, $line)) { die("sent at {$file}:{$line}"); }定位源头 - 上线前必须移除所有
ob_start()，否则 runtime 日志可能写不全，debug 页面也无法渲染 - 别依赖
output_buffering = On的 php.ini 全局配置——不同环境行为不一致，ThinkPHP 自身也不承诺兼容
命令行 think 工具也受 BOM 影响
php think 报 Class 'think\Console' not found，90% 不是类不存在，而是入口文件 think 本身被 BOM 污染，导致 require __DIR__ . '/vendor/autoload.php' 这一行根本没执行到。Windows 上 PowerShell 默认编码非 UTF-8，也会让 think 文件读取失败。
验证方式：
- 用
file -i think查看编码，如果是charset=bom或utf-8; charset=unknown，立刻重存为 UTF-8 无 BOM - PowerShell 中先执行
$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding再运行php think - Linux 下确认
think文件权限为755，且第一行是#!/usr/bin/env php，不能有 DOS 换行符（^M）
BOM 和空字符这种问题，在 ThinkPHP 里不会报错提示，只会静默破坏初始化链。它不发生在框架内部，而是在框架还没开始跑的时候，就已经被拦在门外了。
