php文件开头bom（\xef\xbb\xbf）会导致include时提前输出，触发“headers already sent”错误；错误提示位置常非bom真实所在文件，需沿include链逐个检查config/、app/等目录下手写php文件；应使用编辑器转存为utf-8无bom格式或用sed批量清除。
include 的 PHP 文件开头有 BOM 就会提前输出
PHP 解析器不会跳过文件开头的 \xEF\xBB\xBF，而是把它当作真实输出内容。一旦某个被 include 或 require 的文件（比如 config.php、functions.php）带 BOM，它在执行到第一行 PHP 代码前，就已经把这三个字节发给了 Web 服务器——这等同于“已有输出”。后续任何调用 header()、session_start()、setcookie() 的地方都会立刻报 Cannot modify header information - headers already sent。
为什么错误提示总指向第一个 PHP 文件，而不是真正含 BOM 的那个
PHP 错误信息里显示的“in /path/to/index.php on line 1”，往往只是“最早触发输出的位置”，不是 BOM 所在位置。实际含 BOM 的可能是 include 链末端的一个配置文件，甚至是一个被多次嵌套引入的 common.inc.php。排查时必须顺着 include 路径逐个检查，不能只盯着报错文件本身。
- 用
head -c3 config.php | xxd（Linux/macOS）或Get-Content config.php -Encoding Byte | Select -First 3（PowerShell）确认开头三字节 - 特别注意
app/、config/、extend/、public/下的手写 PHP 文件，ThinkPHP 自身源码不含 BOM - IDE 自动生成的文件（如路由缓存、日志类）通常安全，问题集中在人工编辑保存的文件上
Windows 记事本和老版 Notepad++ 是重灾区
记事本保存 UTF-8 文件时强制加 BOM，且不提供“无 BOM”选项；老版 Notepad++ 默认编码设为“UTF-8-BOM”，即使你没动过设置，新建文件保存也会埋雷。VS Code 和 PhpStorm 默认是“UTF-8 without BOM”，但若曾手动切换过编码，或从别处复制粘贴过内容，仍可能意外带入。
访问全球海洋潮汐模型。功能包括查询指定日期、时间和地点的潮高、潮汐极值及格点天气数据。
- Notepad++：打开文件 → 【编码】→【转为 UTF-8 无 BOM 格式】→ 【保存】
- VS Code：右下角点击编码名称（如 UTF-8）→ 选【Save with Encoding】→【UTF-8】（不是 UTF-8 with BOM）
- 不要信“另存为 UTF-8”——很多编辑器这个选项实际仍带 BOM
运行时 ltrim() 不能替代字节级清除
有人试过在 include 后对内容做 ltrim($content, "\xEF\xBB\xBF")，这完全无效。BOM 不是字符串开头的字符，而是文件磁盘存储层面的前三个字节；include 是直接执行，不是读成字符串再处理。想临时绕过，只能用 ob_start() + ob_get_clean() 捕获并截掉开头三字节，但这是补丁，不是修复——源头文件的 BOM 还在，下次 include 别的地方还会崩。
真正要做的，是批量扫描并物理删除那三个字节。最稳的方式是用 sed -i '1s/^\xEF\xBB\xBF//' *.php（Linux/macOS），或跑一次 PHP 清除脚本，把所有手写 PHP 文件的开头 \xEF\xBB\xBF 彻底抹掉。否则只要有一个漏网，整个 include 链就不可靠。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
