唯一根本解法是确保调用 header() 前无任何输出，包括 BOM 和空白；需用 UTF-8 without BOM 保存文件、删除 PHP 结束标签后换行、排查 include 文件末尾空行及隐式输出。
必须在调用 header() 前确保没有任何输出，包括不可见字符——这是唯一根本解法。
检查 PHP 文件开头的 BOM 和空白
BOM（字节顺序标记）是 UTF-8 文件开头的隐形三字节 EF BB BF，PHP 会把它当内容输出，直接触发错误。VS Code、Sublime、Notepad++ 等编辑器默认可能带 BOM，保存时务必选「UTF-8 without BOM」。
同时检查：<?php 标签前不能有任何空格、换行、制表符或中文全角空格；文件末尾的 ?> 后也不能有换行——最稳妥做法是纯 PHP 文件里直接删掉 ?>。
- 用命令快速检测 BOM：
head -n1 yourfile.php | hexdump -C | head -1，若输出含ef bb bf就确认存在 BOM - Linux/macOS 下批量清除：
sed -i '1s/^\xEF\xBB\xBF//' *.php - Windows 用户可用 Notepad++：编码 → 转为 UTF-8 无 BOM 格式 → 保存
定位实际输出源头：不只是当前文件
错误提示里常带类似 in /path/to/file.php on line 12，但那只是 header() 调用失败的位置，真正“先输出”的地方可能在被 include 或 require 的文件里——比如某个配置文件末尾多了一行空行，或日志类构造函数里写了 echo。
立即学习“PHP免费学习笔记（深入）”；
- 用
grep -n "^[[:space:]]*$" *.php扫描所有 PHP 文件末尾空行 - 临时在入口脚本第一行加
ob_start();，再逐个注释include行，缩小问题范围 - 注意 Composer 自动加载的类文件，也可能因编码或结尾空格出问题
为什么 ob_start() 不是万能解药
启用输出缓冲（ob_start()）确实能让 header() 暂时不报错，但它掩盖了真实问题：你本不该在头信息前输出任何东西。缓冲区一旦满（如默认 4096 字节），或遇到 ob_flush()、flush()、readfile() 等强制刷出操作，照样会崩。
- 缓冲区大小受
output_buffering配置限制，php.ini中设为on是全局生效，但无法解决 BOM 或逻辑错误 -
ob_start()后若忘记ob_end_flush()或误用ob_end_clean()，页面会空白且无提示 - 某些环境（如 CLI、部分 SAPI）下输出缓冲默认关闭或行为异常，依赖它会降低代码可移植性
真正难排查的，永远是那些看不见的字符和跨文件的隐式输出——别只盯着报错行，要顺藤摸瓜查包含链、检查编辑器编码设置、验证每个被引入文件的末尾状态。
