结论：记事本保存 php 文件时默认插入 bom（ef bb bf）或混用 \r\n 换行符，php 解析器在输出前意外捕获这些不可见字符，导致 cannot modify header information 或 parse error；根本原因是 bom 被当作实际输出，破坏 header() 调用前提，且记事本不支持 utf-8 without bom 保存，必须改用 notepad++ 或 vs code 转为无 bom 格式并验证字节确认修复。
直接说结论：记事本保存 PHP 文件时默认插入 BOM（EF BB BF）或混用 \r\n 换行符，PHP 解析器在输出前意外捕获这些不可见字符，导致 Cannot modify header information 或 Parse error。
记事本保存后出现 Cannot modify header information
这是最典型的现象——页面白屏、报错提示“headers already sent”，且错误定位到 functions.php 或 index.php 第一行。根本原因不是你写了什么代码，而是记事本在文件开头悄悄塞了 BOM 字节。
-
BOM是 UTF-8 文件头部的三个字节EF BB BF，PHP 把它当普通输出内容，而header()函数要求必须在任何输出之前调用 - 即使你只改了一个中文字符，记事本也会重写整个文件并附带
BOM；用xxd yourfile.php | head -n1可验证是否含ef bb bf - 部分服务器（如 SAE、某些 Nginx + PHP-FPM 组合）对 BOM 更敏感，本地测试可能不报错，一上传就崩
为什么改英文没事，加中文就乱码或报错？
记事本默认用系统 ANSI 编码（Windows 下通常是 GBK）读取文件，但 PHP 源码绝大多数是 UTF-8 无 BOM 编码。你输入中文时，记事本按 GBK 编码存盘，PHP 解析器却按 UTF-8 解码，结果就是乱码或解析中断。
- 临时补救：打开乱码文件 →
文件 → 另存为→ 编码选UTF-8（注意不是UTF-8-BOM）→ 保存覆盖 - 但此操作不能清除已有 BOM：如果原文件已有 BOM，另存为 UTF-8 会保留它；必须选「UTF-8 无 BOM」——记事本根本不提供这个选项
- 真正安全的做法：用
Notepad++打开 →编码 → 转为 UTF-8 无 BOM→ 保存；或用 VS Code 设置"files.encoding": "utf8"和"files.autoGuessEncoding": false
如何快速检测和修复已损坏的 PHP 文件？
别靠肉眼猜，用命令行或编辑器确认实际字节内容：
- Linux/macOS 下运行：
file -i yourfile.php看输出是否含charset=utf-8；再跑head -c3 yourfile.php | xxd，若输出00000000: efbb bf就确认有 BOM - Windows 下可用 PowerShell：
Get-Content yourfile.php -Encoding Byte | Select -First 3，若返回239,187,191即为 BOM - 修复方式不是“删掉开头空格”——BOM 是不可见字节，必须用支持无 BOM 保存的编辑器处理，或用脚本批量清理：
sed '1s/^\xEF\xBB\xBF//' yourfile.php > clean.php
BOM 和编码问题本身不难理解，但容易被忽略的是：它往往不单独出错，而是和 output_buffering 设置、服务器响应头顺序、甚至 FTP 传输模式（ASCII vs Binary）叠加触发。一旦线上出问题，优先查文件头三字节，比逐行看逻辑更快。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
